Where’s the Beef: Proving your Architecture has value
If you’re not old enough to know the reference ‘Where’s the Beef’, then you’ll love this. If you are old enough to remember it, well then welcome to memory lane.
Back in the mid-80s, the burger chain Wendy’s put out this commercial that was an instant success across the US and Canada.
You can watch it here
Three old ladies are looking at a hamburger with a ridiculously oversized bun, and almost no patty whatsoever. One of them says what they’re all thinking and wants to know where the beef is in all that bun.
The term “Where’s the Beef?” came to be an all-purpose phrase questioning the substance of an idea, event or product. It was even used by then-democratic Senator Walter Mondale during his 1984 US presidential candidacy.
When it comes to building an architecture and floating your design to others, we have this tendency as devs and architects to focus on nitty-gritty technical details.
Don’t get me wrong. There’s nothing wrong with technical details.
The issue is that if ALL you focus on are the technical details, something gets lost which any good design needs: It needs to show others how it adds value. An architecture needs to make sense from all angles, not just the technical ones.
You can’t isolate an architecture from its purpose
Your architecture cannot focus on technological concerns in isolation from the overall purpose for which you intend to use it. Architectures are not just about resilient storage, or programmatic access, or communication protocols. Everyone who uses your architecture has needs. These can be direct needs, say from Phil the dev and Tyrone the engineer, or they can be indirect needs, say Maria the financial controller, or Jim the customer.
Each of these people will be affected by your design, so looking at the issue from a purely technical standpoint alone begs the question ‘Where’s the Beef?’ Sure, Phil and Tyrone are happy, but Maria and Jim are SOL. How are their needs being met? What’s in it for them? You’ve created a really nice bun for the technical types, but for the rest of your stakeholders, it’s little more than that.
You might not know Maria or have access to Jim, but someone in your organisation does, and that someone is going to need to understand how your design will make those people’s lives better. That someone is often a product owner or project manager, and they have a very justifiable reason for being skeptical of the Technology First architecture. The history of IT is awash in the tales of brilliant technology architectures which failed to meet the customer’s needs, or were just flat-out abstracted from reality.
You must take your time and zoom back from the technology, look at the whole landscape from a broader perspective, and at the very least, consider how your design will impact everyone, not just the technical side.
Justify your decisions and choices
I once got into a debate with a fellow architect over why he was choosing to use Entity Framework 3.0 in a new application we were building back in the day. I am a long-time user and thus long-time loather or “Enterprise” ORM technologies such as Entity Framework. These systems create a magical abstraction between a SQL database and programming language constructs so that everything looks like an object to developers, and leave DBAs in a world of awful ‘generated query’ hell. ORMs grow increasing difficult to use and maintain as your systems grow, and force everyone into a mapping prison which becomes impossible to escape. I was not keen on another such beast wrecking up a greenfield project.
“It’s the way things are done,” was his answer. As you can imagine, I didn’t let that particular sleeping dog lie. The debate was on.
An architecture is made up of a lot of little choices. Why use Lambdas vs. containers? Why choose Java over C#? Why use events vs web hooks? Every choice you make is some part of your architecture, and dollars to doughnuts, someone is going to question it.
Each such choice or decision should have, at the very lest, some justification of why you made it. Replacing this IoC container with another? Tell me why. Choosing to use a NoSql store vs a relational database? Explain to me what led you to this choice.
A good way of ensuring you get to these reasons in your choices is to collaborate with your teams and stakeholders along the way.
Make it presentable
Yes, you’re documenting and laying out a technology pattern, but that doesn’t mean it needs to look like one. As the old adage goes “Penmanship counts”: what your architectural documentation and diagrams look like matters. You might not think so, but your teammates and decision makers sure do.
You turn up with some UML action like this, and check me out in the back of the meeting room shaking my head.
That diagram version of techno-gobbledygook might excite your imagination, but most everyone else glosses over looking at that. This is technical implementation pretending to be architecture. Is there a place for this? Yes, down in the deeper details. It is, after all, a technical implementation, NOT an architecture.
Give people something they can latch on to. Start further back, give them high-level concepts, and then allow them the opportunity to drill in further. Use UX-approved colours, fonts, and themes, or ask someone in your UX team to help you out.
Present small concepts on any given portion of your architecture, and give more detail the further in you drill. There are whole waves of new note-taking or architecture diagramming platforms which make this kind of “drill down” possible, and far more effective at conveying your design (My personal favourite is Milanote, an amazing visual note-taking system which allows you to combine the best of diagramming with the best of documentation).
By organising your design documentation in a more consumable format for everyone, you are far more likely to get real feedback that helps instead of just blank stares and shrugs. People contribute to what they understand, not to manifestos full of bland diagrams.
I’m not trying to tell you what you’ve created technically isn’t awesome. It very well may be. However, if you and those three senior devs who sit by you are the only ones who get what you’re on about, then what good is what you’ve done?
As architects, we need to be the one stepping back and looking from a bird’s eye view. We need to make what we’re creating conceivable by everyone, and not simply by those who implement technology.
Hope this helps