Updated: Updated: Architecture
This post is the 2nd part of a mini-series titled “Think Like An Architect”. Part 1: Famous Architects Sketch
It’s fair to say that sometimes architects see things that others don’t. Claiming that this makes architects a kind of mystic seer is likely a stretch. Nevertheless, I have repeatedly seen folks who were stuck being helped by an architect who had a different view of things. After that, suddenly everything made sense.
Rectangle and Circle
Seeing more doesn’t just mean having better eyesight, it also means seeing more dimensions. Imagine the following situation:
Two people are arguing about the shape of an object. One person keeps claiming that it’s a rectangle while the other insists that it’s a circle. The discussion keeps going: “rectangle!”, “circle!”, “come on, it has 4 corners!”, “what? It’s as round as it gets!”. Because a circle and a rectangle are in fact quite different shapes, a reconciliation is nowhere in sight. Both parties being intelligent people rules out lack of understanding as the reason that they’re butting heads. An architect comes in and notices that they are both looking at the same object: a cylinder.
The person looking at the cylinder from the side will precisely see a rectangle. Likewise, the other person, who is looking at the same object from the top, is unmistakably seeing a circle. As long as each participant keeps their perspective, they can keep arguing for a very long time. That’s why software pioneer Alan Kay famously said:
“A change in perspective is worth 80 IQ points.”
That’s a powerful statement but also a great relief. The architect doesn’t have to be the smartest person in the room. Instead they make everyone else smarter.
Architecture is a Matter of Perspectives
IT deals with enormous complexity: beneath the sheer number of systems sits such a dense web of interdependencies that you wouldn’t be surprised if a butterfly flapping its wings causes a hurricane or perhaps a system outage.
We cope with that complexity by using simplified models or projections. The popular 4+1 architectural view model is a typical example. To reason about and depict the architecture of an application, this model proposes the following views:
- The logical view depicts the functional structure of the system, usually via class diagrams.
- The process view depicts the system’s processes and behavior, e.g. via state diagrams.
- The development view illustrates the software modules.
- The physical view describes how software artifacts are deployed to infrastructure resources, e.g. servers.
- Scenarios validate the design by mapping use cases across the other views (hence the +1).
These views place different lenses or filters over a system to make describing the system’s structure and behavior easier. However, we have to remind ourselves that each of these projections is a vast simplifications of the underlying system. Views primarily exist to allow us to understand the system more easily.
The Power and Danger of Models
Architects think in models - that’s how they tackle complexity and make better decisions than just following their instinct or listening to the loudest person. The views above are models. However, models are simplifications and we know well that all models are wrong (see The Software Architect Elevator). Generally, that’s OK. Models can’t match reality because then they wouldn’t abstract things or reduce complexity.
The models you choose will influence your thinking. You want simple but not simplistic models.
However, the model you choose will influence your thinking. A powerful example, which I conveniently snagged from a presentation by Dave Farley, is given by two models of the movement in our solar system:
In the olden days, the earth was assumed to be in the center of most things, leading to the geocentric model on the right. This model works alright for the movement of the sun, but unless you are trying to create abstract art, the movement of the planets is rather complicated and difficult to explain. Nevertheless, this was the model largely favored by religious scholars. In IT, this would be the reference architecture defined by ivory tower architects who are more content with satisfying a specific structural rule than the actual behavior of the system (replace “earth” with “core system” as you please).
Copernicus must have seen something wrong with this model and derived an alternate model that places the sun in the center, appropriately called heliocentric, as shown on the left. In this model, the movement of the planets appears much more organized and plausible. You can think of Copernicus as the change agent who put up such heretical ideas as running other people’s software being a bad deal.
Dimensionality
So, our cylinder story above involves two people who use different models. Just like Copernicus and his predecessors looked at the same movement of the planets in the sky, they had very different ideas of what they are looking at, just like circles and rectangles. And because people’s view is rooted in two dimensions, the idea that the same object can have different shapes depending on the angle from which you look at it will seem very foreign to them.
Architects rely on models and projections but realize that those are rooted in the same underlying system.
Architects like models and projections but they realize that the projections don’t live in isolation - they are rooted in the same underlying system. That’s why architects tend to get stuck less often in circle vs. rectangle debates.
I am sure you have witnessed circle vs. rectangle debates in IT. An example from my book recalls a conversation related to an in-house web platform. A customer inquired on port forwarding of incoming HTTP requests. The architect answered that they don’t provide a web server. A lengthy circle vs. rectangle debate ensued because the customer wasn’t asking about a web server. Her other systems handled port forwarding via a traffic management system like F5 Big IP. The long discussion related to web servers therefore didn’t make sense to her. The architect and her looked at the system from a different perspective.
Human Dimensions
Like many other architecture topics, dimensionality doesn’t just apply to technical systems but also to organizational ones. And the conversations can get stuck just as easily as in the circle vs. rectangle debate. A great example is the discussion of team autonomy versus alignment. Most managers assume that giving teams more autonomy means they are all over the map, i.e. not very aligned. Hence they believe that they have to choose between one and the other - circle or rectangle, but not both.
Spotify has realized that what makes autonomy work is in fact alignment, as nicely illustrated in one of their engineering culture videos:
The need for alignment as a precondition of autonomy, not the inverse, is well explained in Stephen Bungay’s excellent book The Art of Action. Organizational architects also see the cylinder.
Bringing New Models
When an architect encounters stalemate situations that look like a circle vs. rectangle debate, they will try to find a new model to demonstrate that everyone is simply looking at the same thing from different perspectives.
Mind you, though, questioning existing models isn’t without risk - people ended up on the pyre for placing the sun in the center of the solar system. Such is the glorious life of an architect.
