The head of a company recently asked me about the quality of their software architecture. He didn’t have a technical background, and was concerned that his technology team was producing something that was appropriate, and wouldn’t lead them into dead ends. He didn’t have any reason to consider that the architecture wasn’t appropriate, but nor was he confident that it was.
I didn’t get to explore the architecture itself, and that wasn’t the point. Our purpose was just to help him move forward and have some more conversations with increased confidence. So I could only talk in general terms.
The first thing I said was that I’ve never worked with an organisation that had a really great architecture implemented perfectly. I have worked at places which have good architectures (as theoretical plans, or a design), but I’ve never seen those plans implemented perfectly. There are always real-world pressures which compromise the vision of the engineers, which means there are always gnarly little corners and situations that cause problems. But in the grand scheme of things that’s okay. After all, no organisation works in a vacuum, and the organistion has a purpose which typically focuses on customers and profitability rather than the creation of technology for its own sake.
When I have seen well-considered architectures implemented really well they are typically only one part of the organisation’s entire system. So my first piece of guidance was: don’t expect perfection.
But what should we look for in terms of our aspirations? What are the qualities of a good architecture (or design), regardless of how successfully we’ve implemented it? For me, there are two perspectives to consider.
One perspective is the outside view. How well does it enable operations from an external perspective. Is the reliability for users good? How well does it enable the appropriate level of security? Does it scale well, or are there pinch-points when things get busy? If it needs to enable integration, what is that experience like for your users?
The other perspective is the inside view. How well does it enable expansion as the organisation (and its functions) expand? How maintainable is it, either in terms of people’s skills or the tooling available today? Can we monitor it reliably? How well can we trace problems? How easy is it to extend? How brittle is it?
The specifics will always vary, but it seemed like a useful conversation. I don’t think the head of the company should know (many) technical details of the system his team is building, but decisions made in the technology area often have both social and operational consequences. So bringing the architecture discussion up a level should be valuable to everyone.
niksilver.com 
It’s often worth considering architectural fitness functions here: https://www.thoughtworks.com/radar/techniques/architectural-fitness-function
Thanks, that’s a good tip. And the ThoughtWorks radar is always a good read, too.
I find that the architecture as a shared understanding of how the systems work is primarily useful for being able to reason about the changes you want to think about making. If a company doesn’t have a shared view, or has an incorrect vision of the real implemented architecture, this makes change very risky and hard. It doesn’t have to be precise, it doesn’t have to be complete, but it does need to be accurate and representative enough. Maybe his question was, “can we make reasoned decisions that are valid?”
John, that’s really helpful view, and subtly different from what I was thinking. Your perspective is that the architecture is shared, where as my perspective was (if not clearly stated) that of a technical artifact that was explained to others. Your outlook is of greater equality, and I like that very much.
Once that is done, I think the next question would indeed be “can we make reasoned decisions that are valid?” Again, this says “can we make…” rather than “can I verify….”. Thank you.