Transcript
Peter Hunter: Physarum polycephalum, so this is also known as slime mold. Scientists discovered this funky, yellow, single-celled organism is pretty good at making decisions. What they did was they placed food sources in locations relative to cities around Tokyo, and then added slime molds to see what would happen. The slime molds spread out, and they detected locally for nutrients, repellents, making local decisions about which direction they would go in search of food next.
Over time, what they saw was a network of nutrient-carrying tubes that looked remarkably similar to the Tokyo subway. In some places, it was more efficient. Slime molds created a complex and efficient network independently and without a central decision-maker. This is QCon, so why am I telling you this? Architectural decisions are often centralized, sometimes from an ivory tower. I think we want to see if we can learn from slime molds.
Our Journey (Open GI)
Before we do that, I'm going to take you on a journey. Our journey started back in 2020. It was in the midst of the COVID pandemic, and we were wrestling with another problem. Another problem you've all probably dealt with. A legacy solution with multiple code lines, mixed versions of .NET, and different libraries and packages scattered around. We had manual deployment, so we were manually deploying our solution with Windows installers, copying files, prone to error, manual changes to environments. Ultimately, it meant a slow lead time. We were going into 3-month to 6-month release cycles, UAT, cycles of bug fixing, and we just weren't delivering any value to our customers. We set out on a goal. Our goal was to re-architect to a cloud-native SaaS platform and adopt some modern engineering practices. For this journey, I was lucky to pair with Andrew, and our track host, who joined us and showed us a new way of doing architecture.
First of all, we started on Zoom to have a conversation about the books we'd been reading. The first book that Andrew or I, waved excitedly in front of the webcam was "Team Topologies". We set about setting up our teams for fast flow. We had three product engineering teams. We had an enabling team. This was a team of SMEs and experts that would support our product engineering teams. Then a platform team. The platform team at the beginning was a re-platforming team, but that then turned into our platforming team that now supports our engineering teams and reduces the cognitive load for them. The next book was, "Accelerate". There's 24 key capabilities that were highlighted based on the research that DORA did. The two that I think are important for this story are the loosely coupled architecture and empowered teams.
To support fast flow in the teams, we needed a loosely coupled architecture that we could spread across those teams. We wanted to empower our teams to solve problems in the best way that they could. This is where the advice process came in. If anyone follows the Thoughtworks Tech Radar, they'll know that the advice process has just entered the quadrant under techniques in trial, I believe. We needed to think about architecture in a slightly different way. We needed to have a process that would support our empowered teams and our stream-aligned teams. The advice process says that any team can make any decision they need to, as long as they have sought the advice from all meaningfully affected parties, and those with expertise. That they record these publicly alongside reasons for going against it if necessary, so pros and cons. It's that simple. There are tools that sit underneath the advice process, tools that we use. Some of these you'll have heard of. We'll go through in a little bit more detail.
The Context Map
Before we do that, we're going to take a slight detour, and Elena is going to talk to you about something that we lovingly call the context wars and how we went about splitting up our platform across the teams.
Elena Stojmilova: Our product engineering team, we started with three of them. We inherited and shared a 15-year-old legacy platform written in mostly old technologies and different architectural styles. In some of them, we also have single-tenant desktop tools. As Pete mentioned, our goal was to move to a cloud-native multi-tenant SaaS platform and change our ways of working to improve our software delivery performance while doing that. In order to enable the team to work independently, but also to improve the fast flow, we needed an approach so they can understand the whole system, but on another side, to be able to identify loosely coupled business areas within that system on which they can start work independently. We created a context map. What is a context map?
It is a diagram or just a visualization of all the areas within the system and the contracts and relationship between them. How did we create our context map? We did that by applying the domain-driven design principles and identify loosely coupled business focus areas that are known as bounded context. We mapped the relationship and contract between those contexts. With that, we have the context map. The next step was to assign ownership for each of those bounded contexts. We did that by defining which of the teams will be responsible for each of those bounded contexts. What that responsibility means. It means that the team will be responsible for any re-architecting, any new feature development that will be happening within that context, but on another side, also, any new bug that came from that area will be the team's responsibility to be fixed.
This sounds really straightforward and easy, but it wasn't like that. For us to define a context map for a legacy system as ours that still has a lot of complex dependencies and contracts between different areas, it is really challenging. We didn't want it only to identify loosely coupled areas within our system, we wanted them to be aligned with the business flow, so everyone in the company can use the context map. Not only the engineers, but also the QAs, the product, everyone who wanted to gain a general understanding of the software architecture and also to different parts, which team is owning it. Context map definition is not one single step work, it needs to be reviewed a couple of times, and you need to do that constantly in order to be sure that that alignment is met.
Even if we have reviewed our context map a couple of times, we still have gray areas and shared context. What are gray areas? Those are parts in the system that do not have a clear ownership or cannot be identified as independent bounded context or cannot be seen as a part of existing bounded context.
On the other side, we have shared context, and those are contexts that are shared between different teams or maybe between all of the teams. The context map itself, and together with these gray areas and the shared context, sometimes can become a source of frustration for the team. It can create, as we are calling them, context map wars, and those are especially happening when some complex, urgent bug arises and it is somewhere in the shared area or in the gray context.
The context map itself came with a lot of benefits from us. To define all the complex dependencies between the different bounded context will empower the team to be fully aware of the impact of their decision. Whenever they need to make some decision or change within their bounded context, by reviewing the context map, they will be fully aware, what will be the impact, which bounded context will be affected, which team they need to ask or collaborate with. That will lead to more collaborative decision-making process, but also will motivate the team, and they will start to think, can we remove some of those dependencies? That will lead to more loosely coupled architecture.
The gray areas and the shared context are a great insight that those parts of the system need some re-architecting. It's really important to identify them, and whenever you're struggling, to identify a clear context or clear relationship between the contexts, you need those areas to be marked as technical debt and to prioritize their resolving, because as soon as you do that, that will make everyone's life easier. The context map itself will bring the ownership of the teams. They will start to build that ownership for their assigned context, and they will start to work independently.
When the teams start to work independently, they will also be in a situation where they can plan their work independently, and I think that some great results will come from that independence. We have our team set up. We have context map defined. Each of the teams was assigned ownership for each of the bounded context, and the team started working independently, and we started making decisions independently. This new level of autonomy was new for everyone, and we needed some supportive structure here, and that's where the advice process came in.
Architectural Principles
Peter Hunter: One of the first tools or practices within the advice process is the architectural principles. A principle is a core idea that guides how we think, act, or build something. The way we went about collecting our principles was to first look at our business strategy. We had a collaborative session, with various experts, SMEs from around the business. We presented the business strategy, and that was then how we shaped our principles. With a shared understanding across engineering, QA, architecture, we would then create principles that would guide us. They would act as the dotted line and the shape around what we were building. They would also then help us influence our architectural decisions. They would guide our decision-making. Here are 16 architectural principles that came out of our workshop, and I'll take you through one. This is our isolate tenant database, so this is an example principle that we actually use.
The first point is clear statement as to what the principle is. Make it super clear what you're trying to achieve with this principle so that anyone can read it and understand within a few seconds what the principle is defining. We talked about business strategy, so we link our strategic goals from the business strategy to our principles. We make sure that there's a link back to that business strategy.
Again, we want these principles to guide our decision-making. Rationale behind it, so the benefit. Again, this isn't war and peace. This is meant to guide decision-making. It's meant to be as succinct as possible so that, again, people can consume them quite quickly and also remember them, because that's fairly key. Then the implications. Some principles will have implications. Some of them positive, some of them negative. In this instance, it increased hosting costs because of our approach to tenancy. Just to recap, architectural principles, they help align us to our business strategy. They create a consensus across the team because they're formed by the teams. Then they become the foundation of our decision-making.
Architectural Decision Records (ADRs)
The next tool that we're going to talk about is the ADRs, and this is how we go about documenting those decisions.
Elena Stojmilova: Decisions are the core of the software architecture. Practicing software architecture means working with decisions. Also, software development is a constant stream of decisions. We have adopted the decentralized decision-making process, and that means that everyone will contribute to the architectural decision. Everyone can make an architectural decision, starting from developer to architect.
For this approach, it's less important who made the decision or how long it took to make the decision. It's more important to identify if the decision is architecturally significant and will impact the system now or in the future. We want those decisions to be recorded, to be shared, and to be asked for advice. Why do we want to record the architectural decisions? Because by recording the architectural decisions, you're capturing the why behind every what, and with that, you're creating great context for future learning and sharing understanding.
To support the process of recording the architectural decisions, we have introduced architectural decision records, or ADRs. How many of you have heard or used ADRs? Architectural decision records are short documents that have a defined format, and they are recording a single architectural decision, and most importantly, the rationality behind that decision. Each of those documents can have a different format. I will share the one that we are using. Each of our ADRs have a unique identifier and title, that is the decision itself. We are also recording the author of the architectural decision records. They came mostly from the teams, and it's the team lead that is reading the ADRs. They can be in one of the five statuses, new, draft, proposed, adopted, or superseded. We also have a section to record the decision, and it needs to bear the decision itself: short, self-explanatory, in one or three sentences. Whenever you're just reading the ADR, by reading this section, you will get the general understanding for what is this ADR about.
We are listing the relevant architectural principles, the ones that Pete mentioned, and that guide us in the process of making the decision, but also ensuring that our decision is in line with the overall architectural vision. The ADR context, here we are recording the factors that trigger the need for the decision to be made. The alternatives considered, all the options that were considered, the pros and cons for each of them, and why they haven't been the chosen one. The consequences of the decisions, the positive and negative, the benefits and the downsides from the decision itself. Most importantly, we have a section to record the advices. We are recording the advice itself, the person who gave the advice, and the date when the advice was given.
ADRs are here to support the recording of the architectural decision. For me, they are most useful because they guide you in the process of making the architectural decision. Because when you're starting firstly with making the architectural decision, you will be struggling, and you will not have the confidence to make the decision instantly. Whenever I need to make an architectural decision, and I don't know from where to start, I start by drafting an ADR. In the context section, I'm reminding myself why the decision is needed, and what is the problem that the decision will resolve. After that, I'm going on the options section where I'm listing all the options, and the pros and cons for each of them, and also aligning them with the architectural principles. It's also good here whenever you need some additional investigation to do some additional exploration for some of the options.
For example, you want to introduce a new technology, and you're not sure how that will fit with your existing architecture. You can raise a spike, and the teams can do the investigation. They can share the learnings, and you will be more empowered, and you will have more confidence to make the decision. Once you are ready, you're making the decision and recording it together with the consequences from it. It's time to ask for feedback or advice. When do you ask for feedback or advice? You can do that before or after deciding. It depends on the nature of the decision.
If you know that the decision will be impactful and will impact a lot of other different parts of the system, or maybe you don't have the business or technical knowledge and confidence for making it, it will be better if you ask in the process of making the decision, and in that, you will get more knowledge and you will create a better decision. Because once you've made the decision and changed the status of the ADR to adopted, you cannot change it, because the ADR says the documents are immutable. It can happen in practice that you need to change the decision, and if you need to do that, you should change the status of the previous ADR to supersede, and create a new ADR with the new decision. Saying that, that means that the number of ADRs will grow instantly, and over time.
It is really important to keep them centralized and organized so everyone in the company can access them, can be informed, and also can contribute to them. We started with wiki pages, but moved to work items for better management. In almost 5 years now, we have created more than 200 ADRs. It's also useful to have a notification system, for the team channels or for the emails, so whenever someone is creating a new ADR or is updating an existing one, everyone will be notified. ADRs will act like a living document for your documentation, for your project, documentation that we're all trying to avoid writing. It's really important to define the format of the ADR to be in line with your project needs and also to force everyone to follow that format.
For that, you can introduce a template. We have the ADRs to record architectural decisions. They guide us in the process of making the decision, but they are most useful when they are shared and when we ask for feedback and advice for them. We are sharing our architectural decision records on the Architectural Advisory Forum.
The Architectural Advisory Forum (AAF)
Peter Hunter: The AAF, the Architectural Advisory Forum, is our weekly meeting. It's open to anyone, so all teams, architects, QAs, SMEs. There are no restrictions on who can join. We have a set agenda. The first two parts I'll go through is we have our upcoming spikes. There's a correlation between spikes that the teams are doing and future decisions. They're sensing out the changes, they're looking at the options. By sharing those upcoming spikes, we give early visibility to all the teams, so, again, they can give better feedback when the decision comes or before the decision comes. The next part is the upcoming ADRs. This is a list of the ADRs that people want to present. We talked about previously, we get notifications to say that ADRs are coming. Some people read them. Some people may not have had the opportunity. This is an opportunity just to present them quite quickly and open up for any questions. Two other agenda points that we have. We actually also have our DORA metrics.
At the beginning, I mentioned Accelerate and some of the practices that we're using. We've included the DORA metrics and our Azure spend because we think that both have a correlation with some of the decisions we make. Again, by checking that weekly, we can look at some of the impact of those decisions, whether it's a change in a resource and the cost goes up, or the cost goes down, if we're lucky. Again, making some of this visible. I think also since this screenshot, we've also added some extra SLO dashboards that we show as well. That's the advice process. We've got architectural principles, which guide our decision-making. We have decision records to track the decisions that we make, and create a record and a history of that. Then we have our Architectural Advisory Forum, where we share those.
The First ADR, and AAF (Open GI)
Let's take a look at our first ADR and give you a bit of a feeling of what that felt like.
Elena Stojmilova: My team had the opportunity, but also the responsibility to be the first team to make the first individual architectural decision, record it in the first architectural decision records, and share it on the Architectural Advisory Forum, and ask for advice. It was quite an experience. Let's take a look at how that went. Within the context map, we were assigned, for our ownership, a line of business context that is quite a complex context in our legacy system that we inherited, and lives somewhere in the middle of the system, and has a lot of complex dependencies and relationships with all the other different bounded contexts. What were the challenges that line of business context has in that architecture? We were using a single-tenant monolith desktop tool to create and also manage the line of businesses. We also experienced a lot of quality issues with it.
Despite the capabilities of these tools, there were also a lot of limitations and there was a need for frequent development intervention. We had a slow lead time and we were releasing to production really slow because of the nature of the architecture. Also, there were a lot of performance bottlenecks within this context. How do we see the future? We introduced the line of business as a microservice with its own datastore and default configuration. With that said, we introduced a duplication of the existing tool, desktop tool that was used, and this was written by Pete. We made the decision, we recorded in the ADR, and we were making a lot of architectural transformative issues with it. We introduced the line of business as a microservice, and that means that all the principles for microservices will be applying for the line of business also.
One of them is to have a single Azure Cosmos DB for microservices, and with that we introduced a move from one shared SQL database to multiple Azure Cosmos DB. All the other bounded contexts were still relying and having dependencies on that one single SQL database, and there was need for data synchronization and dual write in order to manage those dependencies in those contracts. We have our line of business as a microservice and that means that it will be independently deployable and scalable unit and will improve the lead time, and we will release to production in a short time.
We made the decision, we recorded it on our first ADR, and that was quite new for everyone, and brings a lot of challenges and a lot of emotion for everyone in the company, but mostly for me and Pete as we were leading the process but from different perspectives. For me, at the beginning, when I was doing the first architectural decision, I was quite excited, because I think that every engineer will have the power to work with the architecture and be empowered to make architectural decisions, will feel the same. I felt like I'm doing shopping and everything was on sale, and I wanted to try everything. I wanted to introduce every new technology and every new architecture style that I have read.
On another side, I was aware that that was quite a big responsibility and there were a lot of things that needed to be decided, a lot of options that needed to be made. I was quite aware of the impact of the decision because the line of business was complex context. I was quite aware that we will impact a lot of parts of the system and a lot of teams, and we will need a lot of conversation with the affected parts in order to understand the dependencies and solve them. I also remember that I contacted Pete during that time and I was hoping that he will give me the right direction, he will help me choose what is the preferred option, what is the best option, but he didn't do that. We just went through all the existing options. We went through the pros and cons of each of them, and he let me and my team make the final decision. How did that feel? How did it feel to not be the one making the decision but also not be the one influencing the decision?
Peter Hunter: I felt like the first test driver in a Tesla with autopilot on. I took my hands off the wheel and I was just praying that I wasn't going to crash into anything. As the person that was responsible for the program of work and across those three teams, it's scary. We all have our opinion of how we would do this. Partly, I was biased by the fact that, as Elena mentioned earlier, the tool that she was replacing, I originally wrote and I thought it was still pretty good. I was, again, biased on that. It was a lot of work to stay out of the decision. In actual reflection, I probably stayed out more than I needed to. I think I was over-indexing on not leading the witness. I didn't want to undermine the advice process, and this is something Andrew and I talked about a lot. It was keeping our powder dry, not reacting to some of these decisions. It's hard, but it was going to work. I was convinced it was going to work.
Then, I was distracted by all the messages that started to come in. Everyone got the Teams notifications to say there was new ADR. Everyone had an opinion on the new ADR. I started to get messages, but it's not my responsibility anymore. I was trying to not respond, but push them and channel them back to Elena and Barry, who was her pair. All these messages, I was just pushing back on and just saying, "You need to take this to the ADR. You need to give comments on the ADR, or go along to AAF". I think those messages continued on AAF.
Elena Stojmilova: We were practicing the advice process and we shared our ADR on the Architectural Advisory Forum. It was a short presentation, 10 minutes, but I think that the meeting itself was really long. I think it may have been an hour and more, because there were a lot of questions. It was a dynamic discussion. We were introducing a big change and it was a big decision. Everyone had their opinion, and that was really great because that was one of the reasons why we are sharing the ADR. It was hard to follow everyone, and to understand their views and their feedback.
In order to practice the advice process, we asked people if they can leave their feedback and advice in the section for the advice on the ADR itself. They did that. This is just some of the feedback or the advices that we received. They are quite massive. There were a lot of different opinions. We continued the conversation offline. We did the conversation with the people who gave the advice and tried to understand their views and consider their feedback. I must say that there were a lot of feedback and advices from people that strongly disagreed with the approach.
On our side, there were people who liked the idea, but challenging it and also shared their concerns about it. This feedback made me rethink my decision. I was constantly questioning myself. Is this the right one? Should we change the approach? There were a couple of other options that we could choose, but my team and myself, we didn't change the decision. We changed the ADR to the status adopted, and the team started to implement the decisions themself.
Reflecting now on that first ADR, I will say that for this one particularly, we missed the stronger connection to the product vision. Because we were not doing only the architectural decision with this ADR, we also did some product decision, and we introduced a product change. Not everyone included in the advice process were aware of the overall product vision. With that, they weren't able to give us more effective feedback that would help us in making our decision better and more in line with the product vision.
After this first ADR, we started writing product decision records and linked them with the ADRs, but for the ADRs that there was a need. Given what I know now, I will probably not do that same approach. I will do a more iterative approach. I will try to do more smaller decisions, create multiple ADRs, and ask for feedback from them. That will give me more flexibility and will enable me to receive faster feedback and probably will lead to a better decision-making process. Something that has become practice for me now is to try to get more advice during the decision-making process, not waiting and asking for advice or for feedback on the Architectural Advisory Forum itself. Do that while you are in the process of making the decision.
Collaborate and ask for advice and feedback from the teams that are affected by your decision or the people that can help you with their domain knowledge, business knowledge, or technical knowledge. Make sure that you are receiving advice or feedback, and you are not receiving opinion. Because most of the people will try to influence with their opinions and they can try to convince you that their option or their opinion is the best. You need practice distinguishing between the advice and the opinion. After this first ADR, we continued practicing the advice process. My team continued writing an ADR. Also, the other teams did that. Let's look at how practicing the advice process looked in the past and how it looks now.
The Decision-Making Roller Coaster
Peter Hunter: It's a bit of a roller coaster. I think that what I've seen is that there's four distinct phases: new people, new teams. Since having three teams, we've gone to six. We've added new teams into the mix. They all seem to go through four phases. I'll walk you through and just explain those. The first one is when they don't realize they can make a decision. They're so used to being told what the decision is that they don't think they can. They're going, are you sure we can do this? Are we ok to do this? Do you approve of this? We still hear the language that is, they're still seeking someone to give it the rubber stamp, and it's not coming. Andrew and I had to talk to each other a few times about going to a dark room, and go, "We're not approving anything, we're not approving anything. Pete, don't use the language". We had to hold strong so that we could break this Stockholm syndrome. We can move away from us making decisions, and the teams making decisions.
As soon as they realized that, it came to life. We saw the decisions start to flow. They were looking at new technology, new frameworks, new libraries, new practices, new patterns. It was exciting. The process came to life. We were excited. We could see it happening. There was a lot of energy around it. Then we moved into the next stage, which is where the teams, and much like us as architects have been through this, we start to feel the impact of our decisions.
As Elena mentioned, it was quite a big decision, the first one. There was probably a lot more in that decision than perhaps you would make now. I think this is where the teams start to realize. That's ok, because we've all been through it. We've all made good and bad decisions. It's definitely a trend that they go through. Then the system starts to correct itself. It starts to work. You're in the sunny uplands. Teams are holding each other to account. They're questioning decisions. They're giving feedback on the decisions. They're searching out feedback. Actually, teams are bringing well thought-out ADRs to the Architectural Advisory Forum. What we now see is that the teams are providing the guardrails for new teams joining, for new people joining. We're in a better place. From your perspective, how do you feel about this?
Why Should You Do This?
Elena Stojmilova: Why should you do this? Because it will improve the trust and transparency. Teams will need to be trusted that they will make the right decision. Maybe not always they will do the right decision, but they need the trust that they will do everything to make the best decision according to the consequences and the situation in which they are. Also, they need to promote transparency. To share their decisions, transparency. To ask for advice and feedback from them. Also, it will help you have better alignment between teams. I mentioned that the teams will work independently and they will build the ownership for their bounded context. The architectural principles will guide them to follow the overall architecture vision, and teams need to be reminded, and they will be reminded that they are working on the same product at the end. They don't need to work in silos, they are working on the same product, but they are only making decisions about their context. This decentralized decision-making will lead to more stronger architectural decisions because they will be more collaborative, and they will be shared, and they will be really better. It will support also the fast flow team. They will start work independently and faster. What about architects?
Peter Hunter: How many architects are actually here? Your jobs are safe. You saw AI was coming after your jobs, now you thought slime mold and engineers were coming after your job. That's not the case. Teams still need support. They don't have some of the experience that you have. You can also help them with facilitation, so things like event storming, threat modeling, risk storming, all of these exercises and workshops, they still need support and a perspective on. You're also the conduit between the teams. When you can see a decision being taken in a team and perhaps another team hasn't spotted it, you can then act as that conduit to support the knowledge and information flow between teams.
You can get involved in the gnarly problems, so the really interesting ones. You've freed your time up to actually get more involved with some of the ones that excite you, the problems that excite you. You can support, again, the teams in solving those problems. If you'd like to learn more, check out this book, "Facilitating Software Architecture". It is awesome, because of the content. I'm going to leave you with one thing, be more slime mold. Empower your teams, decentralize your decision-making, and achieve your shared goals.
Questions and Answers
Participant 1: I was just wondering, after you created all of your architectural decision records, how many times do you actually go back and look at them again? Something that we've struggled with is how do you organize those things so that it's easy to find the record that correlates to whatever the thing is one year later that you're trying to make another decision about. You think, there was something in the past couple of years ago that probably relates to this, but I can't remember what it was called and where it is, and all the rest.
Elena Stojmilova: That is one of the benefits from the ADRs itself. They also will become a shared documentation for your project. I have mentioned that we are keeping ours in a repository. They are work items. By just searching them, you can review them, and find them. It's easy because we are using Azure DevOps and you can just search as any other work item. It's really important for each of the teams to be encouraged to do that because they will learn from the previous ADRs and they will learn from mistakes from some of them and also from successes from some of them.
Peter Hunter: I think one of the first things you do is you do search those ADRs to see if there's one that aligns with what you're thinking, because one of the benefits of the ADR is it will show the pros and cons and alternatives. It does some of the research for you. If you're thinking about using a service and another team has already used it, you can stand on the shoulder of giants and look at what they've already done.
Participant 2: Are you keyword tagging those things?
Peter Hunter: We use Azure DevOps, so it's really easy to search. We don't need to. Again, the title's fairly clear, but you can search the entire content.
Participant 3: We use ADRs quite a lot. I'm just wondering, how many of those gnarly problems that you spoke about are down to decisions you didn't agree with?
Peter Hunter: There's lots of ways to solve problems. The problem is until you find that problem, you don't know what the cause is. I think I could sit there smugly and say I would have done it slightly differently, but I still don't know the full outcome of that decision until it materializes. Until I've actually made a different decision and then followed it all the way through, I don't really know. I think you just have to accept that it's a different path that was taken.
Then you've also got the opportunity to feed back. If you didn't give the feedback, then I would reflect on yourself as to, you could have given better feedback at the time. Maybe you need to think about the way you're positioning the teams. Maybe that's why they didn't take your advice at the time. Maybe look back on yourself and go, maybe I could have shared a bit more information or some more context or some examples. I use that to reflect and try and make myself feel better about the decision.
Participant 3: Isn't that influencing the decision?
Peter Hunter: It is influencing the decision, absolutely, but they can choose to take that advice or not. If you truly believe something and you explain it well, then it will be based on facts. Therefore, they'll deal with facts when they're making the decision.
Participant 4: You mentioned you're using this process with six teams right now, and maybe this is answered in the book. Have you thought about how you'd scale it up to 15 teams or 50 teams across a bigger organization?
Andrew: Everyone asks, how does it scale? You could see it's maybe where Pete and Elena are getting to now. It scales to a certain point and then the social, the human being bit doesn't scale. Then you can have a modular way of doing it. There were other bits of where Pete and Elena work who wanted to adopt this, but we didn't make them follow the same, they're different principles, I think. They're different Architecture Advice Forum. Then I think it's joined together since, but they were doing separate programs of work, so they could be cross-fertilizing.
Peter Hunter: That's true. We do have other teams doing ADRs and AAF. They're all visible, so we can search them, but they'll run their own AAF because it's not necessarily relevant to the other teams. I think when we start to bring them closer, then we merge that into a single AAF and make sure that everyone's attending the same one.
Participant 5: Are there any highly impactful, paradigm-shifting decisions that you would not trust to a team to decide using this process? If so, how do you identify those?
Peter Hunter: They're all still decisions. At the end of the day, it comes back to, I'm still an architect. There's a bunch of other architects who are on the AAF. You still have to share your experience with them. I think our principles guide most of the decision-making. I don't think I've come across one. We haven't had anyone go, we're all in Azure, let's shift to AWS, as an example. We haven't had that. If that came along, they'd have to have a pretty good reason to move to AWS, and the ADR would have to reflect that.
Participant 6: At the beginning of your presentation, you show the context map with all the bounded context, and you said one of the first things you did is assign ownership. What was the decision criteria to assign ownership? I assume you don't have 20,000 teams. What did you use to assign ownership to teams?
Elena Stojmilova: Firstly, we identified the loosely coupled services within our system, and we tried to map them with the business flow. They can have a story. For each of that business flow, we have a team that was responsible for it. Having ownership for the business flow means that you're also having ownership for all the bounded context that are within that business flow.
Peter Hunter: I think one of the other parts is if we had engineers that were already experienced in that area, we would then pair them, or we would use our enabling team, and the SMEs there to support that team in understanding that bounded context.
Elena Stojmilova: We have reviewed the context map and ownership a couple of times, and changed the ownership because of that experience. If it came up that some of the teams will be a better owner for that context, yes, we were reassigning the ownership, if needed.
See more presentations with transcripts
