Why do we write software? It’s a simple—but important—question. The answer may seem obvious, yet, as with so many things, the answer is much more nuanced than it seems at first.

For me, the answer depends on which role I am playing. Am I playing the role of developer or architect? As a developer, I expect that my answer is the same as that of most developers. My short answer is: “Because I can, because it is fun, and it’s what I do.” I can create things, seemingly out of thin air. The creative process itself is its own reward. I enjoy what I do!

I have spent most of my career building custom software solutions. When someone who is not in the industry asks me what I do, I like to use an analogy; the typical custom motorcycle shop reality TV show serves as a great analogy for most software development projects.

By the skin of our teeth

Most of us have seen this type of show, and they all...

Our ability to continuously deliver business value is a function of lead time. If we measure our lead times in months or even weeks, then our ability to deliver is not continuous. We are wasting valuable time while we assume that we are building the right solution. Much like the Grand Prix motorcycle analogy, we want to put our software in users’ hands as fast as possible so that they can test drive it and provide feedback. Then, we tune the solution and quickly send it back out for another test drive.

To become a high-velocity team, we need to build the muscle memory that allows us to produce this seemingly uninterrupted flow of ideas and experiments. However, we need to get out of our own way. The typical software product delivery pipeline is full of potential bottlenecks that increase lead time. We need to understand these bottlenecks before we can produce an architecture that enables change.

Let’s survey the forces that influence our...

Our software systems are composed of many features that must work together to deliver value for the end users. How these features communicate has been one of the most significant topics in our industry. The communication pathways within a system impact the timely flow of information, but they also impact our ability to deliver timely solutions. A highly integrated system will maximize the flow of information. However, if we integrate features too tightly, then it impedes our ability to adapt to changing requirements. It can even put the stability of a system at risk as we make changes.

Our architecture must balance these opposing concerns. Let’s survey the different integration styles to see how they impact our systems, so we can take the best parts from each and bring them together in our new architecture.

Batch integration

When I started my career in software development, the major pain point for the industry was information silos...

As we have just seen, our ability to drive down lead times and iterate to innovative solutions is impeded by many forces. Lean methods and the cloud help us eliminate waste, but our software itself is an impediment to innovation. The complex dependencies within our systems necessitate inter-team communication and coordination, which consumes valuable time. The high coupling between components creates the risk of cascading failures when things go wrong. So, teams naturally slow down for fear of breaking things.

We need a new architectural vision. Our architecture must enable autonomous teams to move fast and limit the blast radius of honest mistakes. The following diagram depicts this architectural vision. Imagine a topology of autonomous services that we design for integration from the ground up:

Figure 1.5: Event-first topology of autonomous services and subsystems

Each autonomous service owns all the resources it...

In this chapter, you learned that the role of architecture is to enable change so that autonomous teams can continuously deliver business value. You learned about the various forces that impede a team’s ability to drive down lead times and iterate to an optimal solution, and you learned how dependencies and integration styles impact architecture.

We dug into the details of autonomous services, and you learned how to fortify the boundaries between services so that autonomous teams can have the confidence to move fast without breaking things. Along the way, you learned why the event-first approach treats events as facts, how a serverless-first strategy creates knowledge and makes autonomous teams practical, and why data gravity impedes progress.

In the next chapter, we will begin to define architectural boundaries by dividing a system into autonomous subsystems and those subsystems into autonomous services. Then, we will address the importance of continuous governance...