How do we practice architecture without turning it into a box‑ticking slog with little-to-no impact and tons of process overhead?
This is a tough question.
To unpack this, we need a good analogy. Let's pick an area where some preparation is important and the outcome can be uncertain.
You're leading a hiking tour group through some treacherous terrain.
You've got a pen, some paper, a compass - and some anecdotes from previous hikes about the territory.
You've got a few tools to help you navigate.
There's a campsite at the top of the hill. You've got to lead your group up the hill and then down the other side.
Importantly, you also know that this terrain could've changed since the last time you were here.
Let's get into it.
- Set Off On Your Journey
- Don't Forget Your Tools
- Descent: Just Be Pragmatic & Have An Impact
- References & Further Reading
- Footnotes
- Disclaimer
Set Off On Your Journey
"Software Architect" sounds old-school. But architecture is as relevant as it's ever been. There are tons of definitions of what an architect does, but I think most of them miss the point.
- "Software architects design systems."
- Sure - that is exactly what some technical architects do!
- "Architecture is just drawing boxes and arrows."
- This also might be true - humorously, every architectural diagram is basically "box-arrow-box-arrow-cylinder".
- Architecture is about making technical design decisions.
- Erm...maybe! But I think you'd find that any architect worth their salt is trying to avoid making too many decisions. Especially decisions that are hard to change later.
Let's forget about the boxes and arrows for a moment and return to our trek up the hill.
How can we ensure that we give our group the best chance of getting to the campsite at the top of the hill?- Some of our hikers are experienced, and some are not. All of them want to get to the campsite.
- We need to make sure that we're giving them the tools that they need to make the best decisions possible.
- Our experienced hikers might want to know about the terrain, and the potential pitfalls.
- Our less experienced hikers might want to know about the best path to the campsite, and how to avoid the pitfalls.
All our hikers want us to guide them safely.
We need to be able to do the following:
- Help our inexperienced hikers defer some decisions, avoid information overload, and avoid some pitfalls that would require a lot of time and effort to change later.
- Help our experienced hikers make the most of their knowledge to guide the group to the campsite.
- Help the group understand the terrain, and the potential pitfalls.
- Support the group, by helping them understand how our journey might go based on what we decide.
We need a series of maps or guides to support our group on this journey. Maps and guides with different levels of detail, intended for the different audiences.
Coming back to architecture, these hiking tips translate nicely into three different tools:
- Options
- Narrative
- Perspectives & Just Enough Design
All these tools are important, and they lead to a more-pragmatic definition of architecture:
Architecture is about telling a story that your audience cares about. A story about the past, present and future of a system. This story helps the audience understand the territory better, so that better decisions can be made.
Let's keep trekking up the hill and see how we can use these tools to help us get to the campsite.
Note: We're talking about ways of reasoning about systems problems (what we need to do now and what we need to do in the future). Systems problems are about people, organisations and technical systems. All three areas overlap and are important to consider when constructing a narrative.
Don't Forget Your Tools
How do we deal with the fact that our group of hikers are all different?
We probably need a few tools to help us create good guides and maps for them.
Tool #1 - Options
First up, what do we do when we get to a fork in the road?
We might have a few options:
- Go left, where the path is clear and well-trodden, but it is a little longer.
- Go right, where the path is less well-trodden, but it is a little shorter.
- Go straight, where the path is unknown, but presents an opportunity to explore something new.
Maybe we don't need to make a hard decision right now, and we can defer it to a later time. The left path is clear, and we've got a map that shows us the way.
It also loops back onto the right path after some time, so we've got a backup plan if the sun starts to set faster than we expected.
If we wanted to, we also have enough experienced hikers that we can trust to lead a smaller group down the right path, while the rest of the group goes left.
We know all this because of our experience and anecdotes from previous hikers who have gone before us.
We'd have to consider the trade-offs of each option and make a decision based on the cost.
The key point is that architecture is about giving the people, the business and the systems the ability to defer decisions.
Gregor Hohpe summed it up well:
In the financial world, an option is well-known as the right, but not the obligation, to buy or sell a financial instrument at a future point in time (or over a future time span for American-style options). An option is therefore a way to defer a decision: instead of deciding to buy or sell a stock today, you have the right to make that decision in the future, at a known price.
Translating the formula to IT architecture, selling options gives the business and IT a way to defer decisions. What size of server do you need to purchase for a system? If your application is architected to be horizontally scalable, this decision can be deferred: additional servers can be purchased later, at a known unit cost. What authentication mechanism should an application use? An architecture that properly separates concerns allows you to change that decision late in the project or even after go-live, at a nominal cost.
What can we do now that will give us the opportunity to make a decision in the future where we've got more information, and we're more likely to be right?
Realistically, you're not going to be able to do a high-fidelity calculation when you've got a group of weary hikers on a hill and the sun has started to set.
Your job becomes to have some really good heuristics for deciding to make or not make a decision. You also need to have some good ways of communicating the value (and potential cost) of the options to the group.
Tool #2 - Narrative
Overloading our hiking analogy - you've made it to the top of the hill, it's time to sit down around the campfire and tell a story.
You're telling a story about the day's hike, and how you got to the campsite - what territory you overcame, and what you avoided.
You're also telling a story about the next day and how you'll get down from the hill.
This story is important, because you need your tour group to want to follow you down the hill, and understand how what shoes you're wearing, or what food you're carrying will impact the journey.
Similarly, architecture is about telling a story.
If you're doing it right, you're telling a story about the past.
About how the decisions and non-decisions in the past got you (the system, the people, the company) to where you are now, and how what you do now will impact where you get to in the future.
Then - it's about telling a story about the future. What can we expect if we make certain decisions now? And what can we expect if we don't make those same decisions now?
This type of story telling isn't supposed to be divination around a fire. It's about using a map to build conviction in the choices you're making.
The important part of story telling is in understanding the audience and the level of detail that is just enough to take them along the journey with you.
Tool #3 - Perspective & Just Enough Detail
If we were trying to build a truly comprehensive map of a city, we'd need to include every single street, building and region. We'd also need to include thematic information (temperature, elevation, precipitation, etc), that can't be captured in the geographical features.
For the hiking trip, a map might need to include information about the terrain, the weather, the time of day, and the location of the campsite. All of this information is important to have, but it's not all equally important to have at the same time.
Comprehensive maps are interesting to look at, but they are worse at solving specific problems when compared to maps designed for a single reason.
A map needs a purpose, and it needs to contain a limited set of information, so that it's narrative isn't too complex to follow.
- For planning which day to start our hike, we need information about the weather. We probably don't need to know too much about the weather in the city, or the wildlife on the trail.
- For setting our route up the hill we need information about the terrain and the location of the campsite. We also need to know about our hikers and their experience. We don't need both of these on the same map, but we may use them together to make a decision.
- Lastly, to keep our group as safe as possible, we need to know about the potential pitfalls of the trail. This is a single map, that we can use to guide our group along the journey.
So it seems that we need a few different maps to help us achieve our goal.
If you're one of the hikers on the trip, you might not need all the same maps that the guide needs.
The same principles apply to software design, and architecture.
- Does a presentation to executives need to show every single line of code in the system? Probably not.
- Does a system design document need to include projected EBITDA calculations for the next 5 years? Probably not.
- Does an integration architecture diagram need to include detail about the type of database used in the system? Probably not.
We always need just enough detail to guide the decisions (or non-decisions) an audience needs to make. Architecture isn't about wasting time re-mapping information that is already known, or obvious.
The multiple maps and combinations of maps can collectively be called perspectives.
These perspectives are just different points of view, with different levels of detail, that support different audiences in achieving their goals.
This hiking trip had two parts:
- The ascent
- The descent
We're now ready to start our descent, where we'll see how our options, perspectives and narratives play out in the real world.
Descent: Just Be Pragmatic & Have An Impact
All the planning in the world can't make up for a lack of pragmatism when reality doesn't match our plans.
We led our group up the hill, camped out for the night and we're ready for the next leg of our journey.
As we look down the hill, we see a very different picture than what we had expected.
Our group feels uneasy, but they remember the story around the campfire last night. You told them about how the descent might have changed and the ways it could be different.
They're ready to follow you down the hill, even though they're not sure what the path ahead will be like.
This is the time when we need to be pragmatic, all our maps and perspectives have become slightly out of date when presented with an unforeseen challenge. But as the guide, you had an upfront understanding that things may have changed - and so you are as ready as possible to make the best decisions for your group.
We need to finish this hike today - we start our descent. We understand the strengths and weaknesses of our perspectives, decisions and our group.
The road ahead isn't one we've travelled before, but we've got the tools (and experience) to make it work. We know that we need to be flexible and that we need to tell an ever-changing story as we go - to keep our group safe and on track.
We can't stop for long periods of time to draw maps, and we can't expect our group to be able to follow a map that is too detailed.
This reality is the same when building and evolving software systems for businesses. You can't be prepared for every possible scenario. You can be prepared for the fact that change and unforeseen challenges are a part of life. This is a part of the options you create, the perspectives you choose, and the narrative you tell.
This is how architecture has an impact.
References & Further Reading
Footnotes
- There's probably a lot more that could be said about options and architecture. The core of the idea is that decision deferral is a key part of architecture and a good mechanism for understanding the cost of things.
- Financial options are a heavy concept to describe a simple mental model. Architecture should be creating the opportunity for the business to choose to do (or not do) things in the future. Reduce forcing functions and increase immediate agency.
- Storytelling really is very important. In the absence of a good story, it's hard to get anyone to follow you down the hill. Don't forget that your audience is at the core of the story you're telling.
- Stefan Tilkov talks about different perspectives, and how to choose perspectives in this great talk about Practical Architecture.
- Architects really shouldn't be spending tens of hours writing documents and drawing diagrams. But distilling the essence of a system into a few key perspectives is a great use of time.
- A lot of the upfront calculations that architects might do are based on assumptions and experience. But these are not the only sources of information.
- The best architects are able to use the experience of others, and the experience of their own team to make better decisions. Read, Watch, Listen and Learn.
Disclaimer
- The ideas and opinions expressed here are entirely my own and do not represent the official stance of my employer or any organisation I’m affiliated with.
- I'm trying to create my own map of the architecture role in an organisation. There are an abundance of definitive guides to practicing architecture out there. This is my own attempt to create a map that is more useful for me.