Drawing makes for an easy life (devs and architects)
Lets establish a core fact first; I am no artist and my handwriting is pretty atrocious. Whilst that’s a limitation at times; I can still draw a few boxes and arrows and most of the time my hand writing is good enough to be legible.
Despite this, I believe that drawing is one of the most useful tools we all have. This was reenforced in spades when I attended MapCamp 2018 recently. I’ve been won over in recent times by Wardley mapping as a model for making and communicating decisions. As the creator (Simon Wardley) says, there’s no such thing as perfect communication, only less bad and Wardley mapping is certainly one of the least bad mechanisms I’ve used.
From day one of coding I’d always have a pen and a scrap of paper by my desk; now I’m no artist by any means, but that pen and paper saved me so much time it was incredible. I used it for all sorts. When people talked about the problem to be solved I’d draw the interactions. When I read the codebase I had to contribute to I’d draw the key files and how they depend on each other. But most importantly for me as a junior developer through to an experienced architect, before I make changes to a codebase I draw how I see the solution; which files were changing and what they would depend on. I can’t count the number of times these diagram bring corrections to the fore before coding starts.
Take this diagram; it’s easy to glance at it and recognise some poor naming conventions, or gaps in reuse of existing content. As a developer, this makes it much easier for my peers and seniors to guide me. Sometimes it is just in the process of writing it down that causes me to understand what I’m doing better; but this is also an incredible tool for talking with other team members to identify gaps.
The power of a picture (no matter how ugly); is worth a thousand words I’ll never write. I progressed from rough doodles to selective use of UML; I’m a particular fan of sequence diagrams. If you haven’t used it yet, the C4 model is also fantastic. These have been a massive help to me in structuring information particularly as projects get larger; or when governance boards with less context need a walk through.
When it came to decision points though and communicating professionally with non-technical people; I usually resorted to light weight diagrams (to avoid technical distractions), complimented with pros and cons lists for the likes of ‘architecture diagram A’ or ‘architecture diagram B’. While it often works, it can result in discussions about all sorts of detail on the architecture. With this style of communication is people tend to either read just the first couple of points or pick out the bullet points attached to their personal agenda. This can be dangerous as it doesn’t easily direct the audience/ contributors to the high value discussion.
In come maps; so if doodles, C4 and UML are good; maps are awesome.
How often do you use the written directions which google maps produce versus the pictorial representation? A map gives a sense of direction at a glance; you can see the big picture but also the long stretches. the complex corners and roundabouts. Wardley mapping is based on a similar premise.
The beauty is, Wardley maps don’t need much explanation. Start at the top with the problem you want to solve, then break it down into components. For each component, plot it on the Y axis based on it’s value in your problem domain. Then plot it’s X axis based on the evolution level of the solution you’re using/ proposing. It’s possible then to pin point where you’re investing in low value custom built solutions. This also shows where you should seek commodity solutions for low value components and invest more in the high value components. As an organisation a Wardley map can be used to map a way forward and increase focus/ investment on the components at the top of the value chain.
That’s not to say Wardley maps are easy; the process of creating them requires much debate and discussion as plotting is subjective. But the conversations generated regarding business value and evolution can be enlightening.
The map can then consumable for a wide range of stakeholders, showing the direction of travel, bringing both technology and business leaders along the journey.
At the most recent mapping conference (Map Camp 2018) there was significant discussion on the use of this as a tool for strategic decision making. This isn’t just a tool for the scrum team, but a map that can be understandable by C level folks to support investment. I was delighted to see high profile leaders like Liam Maxwell (National Technology Advisor, HM Government), Julie Pierce (Director Openness, Data & Digital at Food Standards Agency) and Danielle H-Wilson (Head of Business Architecture & Analysis at Co-op Digital), all presenting on the value they’ve seen in this approach.
Reading Simon Wardleys online book followed by some practice is well worth some of your time.