CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 31, NO. 7
 

Software architecture requires balance. Often, you can focus too much on it, creating robust products that miss customer needs or over-engineer solutions. Conversely, especially in Agile contexts, you can under-engineer things and your product efforts can succumb to relent­less refactoring rework. So there’s a balance to strike in architecture, no matter what methodology you use to create your software. In Agile contexts, that balance is often lost. And it usually leans to less over more.

During the 20 years I’ve been leading technology organizations to build products, mostly via Agile, I’ve learned some rules that have helped me — and my teams — successfully strike the right balance. These aren’t technically focused rules; they’re more generic, so they apply to monolithic, layered, service-oriented, and microservice architectures equally well. Let’s dive into the rules and see if you find some value within.

Rule #1: Allow the Architecture to Emerge

At some fundamental level, Agile thinking is experiment-driven. That implies that we want to create prototypes and mock-ups and hack sufficient code to allow us to experiment with different approaches to building our architectures.

We don’t want to design in one large lump — ever! Instead, we want to create a layer or certain amount of architecture (services, plumbing, back-end functionality, etc.) and then build something on top of it. That something should be valuable to our client or customer, but not cost too much to build. It should be something easily demonstrated and validated. Something easily changed.

This is what I mean by allowing the architecture to emerge. Instead of being presumptuous and building all the plumbing before we layer anything on top of it, we build in slices or increments. There is a term the Scaled Agile Framework (SAFe) community uses called “architectural runway” (sometimes I simply call it “architectural look-ahead”). It is measured by how far your teams are looking ahead to consider architectural implications before building on top of it (or integrating it). Traditional waterfall teams look ahead over the entire project. Agile teams look ahead a few sprints to no more than a release or two.

You should use caution here around the balance between architectural look-ahead and rework. On one hand, if you don’t do any look-ahead, then you’ll constantly be reworking everything, which will slow you down (or stop you entirely). On the other hand, if you look ahead completely, without experimenting and implementing your ideas, then it will take you a long time to integrate and make it work — again, slowing down or even stopping your progress.

So there is a trick to balancing between looking ahead over the entire project and looking ahead a few sprints (usually relative to the technical and business context you’re in). If you’re effectively focusing on the journey, then you’ll find the right look-ahead balance for your context and your teams.

Rule #2: Treat Your Architecture Like a Product

I’ve always appreciated it when an organization develops a backlog of architecture stories that it wishes to integrate into its products. The stories are usually different from functional or feature-driven work, in that they might be below the surface or infrastructurally based. But they are important to articulate so they gain visibility. By putting them in a backlog, you start to do things that product owners typically do:

• You groom or refine these stories with the development team(s).

• You define acceptance criteria that capture the essence of what “done” is for each story.

• You discuss the level of effort (points) associated with each story, including testing effort.

• You slice the stories (decomposing them) along execution boundaries.

• You discuss the strategy of how individual stories are implemented to meet an overarching release or architectural goal.

• And, you have value-based discussions, talking about the business value of each story, including the why behind each and the customer impact.

An important aspect is the experimentation or exploration part. For example, if you have a feature idea that you think a user would value, you might define a minimum viable product (MVP) for it and whip up a quick/cheap prototype before making a final implementation decision. If the feedback isn’t positive, then you’d quickly pivot in another direction.

The point is that I want the same level of thoughtful planning to occur for architecture as for features. In this way, as with features, everyone becomes a stakeholder in the architecture. That means stakeholders understand the motivation, agree with the business case/investment, and understand the customer impact/value of the shared architecture.

Rule #3: A Picture Is Worth …

It may be my narrow experience, but most Agile teams I encounter develop few to no diagrams or high-level views of the architecture they’re implementing. Instead, they allude to “being Agile,” where architectural docu­mentation is unnecessary, which implies that you simply collaborate around the code and magic (emergent architecture) occurs.

One factor influencing this approach is a fundamental misunderstanding of this Agile Manifesto point: work­ing software over comprehensive documentation. Another factor is that these teams have historically written large-scale documents that have not served them well. Thus, they’re scarred by lengthy, but mostly wasted, efforts.

Now, I am an old-school developer who doesn’t feel that documentation is inherently bad; particularly high-level, big-picture elements that show teams where they’re going from an architectural perspective. A technical roadmap, if you will. Aspects of this architectural roadmap include mapping out a big picture of your business and technical architectural intentions on a whiteboard (virtual, if you can). It is important to align the business view (value streams, strategic roadmaps, high-level personas, story maps, release plans, etc.) with the architectural view (designs, interactions, flows, critical constraints, technical layering, etc.) so that you and your teams have a more balanced view of the goals. This might sound like a lot, but keep in mind that it’s a high-level view.

Another aspect of the roadmap is keeping design snippets on a wiki or within your user story definitions. With whatever you document, keep it simple, up to date, and relevant to your teams. The final arbiters of the completeness of your documentation (i.e., whether you’ve defined enough) are the teams themselves.

Finally, the key to architecture is the same as with the user story: communicating, collaborating, and interacting around the documentation. The conversations are the most important thing. And that means continuous conversations between your business stakeholders, architects, and your teams as well.

Rule #4: Everyone Is an Architect and Everyone Owns the Architecture

There must be a fundamental shift when moving to developing architecture in Agile contexts: from a singular view, where there is an architect that delivers it to the teams for execution, to one where, although there might be experienced architects, everyone on the team is responsible for and thinking about sound architecture investments. Instead of it being an individual responsibility, it’s an organizational or cross-team responsibility. I often call it the “No Glass House” rule, where we avoid a functional silo (team, group, individual, etc.) solely looking after architecture. Instead, I want everyone thinking of solid design, testability, performance, security, user experience (UX) design, simplicity, and maintainability.

In addition to the technical aspects, I also want everyone to be thinking of the business rationale behind the architecture. Why are we doing it? What problems are we trying to solve? What’s the business case and value proposition? And how does it fit into the flow of the business from a value stream perspective? Some will certainly have more experience in these areas than others, but everyone can put on the hat of the organi­zation, business, and architecture, and consider the implications throughout his or her work.

Another part of this is holding the team (each other) accountable for building wonderfully architected products. The goal should be products that will stand the test of time and wow the users with their intuitiveness, robustness, and reliability.

At iContact, where I was once VP of engineering, we would canvas our customers after moving to Agile to determine what stood out in their minds. Since we were doing quarterly releases (i.e., release train model) and had more than tripled our feature productivity, you would have thought that our speed and increased features would have been top of their minds. It was, but the number one thing that stood out to them was the overall quality improvement of our products and how we were better connecting to their UX needs.

In other words, architecture (quality, robustness, simplicity, etc.) mattered to our customers the most. Those improvements were what grabbed their attention as we continued to evolve and deploy our products.

Rule #5: Keep It Simple and Connect to the Business

This rule is quite near and dear to my heart because I really like complexity. I like engineering complex solutions to simple business and customer problems. And it’s also quite comfortable for me to fall into that over-engineering, gold-plating, doing-more-than-is-required mindset.

Why? Because I can. Because I’m an engineer, and the more complex and elegant the solution, the better I feel about my capabilities. It makes me smile.

I think a lot of engineers are like me, but it’s the wrong approach; even though it’s often easier than thinking deeply about the problem or challenge and then find­ing the simplest possible thing that could satisfy your stakeholders.

One way to combat this tendency is to focus on MVP-like language. Words like ”minimum” and “viable” can more narrowly focus our efforts. Another important activity is sitting down with your business partners to understand the why behind their requests. People often describe this as a challenge because, as business stakeholders, they are too busy to explain their needs. I’d argue that if they’re not too busy to spend corporate funds on solutions, then they shouldn’t be too busy to ensure that those solutions meet their needs. Whether they’re internal customers, external customers, or both, busyness is often more excuse than it is reality.

If appropriate, including UX activity is an important part of the discovery and design process. Far too often, groups do either too little or too much UX. Either they skip it and dive into solutioning far too soon, or they go into an analysis paralysis state and do UX for months without truly engaging the teams and customers directly.

An important part of business connection is ensuring that stakeholders get into the demos and verify/sign off on the solutions the teams are providing. This notion of demonstration, feedback, discovery, and ultimate acceptance is crucial for closing the delivery loop. It is also vital that stakeholders stick to their word when it comes to those signoffs.

Rule #6: Build in Testability and Resilience

As I defined my rules, I wanted to recognize the quality and testing folks who would be reading them. One of the keys to a solid architecture is considering how your organization will test it. This is true not only from an end-to-end perspective, but also when considering areas like usability, performance, security, reliability, and resilience. You must make these investments in quality and testing transparent to your stakeholders and help them realize their value proposition.

A famous example is Netflix’s Chaos Monkey appli­cation, which would randomly remove servers and services in its production and testing environments. It simulated various forms of failures, which encouraged teams to improve the resilience and test for it in product development efforts.

In Agile contexts, the focus on test-driven development, behavior-driven development, and acceptance test-driven development also encourages testing, which can be extended to architectural elements. In fact, architecture stories — yes, there can be such things in a backlog — can and should have testability requirements called out in their acceptance criteria.

I consistently try to remind the Agile teams I coach to consider quality and testing in their user story estimates and not to focus solely on implementing the functionality. There’s so much more involved in creating robust, testable, and resilient applications. It takes design thinking and, often, support from the underlying architecture.

Don’t be afraid to invest in testing automation or infra­structure that eases the burden of and lessens the time for testing. Clearly, Netflix saw the development of Chaos Monkey and similar investments as enabling it to move more quickly, while also maintaining product resiliency.

Rule #7: Admit That You Don’t Know

One of the first things I’d like everyone to acknowledge in software architecture is that we most often haven’t done before what we’re being asked to do now. That is:

• We’re clueless about what the design approach should look like.

• We’re clueless about the tools/techniques we’ll use.

• We’re clueless about the environmental considerations.

• We’re clueless about the UX implications and what the customer truly needs.

• We’re clueless about the performance implications.

• We’re clueless about how to test our solutions.

• And we’re clueless about how long it will take to complete our work.

I think the most important acknowledgement or statement that we should all agree to early on in any architectural discussion is that we don’t know. Out of this level of openness and honesty comes the need for prototyping, discovery, and learning. It’s hard to do that if we don’t look each other in the eyes and say, “We don’t know, let’s find out.”

Once we do that, the focus needs to turn to learning, which is something we can all do. Here are a few techniques for approaching this learning:

1. Working code is the great leveler. So, as much as possible, pull together prototype code to learn. The prototypes should be cheap and fast. They’re not production code; instead, they’re learning code or experimentation code. This includes paper prototypes and similar tools from a UX perspective.

2. User story spikes are the best way to capture these activities. Write a spike for each and every major learning activity. Take the time to clarify the acceptance criteria for each. In other words, what key things will we deliver or complete to more fully understand this aspect of the architecture?

3. As mentioned earlier, SAFe has the notion of architectural runway or architectural look-ahead. So, not only do we need to capture spikes and write code, we need to forecast enough in advance that we’re “ahead” of our product development needs.

Consider working code the ultimate clarifying view of your architectural understanding. Aspire to code over study, documentation, and talking about the architecture. Instead, build prototypes as soon as possible, get to working code, and ultimately improve your knowing.

Rule #8: Demo Your Architecture

An extension of the working code points discussed above is demoing your architecture. It is incredible how much pushback I receive on this idea in my coaching. It seems Agile teams are comfortable demoing end-user functionality, but incredibly uncomfortable when you ask them to demo architectural elements. You’ll usually hear excuses about there being no UI, or it takes too much extra effort to expose the architecture, or it would be too hard to measure attributes of the architecture in clear business terms. You may also hear that most stakeholders (executives, customers, managers/leaders, etc.) don’t really care about their architectural, infrastructural, automation, and other “plumbing-oriented” types of work. They only care about customer-facing features (MVPs) and things they can see, understand, and charge for.

Stakeholders view demonstrations of this sort to be too technical and hard to understand, self-serving exercises that only benefit the teams, or boring and a waste of time. But I like to confront this perception and try to influence stakeholders to endeavor to understand and engage with more technical demonstrations.

Why? Because they should care. They are certainly paying for the architecture and they should try and understand the complexity and infrastructural demands within their products. They do not have to understand the architecture the way the teams do, but from the business, value and impact, competitiveness, and investment perspectives, the team’s business partners do need to care. Demoing architecture is a wonderful way to provide stakeholders guidance toward this improved understanding. Over time, they’ll start to get a feeling for:

• Architectural investment percentages

• Costs associated with their demands/decisions

• Tradeoff decisions

• Risks associated with architecture (implementation and delaying updates)

• The drivers behind refactoring

• The investment “mix” of features versus architecture inherent to each of their products

All these elements lead to improved understanding, empathy, and respect for all aspects of their products. I’ve found that stakeholders who embrace their archi­tectural investments are far better decision makers.

Rule #9: Chaos Is Constant, So Continuously Refactor

Let me use an analogy to begin to explain this rule: I am a home owner in the US state of North Carolina. Our climate causes specific types of degradation in my home, and there is simple aging to contend with as well. As a result, I find myself investing annually in the upkeep of my home and its systems. I view it as a “pay me now” versus “pay me later” decision, and I like to keep my home nice, so I lean toward pay me now.

Some of my neighbors have the reverse philosophy. An example can be found in house painting. I’ve been painting on a regular schedule, every five years. Some of my neighbors paint only when things are obviously falling apart, as evidenced by exposed wood, wood rot, and severely peeling paint.

My strategy is more of a preventive approach and the costs are frequent but low. My neighbors, on the other hand, have less frequent payments when it comes to the exterior of their homes, but when they do pay, it’s more costly. For example, they might need to replace all their siding because they haven’t painted it in 10-plus years.

I tend to update to new technologies as well. For example, a few years ago, I updated my HVAC sys­tems to much more efficient units. Not only are they more reliable, but I’m saving a lot of money with their increased efficiency.

Switching back to software and architecture, I always recommend the same strategies for software development products and applications. We must acknowledge that software ages and our approaches and tools evolve, so we want to continuously invest in the care and feeding of our products. That investment needs to be part of our business case and factored into the ROI.

This isn’t just at a feature level. I would argue that it’s even more important to keep the plumbing (infrastructure, tooling, automation, architecture, design, integrity, performance, maintenance, etc.) up to date as well. Your stakeholders may not always see this investment, but they will experience whether you are, or are not, making it.

Finally, I am a proponent of asking my teams about technology evolution and trends and determining how we want to invest along evolutionary curves. This includes new technology, new tools, and new approaches. It’s important to listen to your team and trust your team in these recommendations. They’ll know far better than you what the relevant trends are and the value that updating can bring to your business and customers.

To return to my analogy, don’t wait until your house crumbles and you must rebuild from the ground up.

Wrapping Up

That’s it. Consider these the nine Rings of Man from The Lord of the Rings. Now if I were asked to share the one ring to rule them all, it would be balance: getting to the point where you define, refine, and implement just-enough and just-in-time architecture. May you eventually find that one ring to rule them all.