#019 - Decree Architecture vs. Abdication: How Leaders Break Architecture

Two organizations can both say "we have process" and mean completely different things. One team watches a tested, urgent fix sit in a queue behind a board that meets every other Tuesday -- nobody on it built the system, nobody carries the pager. Another team ships to production the same afternoon, governed by an availability budget and an automated canary release instead of a meeting. Same word. Opposite outcome.

Architecture has more than one right answer -- if there were only one possible solution to a given problem, the creative part of the job would already be over. This episode closes out the Architecture Leadership: Direction or Freedom series with a simple way to hold that conversation together: Purpose, Problem, Parameters, Possibilities.

A design review starts with someone who already has the answer: "We need microservices." Or Kubernetes, or an event-driven architecture, or a new API platform. The room spends the next hour justifying a decision nobody actually discussed. This episode is about that moment, and the mistake underneath it. The mistake isn't giving architects too much direction, or too little. It's giving them direction at the wrong altitude -- a solution instead of a problem. Gregor Hohpe's "Architect Elevator" describes the levels a good architect has to move between; this episode argues leadership's job is to state the destination and the constraints, then get out of the machine room. We walk through why architecture is creative work, but creativity isn't the deliverable -- architects are paid for outcomes like reduced risk and faster delivery, not for diagrams. We use Hershey's 1999 ERP rollout as the real, named case for what happens when a leader fixes the technology and the calendar before anyone defines the actual problem: a Halloween season with empty shelves and a nine-figure loss, from a project that was never really about SAP. And we get into the reflex that causes it: "we need microservices" is a solution dressed up as a requirement. It skips the problem-definition conversation entirely, including the option that's usually invisible on that list -- doing nothing. The practical shift is simple to state and hard to practice: state the problem, the business motivation, and the constraints -- then stop, and leave the design to the people accountable for building it.

Most bad architects are easy to spot -- buzzwords, a checklist, an authority that was never earned. The good ones are the hard case: quiet, unremarkable, everything just seems to go well and nobody quite knows why. This episode is about that second group, and about the self-tests that actually separate them from the first. We start with the split at the center of the episode: the oracle, who hands down verdicts from a position nobody is allowed to question, versus the amplifier, who leaves everyone in the room able to solve the next problem themselves. Built around a conversation with Gregor Hohpe, a Google and AWS enterprise architect and author of "The Software Architect Elevator." We walk through the Rubber Duck Test -- a proposed self-check, not an industry standard -- for whether you're actually useful: do people come to you to think better, or because you're a checkpoint they have to clear. We get into why simple architectures are usually the hardest ones to build, why essential complexity can't be negotiated away, and why "too many cooks" produces something worse than any option on the table, not a fair compromise. We close on the line that ties the whole argument together: an architect's real pitch is "I lower your risk," not a stamp of approval on someone else's design. And the current wrinkle -- what that pitch is worth once anyone can paste a chatbot's output into an architecture document.

Most systems get a database before anyone has written down a requirement. In this episode we take that reflex apart and ask what the decision would look like if it were actually made rather than assumed. We start by separating the four kinds of state almost every system mixes together: reference, transactional, derived, and ephemeral. Only one of them clearly justifies a networked relational engine, and conflating them is what turns a modest application into an operational burden. From there we look at what a database really costs. Not the licence -- the operational surface: high availability, a restore you have actually verified, patch cadence, schema governance, and a fresh single point of failure carrying its own service level agreement (SLA). We then examine the strongest idea in the "no database" argument, which is not the absence of storage at all but materialization -- a slow, human-paced write path paired with a fully pre-computed read path -- and we are honest about where that simplicity breaks down. The dividing line that matters turns out to be concurrent writers to overlapping state. Not data volume. Not user count. We close with eight decision gates you can walk through in a design review, so that whatever you choose, you can defend it with a reason rather than a habit. Dmytro Golodiuk is a highly experienced technology professional with over 17 years in the software industry. His proficiency spans cloud computing, enterprise platforms, software development, and integration technologies, with deep expertise in the Microsoft ecosystem. Dmytro combines his technical knowledge with formal Enterprise Architecture frameworks like TOGAF and ArchiMate to deliver robust and practical solutions. In addition to his architectural work, Dmytro is a passionate mentor dedicated to helping others grow in their IT careers. https://mentor.sh/mentors/dmytro_golodiuk⁠⁠