Chapter 4. The Architecture Advice Process

In the previous chapter, I talked about how these days decisions at scale need to be both decentralized and fast. I then showed how none of the various traditional decision processes could offer everything we needed, being either too slow or overly centralized.

In this chapter, I’ll introduce you to the architecture advice process—a simple yet powerful approach to deciding that is both decentralized and fast. I’ll explain how this process meets all four requirements for a modern decision process by involving the right number of people, optimizing the entitlement to initiate decisions, prioritizing trust, and minimizing the need to communicate decisions. I’ll also take you through two examples of it in action so that you have a better understanding of its mechanics and can see how you and others can participate in it openly and effectively. I’ll close by discussing the widespread positive impacts the advice process can have on both your software and your organization’s culture: not only removing blockers and increasing feedback but also promoting healthy, equitable communication. I’ll also show how the process delivers software architectures that evolve more fluidly and responsively. I’ve described these benefits in some detail so that you’ll know them when you come across them.

First, let’s remind ourselves why we need a faster, decentralized decision process.

The Need for a Faster, Decentralized Decision Process

There are clear challenges when it comes to using traditional approaches to architecture. When using ivory tower approaches, I found that I couldn’t focus on the relevant details. With the hands-on alternatives, I struggled with stepping back to see the bigger picture. And I failed miserably trying to be the best at both. I realized I was always stressed for three reasons:

  • My accountability and responsibility in decision processes meant I was blocking or at least impeding team flow.

  • My architectures might not be fit for purpose: I was unaware of how existing systems were running and the nuances of the current implementations.

  • My architectures might not be getting into production and staying there: I was failing to communicate them effectively.

All three of these were entirely due to the way architectural decisions were being made and taken: with me at the center, responsible and accountable, irrespective of whether my approach was an ivory tower or a hands-on one.

I asked around, speaking to colleagues, ex-colleagues, and clients, and discovered that although I wasn’t alone in feeling this way, no one had a solution. Is there a way to make architecture less about the responsibilities associated with a job title and more about architecture as a collective practice? Might there be an alternative approach that could take architects out of the critical but stressful decision path while still maintaining the practice of architecture at the core? Could there be a decision process that locates decisions in the right place, involving as few decision takers as possible (i.e., be fast), while allowing as many different individuals to make and then take those decisions (i.e., be decentralized)?

There is, and it sits in the coveted top-right quadrant of the speed/decentralization graph in Figure 3-9. It has the potential to remove all three stressors of the traditional approaches in one fell swoop.

The Architecture Advice Process: One Rule, Two Advice-Offering Groups, and One Contract

In Dennis Bakke’s book The Decision Maker (Pear Press), he describes an “advice process” that he devised at AES, a Fortune 200 global power company. It’s an incredibly simple, trust-centering process that is applicable to all flavors of decision making, including those that involve software architecture. As such, I call my version an architecture advice process.1

In the architecture advice process, there is a single rule: anyone (a development team member or someone playing a cross-team architecture role) can take (select a decision option) and communicate an architectural decision as long as during the option-making stage, they seek advice from:

  • Everyone who will be meaningfully affected by the decision

  • People who have expertise in the area in which the decision is being taken

This seeking of advice is a social contract that balances the rule. That contract is upheld by ensuring that the required advice has been sought, listened to, and understood. Once the contract is met, the decision taker is free to select the option of their choice and appropriately communicate it to the relevant parties. See Figure 4-1.

A diagram of a process Description automatically generated
Figure 4-1. The architecture advice process, where advice is sought and offered on in-flight decisions, initiated by either teams or cross-team architects as software flows to production

Being both fast and decentralized, the advice process (I’ll drop the “architecture” part of the name from now on) sits in the top-right quadrant of the response-speed/decision-rights graph I shared in Chapter 3, now updated in Figure 4-2. This might seem like a bold claim. Let’s unpack it a little.

A diagram of a political party Description automatically generated with medium confidence
Figure 4-2. Updated graph comparing the various decision processes in terms of decentralization and speed

The Architecture Advice Process Is Fast

I’ll start with speed. First, recall from Chapter 3:

The key factor in a decision’s response speed is the number of people who either contribute directly to the taking of a decision or can object to that decision after it is taken. The lower the number, the faster the optimal response speed.

In the advice process, the number of people involved in and accountable for the taking of the decision is one (or one team-sized group), and the number of people who can object—and effectively block the taken decision—is zero. That’s a pretty small number, and it’s the reason why the advice process is so fast!

Not only that, but during the preceding option-making step of the process, those driving the decision are seeking advice—but importantly, not permission—from those affected by it and those with applicable expertise.

Therefore, the need for broad consensus—or indeed any form of broad agreement—is avoided, and the advice process can reap the speed benefits of the autocratic, delegation, and consultative processes, which circumvent this issue in the same way.

It’s for this reason that I’ve placed the new architecture advice process dot on the graph in Figure 4-2 just slightly to the right of the consultative process with regard to speed. This is to reflect the fact that it probably involves the same number of people as the consultative approach but with the added sense of urgency because the responsibility for the decision comes directly from those who need it, with zero intermediaries.

A few words on how the number of advice offerers affects the speed of deciding might help.

First, the greater the number of “meaningfully affected parties,” the more people decision takers are obliged to seek advice from. While this sounds like a drawback, it actually sets up a valuable reinforcement dynamic: to make fast decisions, teams will look to reduce the number of affected parties they must turn to for advice. The simplest way to do this is to more sharply define a decision to reduce (or remove) the impact on others. This nudges teams to continually validate good system boundaries, rewards decoupling, and reduces the scope of the decision. (I’ll go into all these topics in greater detail in Part II of this book.)

And “those with expertise in the area”? Structuring decisions to avoid engaging experts is something you don’t want to do, but the architecture advice process changes the interaction dynamics here, too. Decision takers no longer need to convince experts of the reasons for a decision, so a rich conversation can take place from the beginning, with the sole goal of seeking and sharing knowledge and experience.

With the option-making and decision-taking steps covered, what about the third step: sharing the decision? In a centralized process, this sharing stage is another weak point. If a decision taker doesn’t share their decision with those who will implement it, nothing happens; all decision-process efforts were for nothing. If they share it but poorly, the implementation may bear little or no resemblance to the decision that was taken.

With the advice process, the people who make and take the decision are also the ones implementing it. The sharing step is simply getting back to the affected parties and experts and letting them know what the decision taken was. This is simpler because everyone was previously involved. It’s also derisked because poor communication at this stage won’t affect the implementation.

The Architecture Advice Process Is Decentralized

The main issue with traditional architectural decision processes—and hence in both the ivory tower and hands-on architecture approaches—is that their “center” is fixed. It is always occupied by a fixed group of named individuals: the architects responsible and accountable for the overall architecture.2 You can see this represented in Figures 4-3 and 4-4. All significant architectural decisions in both traditional approaches must pass in front of the architects, at least for approval, and frequently much more.

A diagram of a project Description automatically generated
Figure 4-3. When using ivory tower approaches to architecture, all development teams must defer to the architects for decisions, at least in the form of their approval
A diagram of a construction worker Description automatically generated
Figure 4-4. When using hands-on approaches to cross-team architecture, all teams must still defer to architects for decisions to be taken

In contrast, the advice process locates the center around whoever needs it, whenever it needs to be there. (This “center” can even be in multiple places at once.) Therefore, it meets the key need for optimal decentralization (I’ll come back to the ramifications of this again and again throughout this book):

The key factor in a decision process’s decentralization with regard to decision rights is the number of people who are de facto entitled to initiate and then contribute to the taking of decisions. The greater the number and the deeper their involvement, the greater the decentralization.

The essential words here are “de facto entitled.” The biggest downside of the most decentralized decision processes (such as democratic or consensus) is that they are always maximally decentralized; everyone is always entitled to contribute to the taking of every decision. Consequently, even in circumstances where everyone is aligned and on the same page with regard to consensus, simply letting everyone be heard on every topic can be at best long-winded. This happens because everyone feels obliged to participate, contributing what they can to both the making of the options and the taking of the decision. Why? Because if they stop participating, then they will be seen to not care or not know enough to offer opinions. At the extremes, what you find is that while everyone has an opinion, no one takes decisions. In these circumstances, not only decision speed but also accountability suffer.

Again, an advice process flips this. (As the renowned systems thinker Russell L. Ackoff would no doubt remind us, an advice process does not solve a problem—it resolves it.) There is now one decision taker, but that decision taker arises from the collective, wherever and whenever a decision is required. With the advice process, no one needs to seek permission to initiate this. As per Zuboff’s book The Age of Surveillance Capitalism, when deciding, it’s important to consider both who decides and who decides who decides. With the advice process, the answer to both questions is “whoever feels the need to.” It’s for this reason that I placed the new architecture advice process dot on the graph in Figure 4-2 between the democratic and consensus processes with regard to decentralization, reflecting both that anyone can take a decision if they see the need but that decision won’t have everyone involved in it.

So what about involving the right parties in the option-making and decision-sharing stages? The responsibility for both lies with the decision takers, which is the topic of the next section.

The Architecture Advice Process Gives Rise to a Social Contract

The core of the advice process gives rise to a mutual agreement, a social contract, which comes into play whenever a decision is required. If we were to write out this contract, it would say:

We trust others to make and take decisions, on the understanding that they put in the hard work, listen, and think about their decision’s impact on everyone and everything else. We in turn trust that others will do the same for us.

There are two parties in this contract:

The decider

This is the person (or when it’s a team, one of their members, most likely the tech lead) who initiates the process because they have a need for a decision.

Those offering the advice

These are the people who represent the affected parties and those with expertise.

The key that holds everything in balance is that everyone in the sociotechnical system, those building and running the software, could be called on to play either of these roles. Today, I could be a decider, seeking advice from others. Tomorrow, I could be an advice offerer, providing my wisdom to others. What I want for myself, I need to be able to offer to others. Perhaps this feels like a flimsy platform on which to build something, but remember that we are already engaged in a collective endeavor: the construction of a complex system with many interconnections and emergent properties. In such an environment, it makes sense to play by the rules of the game. To play well, I need others to trust me, and I need to trust them.

How do I build up this trust? By involving the appropriate people in my decision via their advice (I’ll cover how to identify these people in Chapter 5), by listening to and understanding that advice properly, by taking that advice into account in the options I shape and select when taking the decision, and by ensuring that the right people know about a taken decision by sharing it appropriately.

Trust is a big topic, and nurturing and protecting trust as you collectively practice architecture is a theme you’ll see throughout this book. For now, it’s sufficient to be aware of its central role and how it manifests in the form of the advice process’s social contract. You now have enough detail on the process to see how it works in practice.

Two Examples of the Architecture Advice Process in Action

Whenever I present the architecture advice process to clients, colleagues, and audiences at conferences, the description on its own always elicits strong emotions, both positive and negative.

On the one hand, you have developers who have felt the pain of being simultaneously blocked and berated for not getting the latest feature into the hands of users quickly enough. They typically greet the whole idea with open arms. On the other hand, some software and systems architects treat the architecture advice process as a potential silver bullet;3 they’re too experienced to accept it without question, but they’re willing to give it a try, evaluating experimenting with it as soon as possible.

But not all developers welcome the idea as enthusiastically. This is usually because not everyone feels as ready, willing, and able to take on the responsibility and accountability that the advice process entails. Some architects, those whose job it is to worry about the overall system, about coherence and predictability, and about nebulous things like cross-functional characteristics, tend to experience vertiginous flashes of panic as images of multiple teams, all headed off in completely different directions, arise.

You might be experiencing one, some, or all of these emotions yourself at this moment. That’s no bad thing. It means that you’re at least open to the idea of change.

These uncomfortable emotions arise from the advice process’s apparent simplicity. To many, it feels a little too simple. This comes from the tendency to think that for something to be important, it also has to be complicated.

If you are feeling this, remember the concepts of complexity and emergence. Surprisingly complex (and responsive) things can arise from very few and relatively simple elements when interconnected in a dynamic environment. The same thing happens here with the architecture advice process: you’ll be amazed how transformative adopting the advice process can be. Not only for your architecture practice but also for the resulting software and systems architectures, and the social dynamics of the teams that build and run them.4

With this in mind, I’m going to share a pair of stories to let you get a feel for how the process runs. They not only demonstrate the versatility of the advice process but also show how the process looks from different viewpoints. For that reason, I’ll keep coming back to them throughout this book, so it might make sense to add a bookmark (digital or otherwise) so that they are easy to find again. The stories show:

  • How a development team member might follow the process to address a need they are experiencing

  • How an architect might do the same with regard to something related to the overall system architecture

As you read these two tales, pay attention to the social contract and who the different parties are: decision maker/taker and advice offerers. Watch to see how the members of the advice-offering groups change depending on the decision at hand. Try to think about which party you might be in both types of scenarios. Also think about what the others are doing and contributing, and try to be aware of how it might feel to do so. You can refer back to Figure 4-1 for a visual representation of the advice process in action.

Story 1: A Development Team Decides to Use Release Toggles

The first story starts, as the majority of decisions do, with a team facing a challenge they want to resolve. Their organization uses the architecture advice process.

This team works with a product manager who is always pushing to deliver features to their users with less and less delay.5 Luckily, some of the team had read Accelerate6 and learned that by moving to a trunk-based delivery practice,7 they could eliminate pull requests altogether and consequently improve on their lead time for changes and deployment frequency metrics, and (most important) they could do it safely. A worthy goal if ever there was one.

Enthusiastic to learn new things, the team did their research and realized that to make this possible, they would need to make a small, localized, but significant architectural change: some form of release toggle. The question they had in front of them was: what would this release toggle implementation look like?

So let’s recap. The team is in need of a solution right now that lets them disable their unfinished code while still pushing directly to the trunk and deploying regularly to production. To do so, they need a significant architectural change involving some form of release toggle. This issue is blocking them from delivering as fast as the product manager needs them to.

The team has loads of local, specific, and up-to-the-minute detail on their need. They know all about the state of their codebase. They know what their running services are like, what they do, how they do it, and what kind of infrastructure their services run on. They know their backlog and what is coming up next, and they know the state of their existing pipelines, testing strategies, and other automation. Perhaps most important of all, they know about the skills they have as a group and what they are and aren’t comfortable with.

Note

In this first story, who do you think is the decision taker? And who do you think is the option maker? I’ll let you think about it while you read and give you the answers at the end.

The team started by investigating the options, doing some design work, and landing on what they felt was the best option for them: simple boolean checks in code. This can be considered their “draft decision.”

It was at this point that they decided to seek advice. First, members of the team listed and spoke to the “affected parties”:

It was self-evident to them that these people would be their peers in other delivery teams whose lives would be changed as a consequence of the release toggles being implemented. It wasn’t very hard to sit and think, “Who would have extra work to do as a result of us implementing this decision?” as well as “Whose freedom to act/flexibility to make changes unimpeded might be curtailed as a result of this?” It didn’t matter if their proposed decision would have such an impact. What was important was that the team thought about who might and then went to speak to them.

These impacted teams provided an incredibly useful and visceral “outside but still here-and-now” perspective on the proposal. They provided valuable context and detail that the deciding team was only slightly aware of. The key point that multiple impacted teams raised was the fact that these toggles would effectively “hide” unfinished services that they were developing and testing against. How would they test with the proposed solution? This was a great piece of information that the deciding team had simply not thought of. They noted it, vowing to figure out how to incorporate this need into their design.

The deciding team wasn’t being reckless or uncompassionate here. As soon as they were reminded of this fact, they realized just how problematic their original proposed change would be. They might get their features to production faster, but these other teams were building services for the same end users, just for later stages of the journey. By moving faster with their original, preadvice design of boolean toggles in code, the overall benefits would be small to none—perhaps they would even make things worse overall.

So why had the team not thought of this themselves? Because putting yourself in everyone else’s shoes is difficult to do. It comes down to human psychology. Someone who is having something removed from them is far more alert to that fact than someone who might be doing the removing. This is because the person affected knows what they need and how much they need it far better than anyone else. This is one of the great powers of the advice process: all you need to do is think of the people and then let them tell you what this will mean to them. Instead of trying to put yourself in someone else’s position (as other approaches to architecture can do), the advice process engages with these parties directly and involves them explicitly. It’s a much more effective way to make good decisions.

At this point, the team already knew they had to return to the drawing board with their design, but before they did so, they chose to speak to the other advice-offering group: the parties with expertise. What insights would they have to share?

In many circumstances, “expertise” translates to “past experience and/or wider horizons on the decision.” We’ll dig into each of these in detail in Chapter 12. For now, it will help to think of these “horizons” as matters like longer time periods, broader scopes, greater risk awareness, deeper understanding of cost implications, and wider understanding of the impact on people and skills in other areas of the organization as well as general organization, business, market, and industry understanding.

In our story, the experts initially identified to speak to were a systems architect, the lead QA, and a different product manager for another part of the product who had experience with release toggles. The team spoke to them each in turn.

The architect turned out to be a great first port of call. Not only did she have a wealth of opinions, but she also had experience working with a form of release toggle back when she was a developer. She pointed out that not everyone had the same idea in mind when people used the term toggle and pointed them to an article on feature toggles that the team had not previously seen to help them disambiguate. After the team had read this, they realized they had been lucky—they really did mean release toggle—and they had also learned that they should think about making their implementation temporary. The architect backed up their advice with tales of all the dead code that was left in the codebase when her project had used them. This was a key piece of advice and one that was very simple to incorporate into the decision, whatever the selected option. In doing so, all options were improved, and technical debt in the form of redundant code could be managed, saving the team a lot of time in the future. This is an example of an expert providing “farsight” (looking farther into the future) advice.

The architect suggested that the team talk to the lead infra engineer. They’d be able to provide advice on environments, permissions, and access rights. The team agreed to set up a chat with them. But first, they had a scheduled meeting with JB, the lead QA.

JB had some great points, too: specifically, a concern that toggles would make testing more involved. They explained that with release toggles in place, testing would have to ensure that features (1) did work when toggled on, (2) did not work when toggled off, and most important, (3) didn’t interact with one another in weird, unpredictable ways when some were on and some were off. Despite this, the lead QA, JB, was also very excited. They knew the risk-mitigating benefits of being able to make many small releases of code as opposed to one large one. (No prizes for guessing that this quality expert had provided an example of “greater risk awareness” advice.)

Next, the team sat down to talk with Yinka, the lead infra engineer, who was kind enough to have an impromptu chat with them despite feeling a little ambushed. That conversation, although initially a little fractious, validated what Fiona, the systems architect, had pointed out: if the toggles were in code, then to change one toggle—for example, to enable a feature for an internal showcase demo—the team would have to submit a code change and trigger an entire run of the pipeline.

While it would work, the infra engineer Yinka wasn’t shy about sharing his feeling that this was a pretty heavyweight approach, but when questioned, he explained how the team’s goal could be better achieved with toggles controlled by environment variables, which could then be changed without redeployments. “This would be easy for the team to implement,” Yinka said, “as we’re already using this approach for some of our infra configurations, and it has the added benefits of not giving me and my team any more infrastructure to look after, such as databases or more elaborate products.” Yinka even concluded by telling the team about a colleague to speak to when it came time to implement. In the course of this slightly difficult but enlightening conversation, the infra engineer had provided examples of both “deeper understanding of cost implications” (with regard to time taken to swap toggle settings) and “wider understanding of the impact on people and skills in other areas of the organization” advice.

There was one final expert to seek advice from: Monira, the product manager from another department who had experience using release toggles. The team kicked off the chat with her by summarizing everything they’d learned from the prior conversations. Monira validated it all and didn’t have much advice to add. She did, however, point out a final benefit of the environment-variable approach: it would allow the team to safely, and with little notice, demo to her colleague, the team’s product manager, or clients. When the team asked how, Monira explained that the toggles could be used to turn on a specific feature or set of features for such impromptu demos and then turn them off again afterward, with little overall disruption to the team’s planned work and without blocking environments for multiple hours while the toggle was enabled and then disabled. The team loved this. It would allow them to smash the expectations of their product manager, who only really wanted to understand users’ needs (and therefore build the best product possible) without much disruption. A win-win situation.8 Yet again, advice had broadened the horizons of the team. This time they had benefited from an adviser’s “understanding of cost implications” as well as their insights into what the market would tolerate in the form of clients’ willingness to get incredibly early views on in-development features.

Armed with all this incredible advice, the deciding team went back to their design and made significant changes. They followed the advice of the infra team member and decided to use environment variables for their toggles, and they checked to see if this meant they would have to request any significant changes to their delivery pipelines. It didn’t. They also decided to track the existence of toggles for stories in their Jira tickets, which would allow them to see what toggles were in use and, importantly, what they were used for. This last idea came from the business analyst in the team who knew Monira, the product manager, would appreciate being able to know at a glance and without disrupting the team what was demo-able.

The team’s final act was to get back to everyone they had sought advice from to let them know about their decision. This was easy and quick because those involved already had a lot of the context, and even the affected teams who didn’t know about the shift to an environment-variable-based solution knew about all the context of the decision and so needed little extra information. They were also pleased at this new easy-on/off solution as it meant they could get access to the in-development services far more rapidly when they were needed.

Now that the advice process is complete, I can tell you who the option makers and decision takers were. The answer for both is “the team.” The reason they are the decision takers is because they are the ones who felt the need for the decision and who initiated the advice process in order to take it. And why are they the option makers? Because they are the ones making the options (with help in the form of advice from the advice offerers whom they are obliged to engage).

I hope the benefits of the advice process are clear from this first story. The deciding team ended up in a far better place than they would have been had they gone with their initial design, which they came up with on their own. This is in great part because the advice process provides a basis for combining a wide variety of data and viewpoints: near and long term, local and systemwide, upstream and downstream. It’s an incredibly powerful mix.

It’s worth being explicit about the fact that not all of the advice a decider receives may change their planned approach, but every piece does contribute toward making them aware of the full scope and impact of their pending decision. In exposing the decider to this, in the context of their real need that arises from their real-world circumstances, the advice process is a great catalyst for learning. In this tale alone, the team learned more than they ever expected about types of toggles and their uses, about the past experiences of the architect, about the thought processes of QA (developers could always benefit from thinking more like QAs), and about how infra contribute to building and running their systems and how they are reticent to take on more things to look after. Most important perhaps, the team collectively built their human network across the organization. The more times they made decisions using the advice process, the stronger this was to become.

For these arising-from-teams decisions, the traditional architectural dynamics are flipped on their head; previously, decisions were taken outside teams, then handed to them to implement. Now with the advice process, teams have a stronger voice and are exposed directly to their peers and the consequences of their decisions. They have, in the words of the Netflix culture deck,9 both “freedom and responsibility.”

Story 2: An Architect Decides to Unpick a Workflow Problem

Over the course of software delivery, especially in these days of constantly evolving architectures, a majority of decisions arise in the fashion of my first story. But not all of them. What about decisions that address those needs for cross-cutting decisions and decisions that arise from the nature and evolution of the system as a whole? Who raises those questions in the advice process? These decisions inevitably come from people playing roles outside of any single delivery team. In most (but not all) cases, these are roles we traditionally think of as “architecture.” This type of decision is the focus of our second story. As you read it, pay attention again to the social contract and who the different parties are. It’ll help make the story clearer.

Picture the scene: delivery has been up and running for a few years now, and a mature product is in place. It has an established customer base, supported by a set of robust and predictable microservices. Predictable, that is, in all places but one. One microservice has slowly become both a delivery and a performance bottleneck as well as a single point of failure.

It wasn’t supposed to be this way. The service in question had begun life as a simple component built by a single team to externalize a few key decision points of their workflow logic. Because it was solidly built, well tested, and, most of all, easy to consume and extend, other teams started to put some of their workflows into it. This isn’t an uncommon occurrence. Over and over, I’ve seen the place where it’s easiest to put complex logic be the place where it ends up, whether that was the best or right place or not.

Time passed, and as the company’s product became more popular, the user needs it was supporting became more complex. This subtle but definite change in overall product philosophy also changed the demands placed on the underlying services.

The workflow microservice began to take more and more of the strain. Because of its high-quality implementation and ease of extension, it coped admirably. Sometimes, for example, a team needed more than the basic workflow support, so the team that owned the workflow service gradually extended it. It worked. Everyone managed to deliver their stories rapidly, and product managers were happy.

But slowly, problems began to arise.

Teams had been noticing for a while that very occasionally, an individual user’s journey would act strangely: they might jump forward a few steps, or jump from one flow to another, or (worst of all) potentially gain access to subflows they shouldn’t be able to access. While this wasn’t great, what was worse was that these failures were hard to replicate and therefore difficult to fix.

As the company’s overall product became more and more successful, the load on all the services increased, and these “blips” in workflow functioning became more frequent and increasingly harder to replicate. It became clear where the root cause of the problem lay: the workflow service. Over time, what had been seen as a reliable and useful tool was slowly becoming a liability.

This isn’t an unusual evolution—I see it over and over again, and let me be clear: what the workflow subsystem was doing now was far outstretching the original design goals of the team when they first developed it. It’s no wonder then that things were beginning to creak at the seams. This superservice was now performing a lot of different jobs, many of which simply hadn’t been considered at the outset because the need wasn’t there. There was a reason for this: when the system was originally designed, no one thought user journeys would get so complex. In fact, one of the original selling points of the product was that it was simple, straightforward, and to the point; it worked the same everywhere. The only reason this service had been brought to life in the first place was to allow minor changes to the user-journey flow to be deployed without updates to the mobile app. But as we all know, even if it’s only from our experiences as consumers, products don’t stay the same for long these days, so the product began to incrementally evolve in a different direction, one that was more individually tailored to users, and the underlying services evolved incrementally to support this.

The signs that the architecture was the problem rather than simply a lack of testing or low code quality first became clear to those in architecture roles. Because they considered matters across the entire system, they were in a position to aggregate all the individual instances of failure, while teams were quite likely aware only of the ones that affected them, so the architects could see a possible pattern emerging. Their longer experience had taught them to stay alert for bad smells, and this service was increasingly the source of troubling odors.

The smell that tipped the balance from observing and offering advice into architecture changes and deciding was work coupling. Teams were being blocked in delivery of their features while they waited for the team that owned the workflow service. The reason? They needed minor enhancements in the underlying service to allow their features to work.

At this point, a systems architect decided that something needed to be done, and as you would expect, she went about this using the architecture advice process, playing the role of the decision maker and taker and seeing the relevant advice inputs. She put together the following list:

Their initial focus in seeking advice was to (1) establish the current design of the workflow service as it existed in the code, and (2) find out what each of the teams was trying to use the workflow service for. As I’ve already mentioned, it turned out that the code was clean, and the design was explicit and well tested. Unsurprisingly, the code was doing a lot. What the architect uncovered with regard to the second line of investigation backed this up. By looking at the combination of the code and the team’s needs, the architect could see that there were three usage patterns being supported.

Some teams were still using the system as originally designed: purely as a workflow engine, directing the users to the next steps in their journeys. These teams didn’t put any of the logic of each step in the workflow; for that, control would be passed back to the mobile user and the app in their hand. This was the first usage pattern.

This original design explicitly did not hold the state of individual user-journey flows. However, as journeys had become more involved, more and more complex business logic had started to be duplicated in both the iOS and the Android version of the app. As a result, the decision had been implicitly taken to put this logic in a single place. By “implicitly,” I mean it had arisen during the course of coding and not been identified as an architecturally significant decision.

It was significant, though, and it was acted on appropriately. The duplicated logic for these flows had been removed from the Swift and Kotlin codebases and located instead back in the workflow service. This decision made a lot of sense from many angles. This was the core business logic, and it was important to the business too because of the increased user expectations. Writing it in two places was a clear violation of the DRY principle.10

In the refactored workflow engine underpinning all these journeys, there was an implicit assumption that these shared, backend business logic steps would be stateless–that is to say, when they were called, they would have all the user state needed to operate passed into them, and all the information needed for the mobile apps to proceed would be passed out of them. Nothing would be persisted. Consequently, other teams were then able to use it in similar ways. All these teams were the second usage pattern.

Finally came the third usage pattern. When the systems architect spoke to these teams, she discovered that, rather cleverly, the teams had realized that they could build on top of the platform provided by the workflow service and add their own cross-request state persistence features. They’d managed to circumvent the “no persistence” rule.

Yet again, the teams hadn’t done this simply for their own gratification or out of laziness. These teams had foreseen that all this passing of state back and forth, especially in some of the less mature mobile marketplaces, would slow things down, ruining overall user experience. (In the future, this would most likely have been the case, but it wasn’t an issue yet.) This local optimization had pushed the workflow service as far as it could go and, in certain edge cases, farther. It also meant that something like session stickiness would need to be implemented if the workflow service ever scaled up to multiple instances, which would have an impact on options to scale.

The systems architect now had a good view of all the forces at play in this decision. Fundamental to her thinking was acknowledging that the workflow service was now meeting multiple needs. Some it had been designed for at its core, and some it hadn’t. What was amazing was that in most cases, it was coping admirably.

The architect now had the information she needed to engage the experts, bringing in one of the organization’s global mobile subject matter experts (SMEs). In the ensuing conversation, it became clear that this kind of evolution is not uncommon where patterns aren’t initially as distinct as they might be in the web world. What is more, the nature of mobile deployments, and the fact that teams can have multiple versions of their clients in the form of the mobile apps out there in the wild running in parallel, compounds issues.

Cassie’s first piece of advice was to acknowledge the various forces at play and the needs of the various teams. Second, she suggested addressing these needs individually. Third, she suggested that some of the problems might not need to be solved right now; instead, the teams that were experiencing them should simplify their implementation while starting in parallel to investigate relevant third-party and open source solutions.

This then led the architect to go speak to Patricia, one of the newly hired senior devs on the Android Mobile team. The company that Patricia had just left had famously faced similar issues around duplication of business logic. They had a great chat about the pros and cons of different approaches to solving this. The architect kept in mind the fact that the circumstances this company was facing were slightly different, but there were great insights around available frameworks, tooling, practices, and developer experiences to make this work.

Finally, the architect knew that Gayathri, one of the more-experienced backend devs, had been around in the days of enterprise service buses, and in another part of the business was Isha, a QA who had worked on a heavily workflow-oriented system based on Apache Camel. The architect chatted with both of them, sharing with them both the current usage patterns of the subsystem and the benefits and pitfalls of various types of standard patterns that this was approaching. In doing so, the architect drew together a decision that would, if not make everyone entirely happy, be right-sized for the organization and aligned to its future direction as well as one that maintained investment in the homegrown workflow solution.

The systems architect was now in a position to make her decision proposal. It comprised three independent parts:

  • Some simple refactorings of the workflow service to firm up usage patterns, making it explicitly easier to use this service to do the things it was good at, and harder or impossible to make it do things it was poor at. These refactorings focused on protecting the statelessness of the service above all else. The architect proposed that this be developed using an “inner source”12 approach to allow teams to put their flows into the workflow service codebase without having to rely on the team that owned it to do it for them.

  • Identify an element of shared cross-platform business logic that is well understood and tested in the workflow service. Take this and reimplement it using Kotlin Multiplatform, providing libraries that can be consumed directly by both the iOS and the Android apps. The architect hoped that this would allow this code to be written once, but that this approach would avoid the need to have this shared code running in the backend, instead packaging it with the iOS and Android releases directly.

  • Refactor the stateful, performance-optimization workflows to make them stateless. At the same time, instrument the journeys to capture real-world data on the journey times and volumes of data being shipped over the wire. Use this to look into solutions such as realtime backend databases for mobile (such as Firebase Realtime Database) and backends for frontends (such as GraphQL).

The next step before taking and then sharing the decision was for the architect to go back to each of the teams and seek their advice on this draft decision, particularly how it might be rolled out. This time, the architect brought everyone together so that the scope and interdependence of everything would be self-evident to all concerned. This was crucial because the implementation of big architectural changes is as important as the architectural design itself. By doing this, everyone involved learned even more about the specifics of what was planned, and an incremental strategy that could be pursued team by team was worked out.

It helped that the decision had been split into three parts. These could be tackled independently and at a sensible pace. All the teams knew what they would get as a result, what their roles in the refactorings were likely to be, and when it would all happen. They also provided some further pieces of advice, based this time on the teams’ capacity for this extra work, the skills and predisposition to learn new things in each team, and any early warnings of potential difficulties. The architect factored this advice into the decisions and supported the teams that required further investigations while helping the others get to work on their elements. Finally, the architect was able to take this involved yet incredibly important decision with the support of all the teams.

The necessary refactorings were implemented slowly, steadily, and safely. Milestones were celebrated by everyone as they were reached. Because everyone understood the overall goal, teams could call in the architect when unpredicted events happened. The product managers supported the change as they could see, step by step, that the numbers of defects their customers were experiencing were decreasing and the speed at which their teams could implement new features was beginning to recover.

You will, I hope, have noticed that the dynamic of this outside-team-initiated advice process is different. In this mode, those concerned with the overall systemic architecture (the roles almost inevitably played by those of us with “architect” somewhere in our job title) have a mechanism to work out in the open, establish dialogue, and build trust and understanding across all teams within the sociotechnical system.

This is where the power of the advice process comes in yet again. The architect pursuing this change had to recognize that they depend on the teams to deliver the necessary implementations. She had to listen to the teams as part of the contract (a great way to get right-now detail) and make coherent arguments for the benefits of their change. This has a balancing effect. No longer could arbitrary, wide-reaching decisions be taken without at least some attention being given to the teams that would bring them to reality.

The Centrality of Advice

I hope that you’re starting to get a feel for how the advice process works. As it becomes more familiar to you, it’s important to keep in mind what advice is and how it shifts the power to decide. Everyone participating in the advice process needs to understand the value of advice, which advice is pertinent to a specific decision, and how advice affects the decision process.

Advice Is Suggested Direction Plus Reasoning

The concept of advice can be a tricky one to grasp. Advice is frequently confused with opinion, and opinions are things that we software development professionals seem to have many of. It’s an incredibly important distinction, though, because in the advice process, opinions are a near enemy of advice.

Near enemy is a Buddhist concept, best thought of as a counterfeit that appears to offer the same value as the real thing but is, in fact, harmful. For example, needy codependency is a near enemy of love.13 From a more technical perspective, a DevOps team is a near enemy of a DevOps mindset, and a top-down-imposed Agile transformation is a near enemy of Agile teams.14

Why is a DevOps team a near enemy of a DevOps mindset? By its very nature, a distinct team “doing” DevOps is fundamentally missing the point of the DevOps movement, which came into existence to break down silos between Dev and Ops (hence their proximity in the name), with goals that include improving communication and building in feedback loops. A separate team to achieve this clearly flies in the face of these goals.

And how is a top-down-imposed Agile transformation a near enemy of Agile teams? Well, the Agile Manifesto principles remind us that “The best architectures, requirements, and designs emerge from self-organizing teams” and “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Sadly, these principles are the exact opposite of a directive from senior management to “be Agile.” You know things are really getting out of hand when things like standardized tools and ways of working are rolled out by a team that isn’t itself involved in the delivery of software.

Now that the concept of near enemies is clear, let’s turn it on advice and opinion, and see why the latter is a near enemy of the former.

Merriam-Webster has the most appropriate definition of advice for our purposes: “a recommendation regarding a decision or course of conduct: counsel.”15 According to this definition, advice is directly related to decisions. No surprise there. The “recommendation” and “counsel” parts are what I want to focus your attention on. When advice is offered, we get both the direction recommendation and the reasons behind it—the benefits of experience. That means the advice recipients get the advisers’ perspectives and perceived outcomes that a potential course of action may or may not lead to. That can truly be incorporated into the decision process.

For example, some advice might be offered regarding which build of the OpenJDK to use in a new project. Now, there are a lot of builds available, and the choice can be overwhelming (the latest list is maintained on the OpenJDK Wikipedia page). Advice received might be: “I would use this build because not only does it have licensing terms appropriate to our company’s standards but also because their releases always keep up with the upstream OpenJDK from Oracle, and they have a great wiki as well as an active community who responded rapidly to us when we asked them for help on a weird issue we had.”

You get the idea. Not only do we have a suggested build, but we can also see why the adviser reached their conclusions. Knowing this, we can then consider if these reasons are relevant to our circumstances and reflect a sufficient understanding of the decision we are engaged in.

How does this compare with opinion? Oxford Learner’s Dictionaries defines opinion as “your feelings or thoughts about somebody/something, rather than a fact.”16 Clearly, an opinion might still be targeted at a decision (“about something”) and might come in a form that initially sounds like it might be advice: “do this” or “don’t do that.” Both advice and opinion can begin in this way, but after that shared beginning, they diverge, which is where the near enemy opinion lurks. The key differences are twofold, both stemming from an opinion’s lack of a “why.” First, opinions lack supportive reasoning, or to put it more simply, they lack facts. They tell you which direction to go in but not why that direction is best. Second, opinions might also be driven by feelings or emotions, which quite likely are submerged and implicit. The lack of associated facts is a clue to this.

If we return to the example of advice that I gave earlier, this time phrasing it in the form of an opinion, you will be able to see the difference: “I would use this OpenJDK build because it works better. It’s faster, cheaper, and higher quality.”

You can see we still have the direction (“Pick this one, not any of the others”) but the reasoning is absent. Why is that build better? Why is it faster? Why is it cheaper? What about it is higher quality? For a decision maker seeking advice, these opinions are damaging because they do not provide the real juice of the offerer’s experience. The adviser hasn’t shared their supporting reasoning, their “whys.”

Architectural decisions are always “it depends” decisions; the trick is to figure out what the decision “depends’’ on, and advice helps with that greatly. Opinions lack this key aspect, and omitting it makes it harder for the decider to benefit from the offerer’s experience.

All is not lost, however. If you are lucky, you might be able to tell that there’s an unvoiced feeling motivating the opinion, and you can get to it via some questioning. In our OpenJDK build example, the advice seeker could probe with appropriate “why” and “how” questions, and perhaps this would be enough to turn the opinion into advice by supplementing it with supportive reasoning. You might not always get this, particularly when the opinionated person is unaware of their bias, or is aware of it but is ashamed to admit it.17 However, even this information is valuable as it signals the presence of a near enemy, which can be handled carefully.

Why do I say “carefully”? By not sharing the “why” of advice and instead restricting involvement to the raw statement of opinion, opinion offerers can be attempting to retain power for themselves, whether they know it or not. If advice offerers are struggling, for whatever reason, asking “why” can boost the process and forge a path to the advice. Underlying it all may be the fear arising from a lack of trust. That’s perfectly understandable, and I’ll come back to this topic again and again in Part III, but while it’s front of mind, let’s have an initial look at the shifts in power dynamics right now.

Advice Powers Up Option Makers and Decision Takers

When you gather advice, useful or otherwise, you expand the knowledge and experience base that informs your decision. You are hearing what others would do in your circumstances, but not only that—you are hearing what they would be thinking or asking themselves if they were in your shoes, and most importantly, you are hearing why they reached the conclusions they have.

Recall the opinionated adviser in the previous subsection. Imagine now that we’d followed up their opinions with a bunch of questions, and that, excited by the prospect of being asked to expand, they did. Sharing just a little of their experience, they talked about how they had worked on a project that used a pre-OpenJDK version of Java, and it had caused them no end of problems. Biggest of which was the fact that they had been forced to rely on a small team of part-time committers to fix the bug requests they logged, which had been many. They told how they had tried to take control of matters by submitting patches and pull requests but to no avail. The core committers were disinclined to offer anyone outside their immediate circle commit privileges. As a consequence, the adviser had gained a distrust of open source projects that were maintained by teams, not subsidized full-time by a commercial company. Even then they were skeptical, reasoning that the company would always prioritize their own needs over those of the community.

Mapping advice onto your specific circumstances powers up your decision, either because you now have supporting reasoning from others or you now have a more cleanly defined context, options, and consequences. Thinking critically about whether you are receiving “advice” or simply opinions really helps in this. It also helps to ask questions, transforming opinions into advice. Both ensure that you really listen and really understand by interrogating advice you identify and isolating the parts that are useful, even if they are mixed in with elements that don’t apply to the circumstances at hand. You can tell which is which from the supporting facts and the reasons why because they allow you to differentiate what is applicable from what is not.

With this counsel available, you become (potentially, at least18) greater than if you were simply thinking and acting alone. However, you—the decider, the one who has initiated this decision and who is responsible and accountable for it—are still the only one in the driving seat. As long as you have lived up to your end of the social contract, fulfilling your obligation to seek all the relevant advice and making sure you understand it, you are entitled to take any decision you need, including if this means acknowledging but putting aside the aspects of the advice that are not pertinent to your decision.

Offering Advice Does Not Make You Accountable—Taking Decisions Does

Let’s be clear: as the decision taker in the advice process, you are not only responsible for a decision but also accountable for it. The permission that the advice process confers to make and then take decisions is a powerful one indeed, but for that reason, it can sometimes be a bumpy road.

This unhitching of this locus of power can be particularly tough for architects who are traditionally used to being in the driving seat of all decisions. Watching others taking the wheel and steering the technical direction can feel uncomfortable, especially when the decisions don’t go the way they would take them, against their offered advice. Even if intellectually, architects and other leaders, right up to the executive level (CTOs and CIOs, for example), understand that this transfer has taken place, it can be emotionally hard to let go, especially when it has been your role’s raison d’être (and quite possibly a motivation for pursuing the career of architect in the first place).

For some traditional architects, feelings around this change in role are self-evident, while for others, they are not so conscious. Either way, it leads to problems when an architect is unwilling (consciously or unconsciously) to let go of their sense of accountability. You will see it arising (either consciously or unconsciously, in yourself or in others) in the offering of opinions rather than advice, even more so when there are difficulties clearly articulating the “why.”

When this happens, it helps to remember that in the new world of the advice process, the responsibility of advice seekers/decision takers is to understand all the advice they can get their hands on, and the advice offerers will now want those who are newly accountable to have as much information as they can provide. This dynamic supercharges the advice seeking—least because of the social contract, but also because there is little to gain in taking a poor decision when a better one might be achievable. Furthermore, if opinions are offered, then it is beneficial to the advice seeker to deploy questions to find out what is behind them because they are accountable for the end results (both the decision and, if they are in a team, the resulting implementation). If there are useful elements for them, then they can access them. If this power is going to transfer, then it had better transfer properly and fully, with the advice seeker aware of all the concerns that the advice offerer has.

There is a great benefit to this transition to the advice process. Recall the two scenarios demonstrating the advice process in action from earlier in this chapter. Story 1 showed that some decisions were now moving into the realm of the teams—they initiated the decisions, made and then took them, and implemented them. They were accountable. In the old world, even if an architect had merely been along for the ride at every step of the way, merely nodding and agreeing to every suggestion the team might have, effectively rubber-stamping everything, at the end of it all, the architect would still be accountable, not the team. This happens with the traditional architecture approaches over and over again right now. It’s happening in your organization (either explicitly or implicitly). How can an architect possibly be responsible for everything these days? And yet, because of the ways that things are currently set up, they are.

Now bring to mind the second story. There, the cross-team architect initiated the process, so they remained accountable for that decision, even though the teams were, as always, the ones who implemented it. Again, that is as it should be. In a world where multiple teams have roles to play and no single team is doing even a majority of the work, you need someone outside the teams to make sure the best outcomes are achieved. As I made clear, the architect still depends on the teams to implement their elements, but this was always the case. If you are an architect, do you really, truly believe everything you told teams to do ended up in production, in the way you told them to do it?

Of course not.19

The Importance of Conversations

However you approach it, the first thing to bear in mind is that the advice process places great value on conversations. It therefore should come as no surprise to hear that the influential architect Ruth Malan presciently noted that for an architecture to be successful:

It is very much about ensuring that conversations that need to be happening are happening—not always initiating them, nor always helping to focus or navigate them, but ensuring they do happen and guiding when needed.20

The advice process is robust precisely because it operates in this way. As a decision process, it decentralizes power so that anyone can initiate a decision. It opens up space for conversations to happen around the making of those decisions and requires that you have conversations with the right people. Malan’s “needed conversations” are the heart of the advice process.

However, it’s quite possible that the approach still feels a little too loose for you, and I can sympathize with that. Many software professionals, myself included, have, in part at least, gravitated toward software because of the certainty and concreteness of code. All this talk of “advice” and “anyone can take a decision” feels a tad too close to anarchy.21

Let’s unpack that a little because it’s important. I want to acknowledge it and provide reassurance, too, with Malan’s centering of conversations as our touchstone.

The Significance of Trust

There is a fear regarding trust that may have been circling your mind as you’ve been reading this chapter. With client after client, I encounter architects who don’t trust development teams and development teams who don’t trust architects. In fact, I frequently see development teams who don’t trust one another either as well as architects who are at odds with one another.

However, trust within development teams is usually quite high, and this indicates to me that trust is possible to achieve and sustain in today’s organizations. The reason this can happen within teams is because, in the majority of cases, there is a shared goal and a mutual dependency on the successful delivery of its associated outcomes.

By deploying the advice process, you are both establishing and subsequently relying on a broader trust network. Is that possible? If you are unsure if your organization can achieve and sustain this, then I encourage you to have faith—just because you may not see it now doesn’t mean it is an impossibility. It’s just that traditional practices prevent it from arising.22

Remember as you read this book, whoever you are and whatever your role, you are worthy of trust. It follows that if you are, aren’t others? If particular problematic individuals spring to mind who you feel are unworthy of trust, I’d challenge you to ask “why not?” Perhaps you disagree with one another. In that case, use the advice process to work with them—at least trying to seek their advice—safe in the knowledge that you can ignore their advice if you choose to. Perhaps they are actively secretive or destructive; I will spend whole chapters in Part II and again in Part III to help you identify and resolve this (both personally and as a collective). For now, bear in mind that such people will be a problem, no matter what approach you take to the practice of architecture. A problem that your organization will need to address.

Once again, this demonstrates the power of conversations, and conversation is precisely the right word. Conversations aren’t adversarial, they’re not a battle, and they don’t seek to have a winner and a loser; they’re not a zero-sum game. Conversations are interactions that take place between equals. They are about the back-and-forth exchange of information and, dare I say it, building of trust and understanding. They are about co-creation of something shared: both software and trusting relationships. There can be no pulling of rank in the advice process.

By centering conversations, you aren’t only solving your problems of architectural processes that block and fail to factor in sufficient feedback. You’re also potentially uncovering a better way to do architecture.

Conclusion

In this chapter, I introduced you to the architecture advice process: a decision process that embodies a fundamental shift in software architecture practice. The advice process is built on the core idea of allowing everyone to make options and take architectural decisions, with appropriate input from others, and a social contract that supports this. This seemingly small change eliminates decision bottlenecks, optimizes feedback, and catalyzes a healthy culture of trust and learning.23

Hopefully, the architecture advice process sounds like something you want to experiment with. Chapter 6 introduces an essential complementary element, and subsequent chapters offer further optional supporting elements to establish and bolster trust, but for now, let’s look at three different ways that you can roll out the architecture advice process, start these conversations, and transform how you go about practicing architecture within your organization.

1 You can read about general advice processes that are applicable to all decisions, not just software architecture ones, on the Reinventing Organizations wiki, which supports the book Reinventing Organizations (Nelson Parker) by Frederic Laloux.

2 This is a likely contributor to the gradual rise of architects up organizational hierarchies. Despite the fact that they occupy what might be considered a glue role (a term coined by Tanya Reilly), their “in-between” focus gradually became seen as “across” and then “above”/”on top of.”

3 Because they’ve been working in software too long to know this is never the case. If you’ve not yet treated yourself to it, I recommend you check out Fred Brooks’s essay “No Silver Bullet: Essence and Accidents of Software Engineering” in Computer, vol. 20, no. 4, pp. 10–19, April 1987, doi:10.1109/MC.1987.1663532.

4 Principle 11 of the Agile Manifesto states: “The best architectures, requirements, and designs emerge from self-organizing teams.”

5 The product manager is right, by the way. Code that is written but is not in use isn’t delivering value. Donald G. Reinertsen calls this design-in-process (DiP) inventory. We’ll see exactly why this matters in later chapters.

6 This is the third time I’ve mentioned Accelerate by Nicole Forsgren et al. in this book so far, and it may not be the last. If you haven’t gotten the hint that I highly recommend reading it, maybe this third mention will be the charm. Go read it.

7 Accelerate suggests that you adopt this practice, but the best place to find out how is in Valentina Servile’s Continuous Deployment (O’Reilly).

8 You can see from this that product managers deeply and intuitively understand the concept of early feedback. Here, they were hoping to get this before a feature was even completed. What better way to find out what users think and prevent waste in the form of the team continuing to build anything unwanted?

9 It never fails to amaze me that Netflix published this so early on in the company’s life. I’ve taken inspiration from it many times and stolen a few ideas from it, too. You can see the latest version as well as previous versions.

10 This was the real DRY (don’t repeat yourself) principle: the issue here was duplication of knowledge, not simply of code. These were key business rules, so having to code and test them twice was opening the teams up to undue risk. The best explanation of this I’ve ever found is in Mathias Verraes’s blog post “DRY is about Knowledge,” which does a great job of disambiguating Andrew Hunt and David Thomas’s original explanation in The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley)

11 Enterprise service bus (aka ESB) was a pattern favored in the early 2010s that got out of control and became a place to mislay and then lose your organization’s key business logic. (See the ESB tech radar blip). The “smart endpoints, dumb pipes” pattern emerged in response to this.

12 See the report by Danese Cooper and Klaas-Jan Stol, “Adopting InnerSource,” for more information. Fundamentally, it espouses using techniques that are used to run open source projects: codebases and backlogs everyone can see, documentation on processes for those outside the core committers to submit features, bugs, code, etc.

13 You can read some other general examples in “This Column Will Change Your Life: Near Enemies” by Oliver Burkeman.

14 Gayathri Thiyagarajan and I filled an entire presentation with the near enemies of domain-driven design called (unsurprisingly) “Combatting the Near Enemies of Domain-Driven Design”.

15 Merriam-Webster Dictionary, “advice”, accessed August 14, 2024.

16 Oxford Learner’s Dictionaries, “opinion”, accessed August 14, 2024.

17 As a former employee of Sun Microsystems, I was raised to have an unthinking bias against everything Microsoft. Even when it was clear I was in the wrong, I would stick to my opinions. This bias ran so deep that it persisted for years after I left the company, and even after the company ceased to exist. These days, I still have a remnant of that bias (Sun was my first employer after all, and it was the heady days of the first dot.com bubble), but I am aware of it, and I can express it out loud. This allows advice seekers to separate the advice from the opinion and get what they need. I also quite like joking about it.

18 Barry O’Reilly (the residuality theory one, not the Lean Enterprise one) is in the process of proving this mathematically. See his paper “An Introduction to Residuality Theory: Software Design Heuristics for Complex Systems” (Procedia Computer Science, vol. 170, 2020) for more information.

19 In fact, I hope teams have never simply coded up my designs unthinkingly. Some of my most memorable nightmares have arisen from something I forgot to even worry about suddenly springing to mind, and when I spoke to the dev lead of the team at work the next day, they let me know that they had already spotted it and updated the design accordingly.

20 Ruth Malan, “How is Software Architecture Created?”, updated July 18, 2020.

21 I use this word advisedly. When people use the word anarchy in general conversation, they typically mean a state of disorder. That couldn’t be further from the anarchist’s own definition. Ironically, the advice process is in many ways a textbook implementation of anarchistic organizing in that it follows Paul Goodman’s definition: “Authority is delegated away from the top as much as possible, and there are many centers of decision and policy-making. Information is conveyed and discussed in face-to-face contacts between field and headquarters” (quoted in Patterns of Anarchy: A Collection of Writings on the Anarchist Tradition, eds. Leonard I. Krimerman and Lewis Perry (Anchor Books, 1966), 379–380).

22 I’ve argued elsewhere that the single-mode, traditional organization structure fundamentally prevents other ways of collaborating from arising.

23 It’s small, but it’s a key leverage point, hence its power. See Donella Meadows’s article “Leverage Points: Places to Intervene in a System”.

Get Facilitating Software Architecture now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial