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 relentless refactoring rework. 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.
One of those rules is to demo your architecture. In my coaching, it is incredible how much pushback I receive on this idea. 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 (minimum viable products) 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
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 architectural investments are far better decision makers.
[For more from the author on this topic, as well as his other rules, see “9 Rules of Agile Architecture.”]