1. Systems thinking

Why it matters

Architecture impacts more than we realize. Therefore, we have to consider the effect on other system capabilities when making architecture design decisions and tradeoffs.

We often say architecture should serve the users, but it should also serve the people that create the solution.

Example: If we have a solution that makes it very complicated to deploy the system, the organization will create rigorous processes around deployment and deploy less frequently than if the task was straightforward. Perhaps they will even create a special organizational unit that manages deployment.

Architecture ties us to our past. If we want to simplify deployment in the future, and even if we found an elegant technical way to do so, it’s no longer a purely technical challenge. Such a change requires a coordinated change in the organization and process at the same time.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
— Melvin E. Conway

How it works

Let’s unpack Conway’s perspective of interconnected system capabilities. If you prefer to stay with Conway’s simplified perspective, feel free do to so. We will argue that for achieving an Agile architecture, you have to pay attention to five system capabilities since they move together.

Axiom 1: Architecture and tooling impact, and are impacted by Competence, Culture, Clarity of Purpose, and Organization.

Axiom 2: Process is the product of our system capabilities.

An Agile team surfs on the product of an organization’s system capabilities.

Let’s elaborate

Competence: You choose a solution which you are competent enough to implement. You can also choose a solution because “I would like to learn (X)”.

Culture: You have likely stumbled on “not invented here” at some point in your career. Your self-image impacts what solutions you choose. Another example is the level of trust, “only people in operation are allowed to deploy to production”.

Clarity of purpose: If you don’t know where the company is heading, you would likely lock yourself into solutions that will hamper future development. Let’s consider the navigation of autonomous vehicles, are you developing solutions for local commute in urban areas or for traveling across the country? The choice of direction has a direct impact on the solutions options to explore.

Architecture and tooling: “Let’s build the solution based on the framework we have ”.

Organization: “But we have a development organization in (insert favourite country here), they could build this…” Another case of creating a solution based on the organization you have, over the one you needed.

A badly built solution can limit a company’s growth opportunities and drive up the cost of operations. It’s no easy feat to find a balance between over-engineering and under-engineering!

How can I make architectural tradeoffs less daunting?

The next time your CEO has opinions about architecture, avoid shutting him out, instead, hear him out. The architecture serves the goals of the company. Since you are in the same boat, row in the same direction.

The second habit is to take a system perspective. When you are changing the architecture, ask yourself these questions:

● How is the architecture impacting dependent system capabilities?
● How are dependent system capabilities impacting architecture?
● If we change our architecture towards the desired direction, will dependent system capabilities inhibit or enable such a change?

Based on these questions, if dependent system capabilities inhibit an architecture change, then change them together at the same time.

The system impact of architecture is one reason why choosing a simple solution over a complex one is preferred, unless you have compelling reasons to do otherwise.

References

Conway’s law, Wikipedia