Calm Down and See the Bigger Picture—It’s Just Architecture

I attended an EBC a few years ago at one of the big technology companies. After getting yelled at for an hour by a super-pumped guy, using his outside voice, about how the company works and its culture, we moved on to a much calmer session with a senior engineering leader.

We had just heard in the previous session that the company’s software teams famously work without any standards, which, of course, everyone in tech already knew. Rock on, brother.

Even “No Architecture” Organizations Still Depend on Architecture

But in the engineering session we learned that while the company’s software teams do work autonomously, it also has gating measures in place to systematically evaluate what those teams produce, mostly through platform automation.

We also learned that the company has a small team of distinguished engineers who are dispatched when a team needs help—which, in this environment, means a lot, because these people definitely work at scale.

It was a good example that even the loudest champions of “no architecture” still depend on it. They just approach it differently and call it something else.

Platform Constraints as Implicit Architecture Governance

While that approach might sound great in theory, we’re not talking about the kind of “help” anyone actually wants. We’re talking about quality time with an on-the-metal caliber engineer in a let’s fix your shit setting—and possibly an exit interview if things don’t go well from there.

In that environment, everything’s fair game—languages, frameworks, even spaces instead of tabs (for the monsters who do that). But the mechanics of their development platforms, and the known optionality of distinguished engineers “helping,” are what provide architectural direction and keep most teams in line.

The teams that venture out usually know what they’re doing; they’re not rebelling, they’re changing things with confidence. Confidence, though, doesn’t exempt anyone from the basics, or, in this case, at-scale basics.

For example, if a team strays from the de facto standards for how services are instrumented, that’s fine. But their service still needs to produce the right logs, as expected in production. And if it can’t handle real-world production loads with telemetry-based autoscaling, well… “help” is on the way.

Architecture Requirements Are Not Optional

As we’ve covered architecture requirements—implemented through rules and measures—I’ve thrown around a bunch of assertive nonsense words: requirements, rules, specifications, measures, assessments, oversight, governance.

It can all sound a little heavy-handed.

But there’s a difference between being heavy-handed and being strict. In any organization, Enterprise Architecture should be collaborative and constructive—focused on the priorities that make the enterprise more effective. It’s an enabling function, not a policing one.

But once architecture requirements have been formalized, though—again, predominantly policy-based—they should be managed rigorously.

Or, if your requirements aren’t actually meant to be followed, maybe skip the rules and measures altogether and just write requirements as useless, puzzling haikus instead:

Architect’s Directive
All requests must trace.
Especially the one inside.
That asks who you are.

Enterprise Architecture is about coherence, not control. Architecture requirements help us set direction and make sure we remember what we’ve built, how to run it, and why.

Architecture Enables Consistency, Not Control

In the end, we’re doing this work to create consistency across our systems. Some things will be popular; others, not so much. Some will get done; others won’t. (We’ll talk about exceptions and reporting in a future article.)

The reason we want that consistency is simple: it gives us a better chance, at runtime, of making a computer do something that we actually want—reliably, securely, and potentially at a lower cost. It also makes our systems easier to manage, helps meet regulatory obligations, reduces tech debt, and improves efficiency. In other words, we’re trying to be more effective.

But what does it actually mean to be more effective, at least from a technology standpoint?

What Architectural Effectiveness Actually Means

First, there has to be a coordinated, rigorous effort to get things right at runtime. But “right” depends on the organization’s mission and priorities.

Calibrating Architecture to Organizational Context

A startup chasing a fleeting market opportunity plays a different game than an established business balancing innovation with established product lines, global businesses, and regulatory complexities.

Second, the organization’s technical capabilities matter. I’ve used architecture programs and requirements to enforce quality with outsourcing vendors and to reign fire when they missed their SLAs.

More rigor in requirements and measurement was essential to compensate for the average skill level we were working with. That’s obviously not the case in the tech company–example we began with.

Third, we want to remove as much foundational overhead as possible from the day-to-day work of software teams—so they can focus on products, features, and customer value.

Reducing Cognitive Load Through Standardization

For instance, if a developer doesn’t have to think about instrumentation—because it’s effectively solved or at least standardized—that person can focus on higher-value work. And since it’s solved and standardized, operations can count on it being dialed in.

Not everyone sees it this way, though. Plenty of people want this kind of enablement. A few—fewer, thankfully—see it as an encroachment on their agency or creativity.

When Autonomy Outruns Accountability

But I’ve also seen what happens when autonomy outruns accountability.

Misconfigurations become vulnerabilities. Vulnerabilities become exploits. Exploits become terrible business problems, which, occasionally, result in executives testifying before Congress.

We don’t want that.

Choosing the Right Level of Architectural Rigor

And lastly, this one’s a question:

What approach does your organization actually need? Whatever it is, align on it, go that route, and call it whatever is most resonant for the organization.

Policy Integration Is Where Architecture Becomes Real and Nonnegotiable

In Defining Enterprise Architecture: A Practical Approach, I outlined three things we need to do in Enterprise Architecture:

1. Translate Strategy into Technology Execution
2. Drive Architectural Alignment
3. Design Solutions

So far, this series has focused on the second: Drive Architectural Alignment. Most of that work, as we’ve discussed, involves translating policies and principles into concrete architecture requirements.

This work should be rigorous. Gray areas are fine—there will always be some—but our aim is clarity through specification.

We should collaborate and balance the needs of our stakeholders, yet be unapologetic about implementation and measurement. These are defined requirements, not suggestions written in a minimalistic form of poetry, by someone like me, who is clearly not qualified to do so.

This part of Enterprise Architecture is different from the other two. Policy integration may seem heavy-handed, but it’s situational—it has to be that way. The other two, not so much.

If you still want to deliberate on the merits of getting policy integration and architecture requirements right without being strict, go ahead. But I view this with similar regard to how Mr Burns replied when asked if his money has made him happy:

“Yes, but I’d trade it all for a little more.”²

Notes:
1. Featured Image AI generated using OpenAI’s ChatGPT (GPT-5) with help from Google Gemini Flash 2.5.
2. The Simpsons, “Mountain of Madness,” Season 8 Episode 12 (1997).