#022 - The Security Requirement That Accidentally Became a Delivery Blocker

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 platform lead opens a kickoff meeting with the line every architecture team thinks it wants to hear: "You have complete freedom to design this." For a few seconds the room feels good. Then the questions start -- optimize for cost or speed? Build or buy? One shared platform, or let every team pick its own stack? Nobody asked for permission to answer those questions. They asked for someone to actually decide them. That's the subject of this episode -- the second failure mode in a two-part series on architecture leadership. Part 1 covered leaders who prescribe a solution instead of stating a problem. This one covers the opposite mistake: leaders who pull back so far that "freedom" becomes unresolved governance, handed to the people least positioned to resolve it on their own. We name the pattern Architecture by Abdication -- a leader disengages from the hard trade-offs, then judges the result after the fact -- and its mirror image, Decree Architecture, where the leader picks the technology up front and expects architects to justify it afterward. The two look like opposites. They produce the same outcome: architects doing work that was never really theirs to do, without the authority that should have come with it. We also dig into why constraints don't suppress architectural creativity -- they define the space where it matters, and why a premature leadership mandate does more damage at enterprise scale than at the level of a single system. A solution architect optimizes one system; an enterprise architect has to check that system against every other one around it. The practical shift: leadership can't demand accountability from architects while refusing to participate in the trade-offs that make accountability possible. Direction and freedom aren't opposites here -- withholding both is the same failure, twice. --- 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.

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.