What maps and the real world can teach us about software architecture - why innovation!

why innovation! uses cookies to provide you with an optimal browsing experience on our website.
Please check our Privacy Policy & Terms of Use to learn more about how we use cookies.
By clicking on “I AGREE”, you consent to the use of cookies.
Sign up   |   Sign in

What maps and the real world can teach us about software architecture - why innovation!

Daryl Chan 3 min
What maps and the real world can teach us about software architecture
It was quite nostalgic for me last Friday night when Simon Brown, a respected figure in the software architecture community, came to speak to the Agile Hong Kong Meetup group about "The Art of Visualising Software Architecture."
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

Simon’s talk covered the way we create and communicate a shared vision around software architecture. He shared some strategies for abstracting software architecture without compromising well designed and functional software.
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

​It was also quite timely that last week the Pritzker Architecture Prize (real-world, that is), was awarded to Chilean architect Alejandro Aravena – described by the jury as “leader of a new generation of socially minded architects” (The New York Times, January 14, 2016). He recently had this to say on the role of architecture: (Dezeen, January 13 2016)​

“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.”
Inside the UC Innovation Center – Anacleto Angelini. Flickr: leonardo_mh 
If it wasn’t already clear, he’s a strong advocate for participatory design and ‘open systems’, believing that "the battle for a better built environment is a collective effort that requires everybody’s force and knowledge” (The Guardian, November 20 2015).
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

This viewpoint is also rather complimentary to Simon's view of software architecture – design should not be abandoned completely, but design should also not be too focused on definition over observation – a principle which is key to the success of the Agile mindset in complex environments.

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.

Daryl Chan
Twitter: @hello_daryl
LinkedIn: darylchan
Register on our website to receive our latest information! register
Follow us on social media