My first ever job in the corporate world was as an IT architecture intern. Given that my prior working experience to that revolved around fried chicken (mind you, a great way to learn about Lean, customer experience, and countless other valuable life lessons), I thankfully wasn't in charge of designing anything. I supported the enterprise and solution architects as they created slide decks full of roadmaps and stacks and talked about SOA and ESBs.
We would get heavily involved in prescribing how components should interact, everything from the applications themselves to interfaces and even data flows - and representing it all in an unfamiliar language of boxes and lines and circles - UML, no less.
It was quite fascinating to be mapping out entire systems and the flow of information, but in a theme that I would later witness across many different architecture teams, I noticed that the tendency to want to understand and define everything could often add distance to the key problems our customers were trying to solve.
Making software architecture more accessible
His C4 model is just one of his creations that I recommend you investigate no matter what type of models you create - software, business process, or even user journeys. At its core, the C4 model is about the mindset of recognising the necessary level of detail for the context, and simplifying the communication to be as simple as possible to make architecture accessible – taking a leaf out of Ben Schneiderman’s work on interface design.
In real world terms - think of software architecture diagrams as maps. On a map of the country, you wouldn't show all of the streets and their names – you would start with the cities, and then show the major roads, if necessary. In modern terms, you would 'pinch to zoom' in or out as required to reach the necessary level of detail in order to satisfy your purpose. Think about how many software architecture diagrams you’ve seen which could suit this real-world like description.
Architecture and 'real world' complexity
“You don't build your things with your own hands. I do not know everything. And your building is not your own building. The best thing that can happen to a building is that it has a life on its own. You will just create the beginning and then who knows where it's going to end? So forget about control.”
I draw parallels to the fantastic work being done on complexity by Cognitive Edge and in particular, their approach to sense-making. They believe that the signification of a system (in a holistic sense, not just software) comes from people within the system themselves and that the interpretation and design of interventions require a balancing of viewpoints based on the context. That’s definitely a topic for another day.
An agile approach to architecture
So what have I learnt since those halcyon days of youth (-ful IT architecture roles)? It’s that our best creations aren't just highly decoupled services, nor are they flawless UML diagrams, but in fact it's about making architecture accessible, and giving people who interact with our creations the ability to achieve a purpose.
Whether it's at the code or component level, and whether it be economic or social outcomes being sought, learning from the real world and using an agile approach to design might just give us the best chance to adapt and respond to the ever-growing complexity we face.