Julien Topcu - Loi de Conway: Lorsque votre conception produit se fache avec votre organisation (FR)

[00:00:05] Thank you.
[00:00:09] You didn't realize it, but you've just left the Montrouge belfry. It's going to be important for the rest of the operations that you keep calm, because you've just been projected into a new dimension called Lighty Zone, in which you will go through three periods.
[00:00:28] You are now in 50 AD, that is, 2020 of our era, in a country in Western Europe called Gaulish. And you are now a project manager at the Ministry of Education. The government of Gaulish has decided to reform its educational system. And through your superior, you learn that you'll have to organize a conference whose goal is to reflect on the major trends in the evolution of the education sector.
[00:00:57] And as in any self-respecting organization, top-down is never far off, so you are advised to call upon external firms. You don't even have time to protest before your superior explains to you that this request comes directly from
[00:01:14] Jupiter himself. So, as you will have understood, this is an anachronistic Gallo-Roman dystopia, and any resemblance to recent news events may well be deliberate.
[00:01:28] So, by the way, we'll tell you that you'll have to call on the firm called Makini. So, Makini, you've already heard about them, but you don't really know what they do. So you decide to go to their website.
[00:01:41] Here it is. something very triumphant, there's the arch and all that. You should note that Makini in the Zone is spelled with an S that isn't pronounced, to avoid any legal action following Stock. And then, and then Gory is written France. So, what is Makini? So it's primarily a company involved in the decisive transformations of its clients, we don't really know yet. So the goal is to find out how they can help you organize a conference on the education reform. So going down a bit, a bit more information. So, well, they've been around since '64, great. innovation accelerator in 200 areas of expertise. So that's still a, you'd say, a very large consulting firm, 200 areas of expertise, that's not something every firm has. But what we can notice is that roughly in the middle, it says there are 5000 technological profiles for education. You don't really know how that can help you, but it's written in big letters, so here we can wonder, well, isn't it a company, an ESN for example.
[00:02:48] Well, by scrolling down a bit, you create a little empathy, you introduce the team. Not just anyone, though. because you have the general director, a member of the Board of Directors, and a team leader for the insurance division. And oops, when you click on it, apparently, there's a lot to say about Makini's top management. Okay, let's go back, that wasn't intentional. But here, you have a call to action, the first on the site, which invites you to view other profiles. So, let's be clear, other profiles are still directors and senior directors. And for each of them, you discover that they are, as we say, specialized in certain areas like pharmaceuticals, digital, they do things with their fingers, and then luxury. So, you're wondering, well, maybe there are people specialized in education.
[00:03:40] Education.
[00:03:43] Well, apparently not here. But we're going to continue anyway, we're going to dig deeper.
[00:03:51] OK, so here we are on the main page.
[00:03:55] Ah, now we have a bit of a know-how demonstration. So here we have publications on growth in Europe, increasing healthy life expectancy, beating cancer, the metaverse, so still nothing on education. But you continue.
[00:04:11] OK. So, well, no, we didn't really want to go work for them. So, here we can wonder, who is this site for? Potential clients or candidates? It's all very confusing. So if you continue, well, there's just the location of their office in Paris and a contact form which will be very useful this time. Since we need to send them the call for tenders.
[00:04:32] But you still haven't understood how they can help you with education. However, you remember that when you arrived, there was a menu that's no longer there, oops, gotta go back up.
[00:04:44] And hold on, you've been on the site for a good 5 minutes now, huh.
[00:04:48] We're going to click on "our profession" and there are balls spinning in 3D.
[00:04:54] Which reinforces a bit this idea of, is it a tech company or not? We don't understand anything anymore. But with the little arrow going down, what are we going to see? Ah, now that's interesting, well. In any case, what they show us is that there are sectoral competence centers and functional competence centers, including aerospace, chemistry, education. So that's cool because that's exactly the information we were missing.
[00:05:19] And below, well, design, digital, marketing, etc. what and what you've discovered there, what is it? It's the fact that Makini is organized in a matrix-like way, you'd say. Well, but that's information that's not very useful to you. Well, once you click on education, there, finally, is the value proposition, their expertise in education. And then, well, testimonials and so on, but well, we're not going to change a winning formula. So, we still have all the partners and senior partners of the division here, and you should know that this is the top of the food chain, the business lines won't be on the site. So, ultimately, you first learned more about Makini's organizational chart. And about its organization even before knowing how it could meet your needs, even though you are potential clients.
[00:06:07] So, you leave with a slightly bitter feeling. You tell yourself, but really, it's all very strange, I'm left a little hungry. But know that this feeling doesn't come from nowhere. It comes from the fact that you've just rubbed shoulders with Lighty Zone. Lighty Zone is a world where beliefs and science intertwine, and it's governed by forces that push people to do sometimes a little strange things. We could, we could blame the designers. of Makini for having made a site with an experience that's not great for potential clients. But in reality, it's not just a practical problem. There's something that potentially pushed them to do that. And to explain this phenomenon, we have to go back to '98. On July 13, the New York Times published an article about Dr. Jacob Nielsen. Well, as his photo doesn't indicate, he's not the one who invented the mouse. But Dr. Jacob Nielsen, who was defined here as the guru of web page ergonomics at that time, is one of the pioneers of user experience. And he set himself a challenge at that time: to make the web more usable. And he had noticed something in the 90s, that companies creating their websites did everything to optimize an indicator for search engine indexing called the SEO, no. There was another one before.
[00:07:34] The CIO. Who knows the CIO?
[00:07:38] Nobody. You know?
[00:07:41] Are you sure?
[00:07:43] It's C-level Igo optimization.
[00:07:47] C-level is top management. In fact, a year earlier, Dr. Nielsen had written an article called "Top Ten Mistakes of Web Management," and in issue number three of the most common errors. It's about having a site that reflects the structure of its organization. And what he says is that users shouldn't have to know how your company is organized; they shouldn't even be able to deduce it from the structure of your site. He also says, a classic sign of this site management problem is that on the homepage, there's a button for each of the company's senior vice-presidents. Nobody does that today.
[00:08:26] '97.
[00:08:28] Strangely, that's exactly what you just experienced. He was joined in '98 by Nigel Bevan, who, in a study called "Usability Issues in Website Design." explains why sites are so frustrating to use, especially because organizations often produce sites whose content and structure reflect the organization's interests rather than user needs. And here we can ask ourselves if Makini effectively doesn't have a desire to be more present in tech. because we put quite a lot of tech stuff forward for you. But that, as someone at the Ministry of Education, that's not for you either.
[00:09:09] So, we can say, if these bad practices have been documented since the 90s, what drives designers today to still do this? We'll see that in a while, but here you are now projected into a new era. You are now in Redmond in the Seattle area in the United States in 2008. And you are now the marketing director at Microsoft. And you are in the process of defining the communication strategy to boost sales of your new flagship product, Windows Vista.
[00:09:42] And your boss bursts into your office furious because your competitor has just released an advertisement. which reports very small flaws in your Windows XP replacement.
[00:09:53] Hello, I'm a Mac. And I'm a PC. here with good news for anyone who's ever been frustrated by Vista. Are you fixing the problem? No, I'm making them easier to live with with my new line of calming teas. There's Crashi Time Camomile, just the thing to soothe the nerves after a Vista related crash. Or if Vista is making your applications run slow, there's Pomegranate Patience. And for mornings, there's Raspberry Restart Time. That's quite peaceful. Also afternoons. But we should move on. Yes, let's move on, Mac. To my line of Vista stress-relieving bath salts.
[00:10:24] that was a real commercial, they made several like that.
[00:10:28] So, it's a disaster.
[00:10:31] Because indeed, your customers, the, well, your customers, your users, fed up with the serial crashes of your new OS and hardware incompatibilities, switch back to Windows XP. And some even go to the competitor with the bitten apple. And the pressure is such that you are forced to let PC manufacturers sell new machines with Windows XP. But amidst this misfortune, two researchers from Microsoft and one from the University of Maryland wonder if, retrospectively, we didn't have ways to predict the, shall we say, the predisposition to failure of Vista modules. So, they launched a study on 50 million lines of code. That's a good monolith, though. No, there are still 3404 binaries. So there are 3404 modules. And they evaluated several indicators, let's say, which are generally used for quality, derived from scientific studies. The first is code churn. That's the number of times the same piece of code is changed, re-changed, re-changed before going into production, which can be a small smell of complexity, for example. Code complexity, for those who know cyclomatic complexity. Some don't know what that is. Well, anyway, it's about ifs and things, in short, it's the complexity of the code, to put it simply. Dependency is coupling. It's the fact that one part of the code is strongly coupled to the other parts of the code, which means that if you make a modification there, it will break that dependent part. Code coverage, which you should know, is test coverage, and the number of bugs before release. But they also added another indicator, which is the organizational structure. And in the organizational structure, they said they would also evaluate certain things that are not necessarily technical. In these matters, they said they would take some postulates. We'll assume that the more people touch the code, the lower the quality. That if you lose a large part of the team, because they left, then that affects knowledge retention and therefore quality. That the closer the person with the power to decide on the component is to the engineers who modify it, the better the quality, and the more contributors to a component belong to the same team, the better the quality. There are others. And they said to themselves, well, let's see if together, this can be a good indicator for predicting failures in Vista modules. Because in fact, retrospectively, they know which modules failed and which didn't. So, they're going to look at the coverage of these modules, they're going to look at, well, each of the indicators.
[00:13:13] So I'm not going to explain the difference between recall and precision, although I could, but the goal here is to have 100% in each column. meaning they were as precise as possible. And the study showed that organizational structure was much more precise than other traditional indicators. So, in the context of Windows Vista, they demonstrated that the organizational structure had a greater impact and was a better indicator for component failure predispositions than something like code coverage. This study, called "The Influence of Organizational Structure on Software Quality: An Empirical Case Study" from 2008. demonstrated that organization, organization eats code quality tools at breakfast. To paraphrase Peter Drucker. In reality, the researchers' intention at that time. was to verify a postulate that had been made several decades before, in 1975, by Dr. Frederick Brooks in the book called "The Mythical Man-Month." In this book, he explains that product quality is greatly affected by the organization's structure. This book, by the way, is strongly unrecommended for Gantt chart enthusiasts; the resulting risk of vasovagal syncope is too high. I see some of you have read the book.
[00:14:38] So, do you feel those little tingles at the back of your neck? That's because you've just made another leap into another era.
[00:14:49] That's the sound of the R that brings you to La Défense. You go to Courbevoie in 2016 and you go to the headquarters of the multinational online travel company for which you work as an architect. This company, I won't name it, but it really exists. And in this company, you defined an architecture for the train ticket reservation system. Like this one. You determined with the development teams that this was the best way to meet the needs. You should know that this company sells train tickets all over the world. And every train is different. The way of managing trains, whatever the country, is completely different. And since the company doesn't want to create custom code for each country, they decided to have an agnostic and standardized experience for users. So the way we manage trains in France will be the same as in Italy. Which means we have an agnostic architecture here. Not specific to each national train. At the bottom, Rail supply is for interconnecting with railway companies in each country, as you can imagine, they each have different APIs. The goal is to federate it into a single API which is Rail supply. Above, Rail shopping is basically the business logic. It's what allows you to select a train, its fare, and then, and then the seat, etcetera, and above that, the UI.
[00:16:13] And so this architecture was chosen 3 years ago.
[00:16:16] And you now decide to step out of your ivory tower to see what the development teams are doing. You heard that these software programs, or rather these services, these microservices, even if we want to use the M word.
[00:16:30] are becoming increasingly difficult to maintain. And by glancing at the code, to my astonishment, exactly what we didn't want was produced. That is to say, each of the bricks could be cut per country. True story, huh.
[00:16:45] So, you thought, but uh, how is that possible? Is there a competence problem among the developers? In reality, what I forgot to tell you is that, in addition, what should have been shared in terms of functionality ended up being duplicated, of course, in each of these If my country.
[00:17:02] So, after some investigation, you saw that it came from a false belief. In any case, from a misunderstanding of what feature teams were on the part of management. For management, feature teams are great. Because with feature teams, people are autonomous, they can type anywhere. Normally, they're supposed to develop features, but a feature equals a project, right? So, the worst part is that these three teams they had at their disposal were in different time zones. And they said, well, it'll be simpler to organize them by train. Because in addition, we first want to deliver the English train, then the German train, and then the French train. So, we have teams with different managers, different deadlines, different objectives, in different time zones, adding pressure, and this is what happens. Meaning, well, we have to meet our own deadline. So what's going to happen is we're going to protect ourselves. We'll do if my case. because the guys next to me, well, I'm not going to talk to them much, and they're not even awake while I'm coding. So, I don't want to break them and I don't want them to break me. Here is the result. So, ultimately, we built a system that deviated from the desired design.
[00:18:17] And the worst part is that since the ownership of each component is unclear, no one wants to pay for the cleanup. No one.
[00:18:30] So, now, we might perhaps rethink Vista's organizational structure indicators. I think there's a lot to say about that. But actually, it seems like Lighty Zone is trying to send you a message. It would seem that your user experience, your product design, the quality of the product and code, and your architecture are greatly impacted by your organization, and perhaps even impacted in a very negative way. One might even wonder if the organizational structure isn't perhaps better than certain good operational practices.
[00:19:08] So here we've only presented facts, but at no point have we explained the phenomenon. To explain the phenomenon, we have to go back to 1968, which is a bit old, isn't it? No, but in 1968. Dr. Melvin Conway published an article called "How do Communities Invent" in Data Motion magazine. He explains how organizations design systems. And we're going to do a little exercise, you'll see, you can reproduce it in all your organizations.
[00:19:36] It's going to be very easy. We're going to take a system. A system, what is it? It's anything you want, it can be a webpage, a service, a product, a phone, a physical car, all of these are systems. some good operational practices. So here we have just exposed the facts. But at no point did we explain the phenomenon. To explain the phenomenon, we have to go back to 1968. It's a bit old though. But in 1968, Dr. Melvin Conway published an article called "How Do Communities Invent" in Data Motion magazine. He explains how organizations design systems. And we're going to do a little exercise, you'll see, you can reproduce it in all your organizations.
[00:19:35] It's going to be very easy. We're going to take a system. A system, what is it? It's whatever you want. It can be a web page, a service, a product, a phone, a car, physically. All of these are systems.
[00:19:50] And each system can be broken down into subsystems, right?
[00:19:56] Uh, sorry. Excuse me. So each system, here I took an e-commerce system. which has four subsystems, so one that is dedicated to user management, one for shopping functionalities, another for payment, and another for invoicing, which we call billing. And Melvin Conway asks if there wouldn't be a predictable relationship between the structure of this system and the structure of the organization that produced it. He notes that, in a very simple way, we could find for each of these subsystems a team in charge. Okay. Well, I think you can all make the same observation. And of course, for this system to work, some of these subsystems must interface. So here, for example, shopping will have to interface with user to potentially retrieve user information. An interface in IT can be an API call with data transfer. In an electrical system, it can be a socket with a plug that goes inside, and in mechanics, especially in automotive, it can be mechanical parts that fit together, like for example, a flywheel and a clutch. And Melvin Conway notes that if two subsystems have to interface, then the teams in charge must communicate with each other to define and negotiate a contract.
[00:21:12] A contract that specifies this interface. He also notes that generally, this depends on the companies, but this need for communication will often be driven by a coordinator. In the current world, because we were in '68, we can consider that these are the Scrum Masters or the Product Owners. And he also notes that when two subsystems don't need to interface, like for example, shopping and billing, there's no need to negotiate a contract, so there's not necessarily a need for these teams to communicate with each other.
[00:21:46] So, what he notes is that there is a close relationship between the structure of the system and the structure of the organization that produced it. So, often, we can have a team in charge of several subsystems, for example, a payment billing team. In this case, it's a compacted version of the system's structure. And what we're saying there is that this mimicry, between the structure of the system and the structure of the organization that produced it, is what we call a homomorphism. And there, perhaps you're saying that he didn't invent hot water, but that's the drama. Because a homomorphism has properties that can be very annoying sometimes. Notably, let's take an organization, like this one. But we start from zero. Apart from the fact that we have already defined this organization. So we start from a need, we don't have a system structure. The goal of an organization that needs to build a system is to evaluate, well, to think about possible solutions, and to evaluate the best solution to meet the need. Okay?
[00:22:51] Now, we're going to imagine ourselves as omniscient. And that we are capable of listing all possible solutions in the universe to meet their needs. We're going to limit it to two because otherwise it's too complicated. I don't have enough space on the slides. And we're also going to consider that the solution at the bottom is the best, arbitrarily.
[00:23:09] So what's important is that we know we're omniscient, so we know it. They don't know it yet. They haven't even become aware of these solutions yet, have they? They're not there. What we can notice as a difference between the first and the second solution is that in the second, there is an interface between user and billing, and here, there is a checkout system, which doesn't exist above. So we're going to say that in the case above, the responsibilities that are there are distributed between shopping and payment. What you can also see is that the structure of the organization on the right there, doesn't resemble at all the structure of the best solution. But rather the first one. So, will this organization, which has already been chosen by management, be able to produce this design? If we believe the rule of homomorphism, well no, it will rather produce the first design.
[00:24:03] Because, why? Well, first of all, we've conditioned people in a certain way, hierarchically and managerially, to communicate in a certain way. So here, since there is no conscious communication between user and billing, they may never realize that by discussing together, they will discover a need for interfacing here of the systems, which will find a better solution to the problem.
[00:24:29] And then, as the management already exists, and they have predefined scopes for each of the teams, how do you want two teams, already constituted with different managers, like for example shopping and payment, to realize that there are responsibilities here and there, which could be grouped into another system? We've conditioned them to think in a certain way.
[00:24:51] In fact, you have to understand that as soon as an organization is chosen, you have already made, in a certain way, design choices, voluntarily or not. And these organizational choices will exclude, in a completely involuntary way, possible solutions.
[00:25:13] And even if these solutions are the best. Because you have biased, in fact, somewhere the search process. Conway explains that in the 60s, there was a structure of 8 people who had to develop a COBOL compiler and an Algol compiler. If you don't know what a compiler is, it's software. For budget and timing reasons, they decided to distribute them 5 for the COBOL compiler and 3 for the Algol compiler. As a result, they had a COBOL compiler in five phases and an Algol compiler in three phases. Although it's pretty much the same thing. So it turns out that someone doesn't agree with that. Tom Cheatham in '96 said that if you take five people, you ask them to make a COBOL compiler, the compiler will run in four phases. Because someone has to be the manager.
[00:26:05] So Conway describes a lot more actually.
[00:26:10] He says that if you take, for example, at the very beginning of a system, there is a need, you're going to put a small group of people who will try to understand the need. But often what happens is that there's pressure in terms of budget and timing. And a manager knows that if by chance he misses his deadline and he hasn't taken all the resources he had at his disposal, we're going to reproach him. And that's going to put pressure on the initial designers of the system. Who would rather, perhaps, continue to work together to tackle the complexity, reduce it until they find a solution, instead of fragmenting knowledge into different subgroups.
[00:26:55] Unfortunately, history shows that, well, management doesn't want to take the risk, and these people are reinforced and reinforced to maximize the chances of successfully meeting the deadline.
[00:27:07] This comes from a belief, says Conway, that work is linear. Some people think that the work of two people over four months is equivalent to the work of eight people over one month. Moreover, Frederick Brooks, to mock this, wrote in his book that a human pregnancy takes 9 months, regardless of the number of women assigned to the task.
[00:27:29] So let's go back to this structure.
[00:27:35] The thing is that in a company, generally there are managerial rules. We explain to you how teams should be constituted, the roles you should have by default, etcetera, etcetera. Which means that an organization will be born. Because the rule is, no more than two people in a team, one manager per team. Okay, great. Which means you have an organization by default, even before you've analyzed the need. And once the organization exists, it will be used. But the need there, well, it's too big now, each team will need a piece of the need. Well, we're going to split it and re-split it in a more or less arbitrary way. Which means that the intersections like this one, in gray, well, the teams won't necessarily detect them. Because we polarized the way people think. We created silos. Plus, it's not even the same management there. There are people who are laughing and looking at each other, in my opinion, it smells like experience.
[00:28:32] In fact, what happened is that, well, by delegating, we also lose knowledge.
[00:28:39] What Conway says is that there is no design group that is both organized and unbiased.
[00:28:47] And you have to understand that. Your organization will bias in a certain way what you are going to build.
[00:28:54] So, what Conway says, because he goes even further, is that communication completely disintegrated at the very moment when there was a delegation. Because the two initial designers, they had to gain perspective to be able to synchronize and delegate things. So they moved away from the need. By doing that, they fragmented knowledge into subgroups. Which means that, notably, if you also have two people hierarchically quite far apart in terms of team, who have to agree. They can't agree. What happens?
[00:29:32] It will escalate. And then we're going to ask people who are now further away from the analysis to make a choice. Well, let's say they can't. Well, we're going to escalate again with someone who is even further away from the need and who will have to make a choice. So what Conway says is that in structures like this, in these structures, generally, the communication structure will tend towards its administrative, hierarchical structure. And with Conway's law of homomorphism, this administrative structure will be found in what, in the system produced. That's why, for Conway, the military tends to create systems that resemble their organization chart.
[00:30:13] So all of that, he summarizes it in this sentence: he explains that the structure of large systems tends to disintegrate during development in a qualitatively greater way than small systems. Because of this disintegration of communication and this bureaucratic system that arises.
[00:30:31] Brooks schematizes a bit more the disintegration of communication. When you had three people in the team, you had three communication channels. But when we went to 11, we didn't go to 11 channels, but 55 channels of communication. Which means that the effort of communication is not linear. When you add people, the effort is not linear. It becomes more and more complicated.
[00:30:57] And what he also says, and so, as the communication effort is not linear, the work effort is not either. We also saw that a team of three people will not produce the same thing as a team of 11. We saw it there with the Algol and COBOL compiler.
[00:31:13] And what Conway says is that if you take three well-chosen people, they will produce a better system than 11 people, because all the assumptions we make that are true, of parallelism, that are true when we are more like potatoes, well, it's not true when we design systems.
[00:31:31] And the very act of adding people, in fact, will rather tend, because we want to ensure the date, will rather tend to the structure towards its bureaucratic structure, which will add additional costs of synchronization and communication for the teams.
[00:31:48] Moreover, later, in '75, Brooks always explains that if you add people to a project that is behind schedule, it increases the delay.
[00:32:00] So what Conway explains is that it becomes necessary to restrict communication to ensure that people can ensure that the work is done. Besides, who has never complained about having too many ceremonies? Has that ever happened to anyone? No?
[00:32:15] Too many meetings.
[00:32:19] Well, Kenny has already done it.
[00:32:22] So what can we say about mega-structures at scale on the shelf, agnostic to systems, that explain that you need to have a very complex communication graph? What will that produce as a system? For those who don't know, it's safe 5.1. I have the latest version, Kenny had 5.0.
[00:32:42] So I haven't really stated Conway's law yet. Conway's law says that organizations that design systems are constrained to produce designs that are copies of their communication structure.
[00:32:58] And that's why, notably, on Makini's site, the first thing you discovered was their hierarchy. And the worst thing is that the further you went on the site, the further you went down in the organization chart. And we can't deny that, we really experienced it. The second thing you took was their matrix organizational structure, even before knowing how they could help you meet the need. And there, it's an example.
[00:33:23] of a place where the communication structure tended towards its administrative structure, and which ended up in the software, well, on their website.
[00:33:37] In the case of the online travel agency, although we had defined an agnostic architecture, since we organized the teams by country, well, it gave software that was cut by country.
[00:33:52] And in Vista's case, well, we saw that the quality of the organization was a better, uh, well, a better predictor of failure than traditional indicators. And that's one of the effects of Conway's homomorphism too.
[00:34:11] So what's quite funny is that if we look in detail at what they had put in their organizational structure, that a large loss of team members affects knowledge retention, blah blah blah, that the more contributors to a component belong to the same team, the better the quality. And the closer the person who has the decision-making power is to the engineers, the better the quality. Well, in fact, we are just the opposite of the disintegration of communication that Conway cited.
[00:34:38] A 2012 study called "Exploring the Duality Between Product and Organizational Architecture: A Test of the Mirroring Hypothesis" compared, or rather, corroborated Conway's law a bit more. In fact, they compared open-source software with equivalent paid, commercial software. For example, a calculator software, open source versus a commercial calculator software.
[00:35:02] And they realized that the open-source software they compared was generally more modular and less subject, how to say, was easier to modify. And they, they, well, what they say is that this is surely due to the fact that the commercial structures, well, the companies, are in fact structures that are very strongly coupled.
[00:35:30] compared to open source. Because in open source, you have people who are volunteers, they don't have a boss, it's at their good will, they don't even have formal objectives among themselves. So it's really the extreme in terms of weak coupling. And that's how they explain the difference.
[00:35:51] So, are we, uh, condemned to live these effects of Conway's law? And are we going to stay stuck in the IT zone?
[00:36:02] So you won't be able to avoid this law, but you will potentially be able to manage its effects a little. In fact, what Conway says is that you have to organize yourself according to the need, the communication effort. So first, analyze the system, simplify it, in what is manageable, that is, into subsystems. Then look at the interfacing needs between these subsystems and that will define the communication needs. So what will allow us, in fact, to restrict to the strict minimum the communication channels between the teams to ensure that the work is done.
[00:36:39] But here we have a problem.
[00:36:42] It's that, well, we know very well that the first design we choose is never the best, because we already improve, because needs can evolve, so the needs in terms of design will also evolve. Which means that for things to be effective, the organization needs to be flexible in its way of communicating and organizing itself. So there, in a way, Conway described a new class of organization design and organization management that we later named Inverse Conway Maneuver or Reverse Conway Maneuver. In fact, this name was given in 2015 by James Lewis, Technical Director at ThoughtWorks, during the great rise of microservices in the IT world. In fact, James Lewis, with his teams, had the crazy idea of telling himself that it would be better to start organizing the teams in the way we wanted to have, well, in the same way, that the structure of the organization should rather reflect the structure of the architecture we wanted to have, rather than starting from existing teams and telling them, 'Follow what's written as architecture on paper.' And there are other people who don't fit into the lineage of Inverse Conway Maneuver, who have roughly the same idea. In 2017, you have Yann Bosch, who is a professor at Chalmers University of Technology and former VP of Nokia Research Center, who wrote in 2017 an article called "Structure It Strategy." And he explains the BAPO model. The BAPO model is to say that the starting point of everything is the way we want to create value for our users and the way we generate revenue. From that, we make architectural and technological choices to meet the needs, which is the A. Then, once we have defined the architecture, we will define the tools, the ways of working, what we will call the P. And once we have the B, the A, and the P, well, we create the organization. And he notes that generally, companies are not BAPO but OPAB. So completely the opposite. Who starts from an already established organization? Then will determine processes out of pure convenience because, well, we already had an organization. So it suits us. And that unfortunately these processes will create an accidental architecture. which will be restrictive and which will limit the teams in their way of innovating and potentially creating new commercial offers. Once we have defined the architecture, we will define the tools, the ways of working, what we will call the P. And once we have the B, the A, and the P, well, we create the organization. And he notes that generally, companies are not "BAPO" but "OPAB". So, completely the reverse. It starts from an already pre-established organization. Then it will determine processes purely out of convenience, because, well, we already had an organization. So that suits us. And that, unfortunately, these processes will create an accidental architecture. that will be restrictive and that will limit teams in their way of innovating and potentially creating a new commercial offer.
[00:39:24] What's quite funny to note is that in '98, Nigel Bevan already gave good practices for better... for a better user experience. So he gave several. Finally, he gave an ordered thing. by saying, first, define the business objectives, the site structure and its content, the page design, the evaluation methods, which are the metrics.
[00:39:47] How do we validate mock-ups with our user panels, etcetera? And then we organize ourselves. And what's very funny, well, actually, in management, he goes a little further, he says for each of the pages, we need to see what skills and what level of competence we need. For example, this page is static, that one is dynamic, there's CSS, there's HTML, in short. And once we have that, we organize ourselves. And what's really funny is that if you take the BAPO model, it matches.
[00:40:17] So, here we have a little bit of a meta process, but what can we do, let's say, at each step? Because it can be very physical. Well, what can we do to ensure that we correctly identify the business, the architecture, the process, and the organization? Well, there are gems popping up a little everywhere in the IT zone, and I'm going to present a few of them.
[00:40:40] The first is Domain Driven Design.
[00:40:44] People who know Domain Driven Design in the room, great. So it's a book that was written in 2003 by Eric Evans, which started from an observation. He said, in fact, people are fighting the wrong battle. They haven't understood where the complexity of the software was. Well, not all the complexity of the software. And he misses the essential complexity, which is the business. So now we're going to create a philosophy that puts the business of development back at the center. And we start from the business only to then arrive at an architecture. So how do we proceed?
[00:41:17] First of all, Domain Driven Design separates two spaces. If you were at Kenny's conference, he talked about it a little bit. He says that the space... well, the problem space, we're going to separate it from the solution space. The problem is that generally, people confuse the two. They have the impression of analyzing the problem while they are building a solution, and that is very problematic because it biases.
[00:41:37] So we're going to separate the two, and so the problem space corresponds to the business, the solution space to the architecture. And the Domain Driven Design, in its toolbox called strategic patterns, will offer us ways to analyze both. The first thing to do, so the business, is to map the need, the problem. And we're going to do it with business experts. And the advantage is that we don't need a big organization for that. We take the business experts, we put them in a room, we take multidisciplinary profiles who will be in charge of starting to analyze the solution. And we put all these people, all these wonderful people, together. And the goal, well, of course, is to understand what the need is. Generally, it's done by means of a workshop called Event Storming. Event Storming was invented by Alberto Brandolini. And an Event Storming consists of listing the domain events, so the events that are important for the business, and ordering them. By doing this, we write here the value creation flow for our users. Then what we're going to do,
[00:42:46] well, mechanically rather, these ordered events will bring out business concepts. We're going to list them. Here, for example, you have catalog, item, cart, price, order, payment.
[00:42:57] And for each of these business concepts, we're going to analyze their lifecycle. We're going to see how far, in fact, they are present and how long they live. This will create boundaries. And these boundaries, we're going to call them bounded contexts. Or those business contexts. For example, here you have a shopping context and a payment context. And there, you're already starting to hit on the architecture. In fact, here, what you have is already a first version of your sub-systems.
[00:43:27] Afterwards, we can go even further. That is to say, with the context map, we are able to explicitly define the relationships between these sub-systems, between these bounded contexts. So for example, here, my OHS is Open Service, and to simplify, it's an API. And we're going to say, for example, that shopping needs user. Well, user information. But what we want to be very careful about is that the business model of user, we don't want it to pollute shopping, so we're going to put something called the anti-corruption layer. I'm not going to go into detail, but it already allows for considerations, let's say, of functional architecture. But it goes even further, because we're going to put the power dynamics between each
[00:44:08] of these sub-systems. We can say, for example, there's an upstream-downstream relationship. What does that mean? It means that user here, it can live its life and be successful independently of shopping. But if user fails, it takes shopping with it. But the reverse is not true, that is to say that shopping absolutely needs user to not be in failure. If user fails, it also fails. But the reverse, sorry, what I wanted to tell you is rather that if he fails, user is fine. Well, it doesn't care. We can go even further. We can say, and if we already have a team topology, in fact, the relationship between these two contexts is that for shopping to ensure that it can use... well, have the information it needs from user, with a... here the relationship is of the customer-supplier type, so it will be necessary to prioritize in the user backlog the needs of shopping. Because otherwise, they will never be able to go into production.
[00:45:05] And it goes even further because we have partnership, we have conformist, I won't do all of them. But here we are already starting to scratch a little bit of the P of BAPO.
[00:45:14] So with the strategic Domain Driven Design, we will be able to map the business with an event storming, to bring out bounded contexts, so a functional architecture, and to highlight the power dynamics between contexts and the eventual communication processes. However, the strategic Domain Driven Design does not give you much insight into how you organize yourself. And whether it's one team per sub-system, or several sub-systems for the same team. And besides, Domain Driven Design completely misses the functions that are a little more support-oriented towards the business. For example, the teams that are in charge of deploying the company's infrastructure in terms of network. All of this is not discussed in Domain Driven Design, nor how to be ultra flexible in terms of organization. But fortunately for us, in 2019, Team Topologies came out. Now there are other methods, but I'm going to talk about Team Topologies, which deals with P and O. And in fact, Team Topologies takes things in a slightly new and different way by saying that we need to limit the size of the software to the cognitive load that a team can handle. And that's quite new. Which means that the goal here is to make sure that the team can safely manage all the software needs, deploy it, maintain it, build it. If they do too many things, they will drown. So we need to restrict the software, or at least their tasks, to the cognitive load that they can manage. And they went and analyzed the types of teams that are generally found in companies, they analyzed four of them:
[00:46:53] the stream-aligned team, which we will rather assign to bounded contexts that are there to create business value. These are multidisciplinary teams that are autonomous in the way they create the software, develop it, maintain it, and deploy it. There are other teams, the enabling teams, which can be, for example, coaching teams that are there to help others improve their skills. And the goal of the enabling teams is to reduce the cognitive load of the stream-aligned teams. As much as the platform teams. Platform teams, for example, if you asked a business team that really does business, in a case where it's not IT for IT. To learn Kubernetes, for those who know. They'll never get by. It's too complicated, and on top of that, doing it well is very, very complicated. So it's better to have specialists who will take care of this, who are also called, if you know Domain Driven Design, rather obligatory complexity, manage it and provide it as a service to the rest of the company, especially for the stream-aligned teams.
[00:47:53] And then there are complicated sub-systems that I won't talk about here, because it's complicated to talk about them.
[00:48:00] Wow, thank you. But in fact, the complicated sub-systems, to say a few words, are rather composed of components that need a very high expertise.
[00:48:10] quite specific expertise, notably, you need data scientists, and it's the only place where you need data scientists because they're going to do fraud detection, and these are roles that you don't necessarily want or need to distribute among all your teams.
[00:48:24] And so they have a very specific cognitive load because it's very high in terms of technicality.
[00:48:30] And Team Topologies, how will it help us there? Let's say we take our system again with our shopping and payment teams. And they feel that it's starting to scratch at this story of, wouldn't there be a few responsibilities riding between us and you there, we even have the impression that you're doing a little bit of what we wrote. They can go into a mode that we call in Team Topologies, collaboration. The collaboration mode means that these teams will work closely together for a certain period of time and in such a way as to begin to tackle a complexity, a new form of complexity that they are not used to tackling. Which means that the cognitive load will increase for a certain period of time. And potentially, they might then determine that the best solution is to switch to this. Assuming we have understanding management, and we explain to them, well, here's a new system, there's all this work and everything. If they decide, okay, to create a new team.
[00:49:31] Here we're going to move into another mode because we have defined the responsibilities, we have defined the interfacing needs, for example, shopping.
[00:49:39] Pardon, checkout needs shopping, payment needs checkout, in terms of information. Here we move to a relationship they call X as a Service. Which means that shopping provides a service to checkout, and checkout provides a service to payment. And these rules actually allow us to say, well, we're going to limit the communication load because here there's a documented service and so on. And there's an interface constraint that has been negotiated with checkout. There are other things we won't go into detail about, like, for example, well, facilitation. Or you can have an architecture team that helps the checkout team improve its skills because, for example, it doesn't know microservices or it doesn't know DDD. But anyway, so there, in fact, I'm giving you, sorry, I'm talking about Team Topologies quite quickly, but it's just to explain to you that it's a dynamic organization pattern that pays attention to the different cognitive loads that exist in the organization, distributes them and gives you possible interactions. There are three, those are these.
[00:50:40] An example of Team Topologies at Docker. So we're not used to it, it's a bit difficult to read, I admit.
[00:50:48] And now, what you've seen, oh, sorry, I missed my... but it's okay.
[00:50:54] So, what you've seen today is Conway's Law, which says that organizations that design systems are constrained to produce designs that are copies of their communication structure. You've seen that user experience, product conception, product quality, and code and architecture can be greatly impacted by the effects of Conway's Law if we don't pay attention. But now, since you have the Conway reverse maneuver, with the BAPO supported by strategic Domain Driven Design and Team Topologies, you will be able to manage Conway's Law as best as possible. Well, sorry, the effects of Conway's Law. So what I forgot to say is that Team Topologies, of course, wants teams to be organized according to the value creation flow. That's why it pairs quite well with Domain Driven Design. If you are a bit reluctant, know that Accelerate, which is a scientific study that came out in 2018, will corroborate a little more, well, for this one, it's rather Conway's reverse maneuvers. If you've never read this book, I strongly encourage you to go and check it out. So just to finish,
[00:52:07] you have to be careful because the Conway reverse maneuver is not a silver bullet, it's not a... how to say, it's not a magic wand. In fact, it's not because you're going to reorganize that magically the system is going to change, in fact. Because if your design is rigid, changing the organization will have a very limited impact. And that's what Mathias Veras, sorry, Veras says in his article called Conway's Law doesn't apply to rigid design. He explains that, in fact, what you need to be careful about is that if you're on a very old monolith and you can't modify anything in it, the organization will cost you a lot for very limited effects. So you must first invest in the design effort and the sanitization of the system.
[00:52:54] before hoping to be able to organize yourself. It's not magic, that's what you have to understand. So Conway's Law must be seen as a constraint. If you cannot change the organization, in fact, it's rather your architecture that will have to adapt. Because the organization, it's not always at your disposal, you're not necessarily the decision-maker on the architecture.
[00:53:15] And the Conway reverse maneuver is just a tool that is not a silver bullet.
[00:53:24] So my name is Julien Topsue, I'm a tech coach at Xodo, which is an ESN and a studio specializing in software craftmanship and Domain Driven Design. And in my great kindness, I brought you to the belfry of Montrouge. And pay attention to your beliefs, because otherwise, you risk being stuck in the IT zone. Thank you.

Transcript (Translated)