“We Don’t Need No Frickin Architects”
I’ve lost count the number of times that I have heard this statement (or some kind of derivative) during my career when mixing with Agilistas. The reasoning behind these statements is that architects are either defunct in the agile world, or that they need to roll their sleeves up and relearn to code alongside others in a delivery team. It makes no sense to over-egg the pudding.
I understand the reasoning, but as a Systems Thinker it is my belief that there is a need for architects.
Lets listen to what Dr Russell Ackoff, a Systems Thinking pioneer and organisational theorist, has to say on the subject.
A system has 3 properties:
- Each part of the system can affect the behaviour or the properties of the whole. They don’t necessarily do it all the time but they can.
- The way each part affects the whole, depends on at least what one other part is doing. The parts aren’t independent, they interact, they are connected. No part of the system has an independent effect.
- If you group the parts of a system into sub-groups i.e. sub-systems, they have the same properties the parts do. Every subsystem, or collections of parts, can affect the whole, and none has an interdependent effect.
The performance of a system is never a sum of the performance of its parts taken separately, its the product of its interactions. The performance of a system is based upon how the parts interact and fit, never on how they act separately.
There are many places where improving the performance of the part, will make the performance of the whole worse.
Architects knows this intimately:
- An Architect draws the house first; the whole, then he adds the rooms; the parts.
- He only improves a room, in a way that improves the house (the whole).
- Sometimes a part needs to be made worse to make the whole better. If he can make the room worse, but make the house better, an Architect will do it.
- The objective is to build the best house, not the best rooms.
If we have a system of improvement that’s directed at improving the parts taken separately, you can be absolutely sure the performance of the whole will not be improved.
The doctrine of the Western world is to think “divide and conquer”, if every separate part of the organisation is managed well, then the whole system will improve. This is absolutely false!
This is completely counter intuitive, we are committed to managing the actions of the parts, not their interactions. Most improvement programmes look to improve the parts separately not the whole. The whole is what should be the focus for continuous improvement.
In the above quote Ackoff is referring to the Organisation as a System, he is not referring to technology based systems. However the same thinking can be applied to technology based systems too.
We are encouraged in Agile to break work down into the smallest possible value adding chunks (often called either Epics, or Stories, or Features, or MMFs, or MVPs etc). Breaking work down makes sense. With the least amount of effort we can not only validate learning (by answering questions and testing hypothesis early, for example whether customers will use or buy our output), but also to minimise risk and possibly realise value earlier.
There are some thought leaders that even say that projects will soon become defunct, to be replaced instead by a constant flow of smaller chunks of work flowing through the delivery pipeline, with projects just becoming containers for these chunks of value adding increments.
As an Agile practitioner this is all good by my book, and makes sense to me.
But the Systems Thinker in me thinks differently. Lets listen again to what Ackoff is saying
“There are many places where improving the performance of the part, will make the performance of the whole worse“
“Architects knows this intimately”
So with a constant flow of small chunks of work, who is thinking about the whole? Who is concerned about the interactions between the parts? Who has the end game in mind?
I have spoken before about the difference between efficiency and effectiveness. Where efficiency is doing things right, but effectiveness is doing the right thing. My observation around Agile, Kanban and the like, is its all about efficiency, whereas we want to be more effective. I like the way a colleague of mine once put it
“We run the risk of rowing really fast as a high performing agile team, but in completely the wrong direction”.
As Peter Drucker says
“There is nothing so useless as doing efficiently, that which should not be done at all”.
So, we are at risk of building a whole load of well engineered parts that do nothing as a whole, or could in fact make things worse. Here is Ackoff again
When you try and put the best parts together you think you will get the best whole. This is wrong!
As an example, if you took all of the different cars on the market today, and asked a group of engineers which had the best engine, which had the best transmission, which had the best alternator etc and they took these best parts and tried to put them together, you would not get an automobile; the parts wouldn’t fit, let alone give you the best car in the world. It’s the working together that is the main contribution to systemic thinking.
Our entire culture is built on analytical thinking. The product of analysis is how things work, never why they work the way they do.
Analysis takes you inside the system, and how it works. It provides knowledge but not understanding.
By using a process of analysis you can reveal structure and say how something works, but not why something works in the way that it does.
Analysis has three steps:
- You take the thing you want to understand apart.
- You explain the behaviour of each part taken separately.
- Lastly, you reaggregate your explanation of the parts into an understanding of the whole.
Analysis became the dominant mode of thought in the Western world for hundreds of years. Today we still use analysis and thinking as synonymous terms. This thinking permeates all of our institutions, corporations, etc.
To reiterate, the process of analysis it to separate the whole into parts and study each part individually. Over to Ackoff
You will see this happening at an early age, if you give a child something they have never seen before, for example a puzzle, and they are confronted with a need to understand it, the first thing they will do is take it apart, the second thing they will do is to try to understand each part taken separately, then they will reassemble it to try and get an understanding of the whole.
This explains why inherently we feel that breaking work into parts to put them together again seems like a good thing.
To understand “why” questions, you need to use a process of synthesis. Synthesis is the opposite process to analysis and consists of three steps:
- You take the thing you want to understand as a part of a larger whole.
- You explain the behaviour of the containing whole.
- Lastly you disaggregate the understanding of the containing whole, by identifying the role or function of the parts.
Synthesis is an another way of thinking, it’s about making sense of the whole, which provides explanations of the behaviour of a system. You take the thing you want to understand and study it as a part of the larger whole.
If you want to understand how something works you use analysis, if you want to understand why it works you use synthesis. To be effective we should be using a combination of both.
The essential property of a system (whole) is that it cannot be divided into independent parts. If you apply analysis to a system, you take it apart and it loses all its essential properties, and so do its parts. This is easily demonstrated by Ackoff:
An example is a car, its a product of its parts. When a car is taken apart the system looses its essential property; moving from A to B. When we take a car apart we have cut its interactions. Not only that, we remove the essential properties of the parts. The motor cannot move from A to B on its own.
Here is another example, you can write, your hand can’t write, its easy to demonstrate by cutting your hand off and asking it to write, it wont do it!
As a sub note, I like the notion of Consumer Driven Contracts as an example of concern regarding interaction between parts:
A consumer-driven contract is a representation of a service provider’s obligations to all its current consumers. Consumer-driven contracts are created when each consumer communicates to the provider its specific expectations. The obligations created on the provider’s side establish a consumer-driven contract. As part of adopting a consumer-driven contract, a provider is free to evolve and innovate its service offering just so long as it continues to satisfy its existing obligations.
However I do wonder if this is merely concerned on how two parts interact with each other, rather than understanding the whole.
What we do need is architects, but….
What I am not advocating is the style of architect that contemplates their navel for months on end, or sits atop an ivory tower dictating policy, standards, monolithic specifications, and the “one right way” to all. I’m also not suggesting that we introduce inspection regimes, or to build gold plated enterprise solutions that we realise are either out of date by the time they are released, or that more nimble competition have beaten us to it.
What I am suggesting however, is the need for someone who understands the whole, with the ability to use synthesis in addition to analysis. Someone whom is viewed as an additional stakeholder by all of those involved in the creation of the parts.
The modern architect gets visibility of, and has interactions with, the parts, but also has an appreciation of the whole. Agile brings transparency to the development process that can enable an architect to see what’s really going on within the parts, that allows them to react based on their objective of building the best whole, one that meets the customer’s needs.
There is a balance. The objective is to build the best house, not the best rooms.