On the road to democratising architectural design
Conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. … Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.
- The Mythical Man-Month, Frederick P. Brooks Jr.
I’ve found the mythical man-month to be a fantastic book — almost set in an alternate reality, where some concepts have aged incredibly poorly, yet are sat alongside concepts that could describe a situation I faced yesterday at work. But the above quote is something that always stuck with me. Software development runs as smoothly as possible, when the system is designed by one mind, or agreeing resonant minds.
I feel the same applies to today’s modern cloud architecture, even when working with disparate systems. Conceptual integrity of your cloud architecture estate, will be a key enabler for your cloud migration programme to run smoothly. But in such a large organisation, how do you achieve this at scale, when you have many contributing architects, each with their own experiences, preferences, and ideas? I’ll share below the refinements I’ve made to Vodafone’s process of making architectural decisions as an agreeing resonant committee.
- Where did it start? How did it evolve over time?
- What’s the natural flow of things?
- Is there any fat we can cut from the process?
- How can we allow the best ideas to win?
Where did it start?
Long before my time at Vodafone, the advent of big data and private cloud allowed anyone with access, the ability to deploy resources without requesting hardware well in advance. With the ability for a wide range of developers and architects to deploy whatever they wanted, a sprawl began.
Someone wanted to bring all this together, and decided to create a Design Authority forum. Somewhere we could bring many years of expertise together, to get the best results out of our cloud usage, by considering all angles. This started as a natural meeting of like minded people, discussing innovative new ideas.
As time passed, this produced good outcomes, and gathered more steam and attendees. We set a regular time to meet. As more was learned from mistakes, slowly small organic changes were added over time, starting with an advance agenda. To learn from a project where we sank a lot of time which ultimately did not have funding, we added someone from finance. To learn from a project which ultimately would not get privacy’s blessing, we added a regular required attendee from privacy. Ad infinitum, many years later we have a somewhat heavyweight process.
What are the problems with this? In essence, with hundreds of developers and architects submitting new proposals, from such a wide range of business functions, we’ve ended up with a process which is complex to navigate, and users are less likely to engage with. We’ve got users tweaking their designs after approvals, lots of submissions without the right data being captured, and 3 staff members administering the process. We’ve got no way to do any kind of effective analysis over the data we’re capturing in confluence, so is there any point in capturing it? There are definitely improvements to be made, but where to start? An evaluation of what we’ve got today.
What’s the natural flow of things?
- Developers copy and paste a template page on confluence, and fill in their details. It’s not truly a submission form, it’s a structured editable page — we’re hoping they’ll fill everything in correctly, implicitly trusting people we may not know.
- They attach a link to another confluence page. This can be changed at any time.
- We have staff to administer changes to submission pages.
- The same staff make an agenda for the next meeting.
- We have a large meeting, often 100+ attendees, to present the latest ideas and changes.
- Changes are voted on for unanimous approval — anything other than approval comes back again.
Is there any fat that we can cut from the process?
The process of creating the submission is tedious in confluence, can we shorten this? We decided to go with Microsoft Lists, for a few reasons:
We can have a nice interface to browse, sort, and filter existing content, all built right within teams. If we’re spending all day in MS Teams anyway through messages and calls, better to have our most important content in the same channel as our conversation:
We can have a validated form for submission, with little to no effort after creating our list, allowing end users to submit requests with the right data:
We can use the content for meaningful analysis, as all of the data is easily available in PowerBI:
We can begin to automate some of the administration tasks, using reminders when tasks are soon to reach a given date field, or rules to trigger when certain changes are made:
We can also being to automate some of our admin tasks, like creating the agenda, changing statuses if no action has been taken for more than a month, etc.
Lastly, we have a simple onboarding process: read the wiki. It should bring any new joiners up to speed as soon as possible, and also gets stored in the same place, right in the teams channel:
How can we allow the best ideas to win?
Recently, we’ve had discussions about the approval process — is it too heavyweight? How do we weigh opinions? Are there any inputs we simply can’t ignore?
Again, this needs some thoughtful reflection on what we do today, before we can make changes.
We can’t ignore privacy or security input — they’re essential functions who don’t much care about our architecture, but care about keeping our customer’s data safe.
So we can put these controls in place first of all — but how do we then act as agreeing resonant minds? Ray Dalio has an excellent TED talk about how to build a company where the best ideas win, which I often reflect on. I reflected on what usually happens at the Design Authority meetings.
Submissions are, in theory, agreed unanimously. But there are certain attendees in positions of seniority and authority, who seem to practically have veto rights on something they don’t like. But if one less experienced person objects, this has often been ignored. This makes some flawed assumptions about attendees based on experience. And although every vote is equal, some votes are more equal than others.
Let’s be honest — there’s no getting away from this idea. It can’t truly be a democracy, (nor a weird form of communism), in a large, modern organisation. We couldn’t truly tell experienced architects at the end of their career, that they have the same weight as a newly minted engineer.
So why shy away from it? What if we had a quantified way of unequal but fair votes, where the most experienced people provide input, which is more heavily considered, but still allow junior staff to have an input which will be considered?
What if we could move away from unanimous approval, to a points-based system, where the number of points a given person gets, is reflective of their advancement on the technical career path? Where level 3 staff get one point, but level 7 staff get 10, for example? And submissions need to win 75% of available points?
This would abandon the pretence that everyone is equal, but also make it clear why they aren’t equal, how exactly unequal things are, how they’ll get more of a say. It would be transparent about how less experienced people in numbers, can overturn the objections of a more experienced person.
Conclusions?
We’ve organically evolved a process of approving cloud architectural changes, but stopping to reflect on this meta-process, has allowed us to be more efficient and organised about how we execute this. This makes our daily jobs easier, and allows us to have a lightweight process where we can govern any new architecture quickly and easily, with the combined centuries of experience at our disposal, to allow Vodafone to meet it’s strategic objectives.
Enjoyed this? You might also like these:
