Featured
Enterprise Architecture (Management) Reloaded
Welcome, welcome one and all, to a little discourse on a topic near and dear to the hearts of those who worry about such things, and a complete mystery to everyone else at the company Christmas party — Enterprise Architecture Management, or EAM as we’ll call it, because even saying the whole thing is exhausting. Now, some of you out there might be thinking, “EAM? Sounds like something invented by management consultants on a particularly slow Tuesday.” And you wouldn’t be entirely wrong.
But before you switch off and go back to doomscrolling cat videos, hear me out. This isn’t your grandfather’s EAM. We’re not talking about dusty tomes and diagrams only understandable by Tibetan monks who moonlight as database administrators. We’re talking about EAM reloaded. Think of it less as a rigid framework and more as… well, let’s get to that.
Has EAM Gone Quiet?
Now, you might have noticed, things have been a bit… quiet on the EAM front recently. A while back, say ten years ago, EAM was the buzzword on everyone’s lips, especially in cahoots with our old friend Enterprise Architecture. Architects, those shadowy figures lurking in server rooms and drawing incomprehensible boxes on whiteboards, were suddenly the great thinkers, the oracles, trying to wrestle the entire company — business structure, information architecture, data architecture, the lot — into one, single, unified view.
They were aiming for the Holy Grail of corporate understanding, weren’t they? And, frankly, it all sounded a bit too good to be true. It’s like promising to knit fog.
Then, something happened. The wheels came off. Or perhaps the carriage simply outran the horses. Whatever metaphor you prefer, the EAM bandwagon seemed to slow down, a bit like a steam train hitting treacle. Walk into companies these days, mention “Enterprise Architecture”, and you might just get a weary sigh and a phrase like, “Oh, not that again.”
This rings a bell with my own experiences. Trying to discuss methodology and argue the finer points used to be like wading through custard uphill. Especially when you ran into the fundamentalists, the folks who acted as if they held the key to all corporate wisdom. For me, that’s always been a discussion stopper. Now, I walk into a company, gently enquire if they’ve given any thought to their enterprise architecture, and often the reaction is… a shudder. “Not another one,” they seem to say, with their eyes.
Hence the question: Does EAM have a bad reputation? Well, from some angles, it certainly looks that way. It feels quieter. But is it truly less important, a has-been, an old hat best left in the attic with the Christmas decorations?
Three Shades of Architecture
Now, I don’t see it that way at all. I don’t think EAM is fading into irrelevance. I actually see Enterprise Architecture as a vital topic for architects of all stripes, especially in larger corporations. But this whole “outside image” thing? That’s tricky. It all comes down to perspective. Especially when you’re an Enterprise Architect yourself, stuck somewhere in the middle. Developers often have, shall we say, interesting opinions about architects. And the business side? Oh, they have reservations too, of all kinds.
Unraveling that is the interesting part, wouldn’t you say?
Because what should Enterprise Architecture even achieve? What’s the actual aim? Rolf, our virtual random EA protagonist in this story, hinted at product orientation being the new direction, putting business value front and center. But was that not always the point? Wasn’t business benefit always the aim?
I’d take a slightly different tack to answering that. Before we dive into goals, let’s rewind a bit and look at why Enterprise Architects might have developed this, shall we say, questionable reputation. It’s all about expectations — self-image versus how others perceive you. I’ve encountered three distinct flavours of Enterprise Architect, if you will. Depending on which type you’re talking about, you might be either thoroughly disappointed, or nodding along in perfect agreement.
And before you ask — yes, I’ve helpfully categorized these for your amusement and potential dismay.
First, Category A: Old School. Now, no disrespect intended, but these are the Enterprise Architects focused on asset management. Think keeping tabs on every PC, server, router — the whole kit and caboodle in the environment. They often proudly sport their TOGAF certifications. Useful stuff, of course, I’m TOGAF certified myself — but this flavour puts governance and asset management above all else.
Then comes Category B: The Business Domain Expert. This archetype is deeply embedded in the business side. Think methodical, strategically-minded folks with a strong business focus. Some even argue that if you haven’t come up through the business ranks, you can’t truly be an Enterprise Architect. There’s… spirited debate, to put it mildly, between these categories. A Category B architect and a Category A? They might just disagree about the very definition of architecture, let alone who is doing it “right.”
Finally, Category C: The Technology Enabler. This, I’d argue, is the “modern” type. Again, no ranking here, just observation. This architect is at home with design thinking, a change agent, and a champion of technological innovation. They really take “Enterprise Gardening” seriously — preparing the ground for good things to grow. This type often wields influence not through formal authority, but through sheer presence and helpful leadership, not because they’re the manager.
These are, of course, archetypes, not rigid boxes. But they reflect the different viewpoints out there. And these types? They don’t always get along famously. This internal discord certainly plays into why EAM’s external reputation might be… patchy. Different expectations, different approaches — you can see how misunderstandings arise.
It becomes crucial, as an Enterprise Architect, to be very clear about what you offer. But we’ll get to solutions later, perhaps after we’ve dissected this beast a bit further.
Product Focus, Not Project Focus
Stepping back to Rolf’s point, about product orientation: I wouldn’t entirely disagree, but I might frame it slightly differently. Let’s consider history. In software development, there used to be this… tendency… towards “Big is Beautiful”. Which led to monolithic systems, or at least, tightly integrated systems, magnificent in their… incomprehensibility. You ended up with an internally facing monolith.
Then came the microservices revolution, a breath of fresh, slightly chaotic air. This brought product orientation to the fore, a focus on domain specialization. But, and here’s the rub, what sometimes got lost in the microservices world was the link back to the business. The domain focus became very technical, not necessarily aligned with business capabilities or core processes.
That’s where product thinking truly comes in. Thinking about groups of business capabilities supported by a system, ideally loosely coupled, independently evolving systems. Business priorities can then shift, innovate at different speeds, without the IT department throwing up their hands and shouting, “Wait! We can’t keep up!” This agility, this resilience, this evolutionary development — that’s what feels truly new. And EAM needs to adapt to this shift.
I broadly agree with that historical overview and the shift in thinking. IT in general is moving towards this domain-centric view, and EAM is no exception. Business scenarios will always drive Enterprise Architecture, shaping capabilities and requirements. But the old way? It wasn’t necessarily domain-centric. It was often project-centric, perhaps even… politically-motivated, depending on how you interpreted the discipline.
Which brings us nicely back to those three architect types I mentioned. We’re about to reveal the results of our little poll, aren’t we? Curious to see what our audience makes of all this architectural categorizing.
Poll Results — EAM’s Vital Signs
Speaking of polls, let’s take a peek at the audience’s perspective. How important is EAM perceived to be for digital projects and transformations? Let’s bring up those results…
Aha! Look at that — a rather positive picture! “Important” and “Very Important” dominate. Excellent. EAM supporters in the house, it seems.
Which is fascinating, given my earlier point about those… less enthusiastic encounters. It appears my personal experiences might not be the whole story. Maybe it really does depend on who you ask. And, crucially, how you ask.
And, following on from those architect roles, it’s now even more interesting to understand how our users see Enterprise Architects and their responsibilities. This could be illuminating.
Now, back to goals — what objectives should an Enterprise Architecture pursue? Rolf, you pointed to product orientation as the new focus — more business value. But hadn’t business value always been the aim? Or were we perhaps tangled up in methodological details, losing sight of the forest for the meticulously crafted architectural trees?
No, business value should always be the objective. But the approach to achieving it, that needs re-examination. The past, in architecture, was about controlling everything. You would lay out these grand designs, meticulously planned, aiming for efficiency through tight integration.
But reality… reality bites. Businesses don’t stand still. The ground shifts under your feet. And those monolithic systems, magnificent as they were on paper, turned into millstones when agility was required.
Microservices tried to break free, but sometimes veered too far into technical domains, missing the bigger business picture. The product-centric view is about reconnecting with that business value, but in a way that embraces change, not fights it. It’s about building systems that support business products, evolve with them, not dictate to them.
The Balancing Act
Now, I won’t go so far as to say that Category A and B architects are obsolete relics, dinosaurs wandering in a digital meteor shower. No. We actually need all three types to keep things running smoothly.
You do need those, let’s say, “administratively-inclined” Enterprise Architects (Category A) who excel at maintaining order and preventing architectural anarchy. They are crucial for governance, asset tracking — the necessary, if sometimes less glamorous, side of things. You also need the Business Domain Experts (Category B), those folks who speak the language of the business, understand the nuances of the business domains, and can engage in creative problem-solving with business stakeholders.
It’s the Technology Enablers (Category C) who bring a certain… je ne sais quoi. A forward-thinking perspective, a knack for spotting opportunities in new technologies, the design-thinking toolkit. They enable innovation, they don’t just document existing systems.
A healthy mix of all three? That’s the sweet spot, in my opinion. That’s probably what long-term success looks like. And that neatly ties into a pre-submitted question — is EAM an advocate for IT architecture?
Absolutely. That Category C type, the Technology Enabler — they are that advocate. They argue for new approaches, champion innovation, while keeping a watchful eye on the overall landscape. They are the architectural evangelists. This advocacy can go in multiple directions — technology, yes, but also business models, portfolio diversification.
It’s about developing new business perspectives, isn’t it? We’re talking MVPs, Lean Startup approaches, “best-of-breed.” And speaking of “best-of-breed”… the surest way to sabotage a Lean Startup approach is to immediately smother it in solid, unwavering Architecture. Perfection, as they say, is the enemy of “good enough to start.” You need people who understand that a new venture needs space to breathe, to experiment, but also guidance. Loose reins, not a complete free-for-all. Knowing how to transition a Lean MVP into a robust, production-ready system — that is the art.
Exactly. If you rush headlong into the Lean Startup mindset, you still need someone to keep an eye on the assets, to prevent total chaos, to ensure things can be actually run later on. You need balance. And yes, Enterprise Architects — the good ones, anyway — are moderators. Moderators between these different worlds, different priorities. Even moderators between architect types themselves.
Moderation is key, and it applies to all architect types, I think. It’s a core skill set these days. Agile thinking, data-driven decision making — essential attributes for any modern architect. It’s about fostering cross-pollination, constructive friction, all that jazz.
And fundamentally, architects, whatever their stripe — we’re service providers, right? We need to be clear about what we offer, why we exist, what our purpose is. This is even more crucial now, as agility, product-centricity, product cycles, all reshape the game. The question, “Why do we need you?”, becomes increasingly urgent.
EAM: Investment or Overhead?
Which brings us to a question some clients seem to always ask: “What’s in it for me? What does Enterprise Architecture actually deliver? If I build an EAM function, how many heads do I need? How big does a company need to be to justify this? What about smaller businesses — what do they do?”
Smaller companies, inevitably, need more generalist architects. Specialists aren’t a luxury small firms can usually afford. The bigger you get, the more specialization you can justify. But is it worth it at all? That’s the million-dollar question, isn’t it?
You need to ask yourself: what do I want to achieve? What problem are we solving? What value do we expect? We’ll get to concrete service offerings shortly, but the basic question is — why hire any architect at all? I see two main reasons.
First, and most importantly: Decision Support. The primary job of any architect, but especially an Enterprise Architect, is to create a basis for making decisions. Where confusion reigns, where there are countless interacting factors, constraints, risks — you need clarity. You need transparency. You need a fact-based foundation for decision making.
Get Mohammed Brückner’s stories in your inbox
Join Medium for free to get updates from this writer.
This isn’t limited to Enterprise Architecture. Software architects, solution architects — all architectural disciplines share this core function. But at the Enterprise level, the decisions are bigger, the stakes are higher. A single wrong decision can cost millions. An Enterprise Architect who prevents just one such mistake? They’ve likely paid for their entire career, salaries, bonuses, the works.
The ROI, therefore, hinges on the scale of decisions and the potential impact of mistakes. For companies facing major transformations — digitalizing business models, for example — seriously consider the cost of not having strategic architectural guidance. Do the math. Look at the data. It will probably make a compelling case.
But does that always mean a full-time, dedicated Enterprise Architect? Not necessarily. It could be a part-time role. Like project management — everyone’s a project manager to some degree. A dedicated expert, though, brings… focus, discipline, specific skills. Whether part-time or full-time, depends on context, background. No one-size-fits-all answer. It depends, as they say… except, we aren’t supposed to say that word, are we? Let’s say: the answer is situational.
And, circling back to those three architect types — when you’re a lone Enterprise Architect, wearing all three hats, business, technology, and governance — it’s… challenging. It’s like being a one-person band trying to play a symphony.
Can you really fulfill all three roles effectively? Or should you delegate, perhaps bring in part-time specialists? It is hard to reconcile those different approaches within a single person. The asset-focused, governance-minded type versus the experimental, technology-enabling innovator. Different mental gears entirely.
However, it’s not impossible. You can contain the experimental, innovative stuff within “sandboxes.” Limit the risk. Keep things… bounded. But it’s a constant balancing act.
Speaking more broadly, though, the modern Enterprise Architecture approach is about cultivating architectural thinking across the organization. Spreading the architectural gospel. Agile, autonomous teams are the norm now. Micro-management from a central architectural authority? Counterproductive.
Better to instill core architectural principles, disseminate best practices, create a shared understanding. That’s far more efficient than top-down dictates. Architectural reviews, for example, become more about knowledge sharing and guidance, less about gatekeeping. Empower teams to make sound architectural decisions themselves, informed by these principles, not dictated by them.
This Enterprise Gardening, we talked about? That’s about self-sufficiency, isn’t it? A somewhat idealistic goal, perhaps. You’ll never reach perfect architectural self-organization. But it’s a direction of travel. A desirable direction.
Moderator, Evangelist, Gardener
Of course, even in a garden of architecturally enlightened teams, you still need those critical discussions. Those moments of creative friction between different perspectives. Innovation isn’t born from everyone agreeing all the time.
When everyone’s on the same page, architecturally speaking, where does the new come from? Innovation thrives on questioning, challenging assumptions. You need a space for those debates. And that’s where EAM steps in again — not as a controller, but as a facilitator of dialogue.
How do you encourage innovation? Not by stifling it with rigid rules. You nurture it, create fertile ground. Enterprise Gardening isn’t just a metaphor, it’s a philosophy. How do you make innovation systemic? Not dependent on a handful of mavericks. It should be part of the organizational DNA.
That’s where EAM, especially the Technology Enabler type, can truly shine. Streamlining innovation processes, setting up sandboxes for experimentation, fostering a culture of constructive challenge.
And does this shift — from governance and control towards enabling and gardening — alter the Enterprise Architect’s role? Yes, dramatically. Governance, quality assurance, control, efficiency — these still matter, of course, but they become background tasks, woven into the fabric.
The foreground becomes gardening. Making yourself, in a sense, redundant. Your success is measured not by control, but by how well architectural thinking is adopted, owned, and lived across the organization. The goal isn’t to be indispensable, but to make architectural competence distributed.
I think that direction is becoming clearer. And it aligns with the wider trend towards organizational agility and decentralization. Companies are striving to be less reliant on centralized bottlenecks, architectural or otherwise.
Which raises the question — how do you practically achieve this shift? How do you empower EAM, make it a success story, not just a theoretical exercise? If you’re too theoretical, you lose people. They see EAM as an ivory tower exercise, not something that adds concrete value.
So, how do you make EAM real? Tangible? Valuable?
Customer Journeys and Concrete Thinking
The problem often with architects is… abstraction. We’re used to thinking abstractly. Conceptual frameworks, architectural patterns, capability maps. Why? Because we’re aiming for flexibility, scope, avoiding premature commitment to specific products. Higher-level thinking. Logical, from an architectural perspective.
But… abstract thinking isn’t universally understood. For many people outside architecture, it’s… baffling. There’s a saying in Dutch, “Concreter is beter,” — “More concrete is better.” It’s wonderfully direct, isn’t it? If you want to communicate a message about technology, architecture, innovation, make it concrete.
And what’s more concrete than the customer journey? Putting yourself in the customer’s shoes. Walking through their experience. Marketing, sales, customer service, product development — map out those journeys, from their perspective. What are their pain points? Their desired outcomes? Then, frame your architectural thinking around those concrete scenarios.
Use customer journeys to explain architectural decisions, highlight the impact of different options. It makes things instantly clearer, more relatable. Less abstract jargon, more real-world impact. It’s a very business-oriented approach, because customer journeys are a business tool, a way of understanding the business from the customer’s viewpoint.
Absolutely. Customer journeys serve multiple purposes. They’re business-aligned, customer-centric, and concrete. Perfect for the agile, product-focused organization we’re aiming for. Why not build EAM legitimacy around something so undeniably valuable and understandable?
Speaking of understandable tools — what about TOGAF and customer journeys? Are they… friends? Acquaintances? Strangers on a train who exchange a polite nod and never speak again? I don’t immediately recall “customer journey mapping” in TOGAF itself. Or am I missing something obvious in those 600 pages?
Well, you’re not exactly wrong. It’s… not explicitly a core element. But, to be fair to TOGAF, it’s designed to be a framework, not a prescriptive methodology. TOGAF, to its credit, does have extensions. There’s the TOGAF Library Body of Knowledge, for example. That delves a bit more into these areas, goes beyond the core framework.
And let’s be honest, no framework is all-encompassing. Should TOGAF encompass Lean Management principles? Customer journey mapping? Agile development practices? Where do you draw the line? Frameworks define a scope, offer best practices, but they aren’t meant to be encyclopedias of everything.
So, you supplement. Adapt. Tailor frameworks to your reality. Treat TOGAF, or any framework, as a starting point, a toolbox, not a rigid instruction manual carved in stone by monks on a mountaintop.
And now, a question from the audience regarding regulatory demands. How does an Enterprise Architect navigate regulatory requirements, those pesky constraints that seem to box you into a corner, stifle creativity, force you into a compliance-focused straitjacket?
Regulatory compliance is… inevitable. Think GDPR. Those requirements will become dominant drivers, and for good reason. Customer trust, business continuity — these depend on taking compliance seriously. It’s not always glamorous, it might not ignite your creative fire, but it’s essential.
Think of it as… necessary gardening. Weeds must be pulled. Regulations must be met. But the method matters. If you treat compliance as an afterthought, tacked on at the end, it becomes painful, stifling, and expensive. If you build it in from the start, it becomes part of the architecture, less of a constraint, more of a… design parameter.
Greenfield projects are opportunities here. You can bake in data protection, security — right from the architecture. Legacy systems, retrofitting compliance? Much harder. But even then, aim for architectural solutions. Loosely coupled components, context-aware systems, designed to mitigate risks at a fundamental level.
In my consulting work, modernization is often driven by flexibility, domain boundaries, componentization. “How can we assemble our IT systems from reusable building blocks?” Compliance becomes one more design consideration, not an afterthought.
And, speaking of evolving skills, the Enterprise Architect of today needs to be… technically savvy. Not just a conceptual thinker in an ivory tower. You need to understand the technical implications of your architectural decisions. How business capabilities translate into domains, how those domains translate into… actual code, infrastructure, cloud deployments.
That technical fluency is increasingly critical. Especially in agile, domain-driven environments. The gap between business strategy and technical execution is narrowing. Enterprise Architects need to bridge that gap, not widen it. Learning agility is paramount. Be prepared to constantly learn, adapt, embrace new technologies, even those outside your comfort zone. Cloud, machine learning, change management, coaching — these are not optional extras anymore. They are core competencies.
The focus shifts. Less about robust efficiency, more about robust dynamism. How do you build systems that are both secure and adaptable? Where regulatory compliance demands rigidity, how do you build pockets of dynamism and agility?
The answer, again, often points to modularity. Microservices, component-based architectures, building blocks. Flexibility, resilience, evolvability. And change management. Bringing people along on this journey. Enterprise Gardening — cultivating a culture of architectural awareness.
Because, ultimately, EAM is about people. Not just processes, not just diagrams, not just frameworks. It’s about enabling people, empowering teams, fostering a shared understanding of the architectural landscape.
Monday Morning — EAM To-Do List
We’re nearing the end of our time together, and I know you promised some… action points, some practical advice for our Enterprise Architects heading into the week. Let’s say it’s Monday morning. What should an Enterprise Architect actually do?
Well, it depends, of course, on context. But some general, broadly applicable principles come to mind. And I’ve even made a little list, for your Monday morning consideration.
First, Embrace Feedback. Actively seek it, at all levels. Top-down, bottom-up, sideways. Feedback from bosses, of course — always helpful. But just as crucial, if not more so, is feedback from those who use your architectural frameworks, those who implement your principles. Developers, business users, anyone impacted by your work. How are those architectural principles actually working in practice? What’s helping? What’s hindering?
Feedback isn’t just a nicety; it’s essential for course correction. For continuous improvement, for self-reflection. Too often, we seek feedback upwards, forget to listen downwards and outwards. Feedback is how you calibrate, how you adapt.
Second, Cultivate Lifelong Learning. Learning isn’t optional. Especially in technology, and especially in architecture. The landscape shifts constantly. New technologies, new methodologies, new challenges. Don’t be afraid to dive into new areas, even areas outside your perceived “core” expertise. Change management, coaching, design thinking, even philosophy — these are all relevant.
The goal isn’t to become an expert in everything. That’s impossible, and frankly, absurd. The goal is mental agility. The ability to learn rapidly, to adapt to new information, to integrate diverse perspectives. That’s the architect’s superpower.
And finally, a slightly cheeky, perhaps less serious, but hopefully insightful point: Engage in intellectual meandering. Learn something completely unrelated to your daily work. Read about history, physics, philosophy, even… Terry Pratchett novels. It broadens your horizons, sparks unexpected connections, and just might give you a fresh perspective on those rather complex enterprise architectures. You never know where inspiration might strike. Sometimes, the best architectural insights come from… unexpected places.
So, that’s my Monday morning EAM prescription. Seek feedback, embrace learning, and… read a good book that has absolutely nothing to do with IT.
And speaking of learning, and of further exploration, for those keen to delve deeper into all things Enterprise Architecture, and perhaps discover things tangentially related like, say, Discworldian wisdom…
Find more great ideas on navigating the digital age at https://platformeconomies.com — and maybe, just maybe, consider grabbing my book on everything IT Architecture while you are at it: https://a.co/d/j7Fc6rN
“Do you not know that a man is not dead while his name is still spoken?” Perhaps Enterprise Architecture Management will find immortality not in rigid frameworks, but in the gardens of well-tended digital ecosystems, its name whispered on the wind of agile transformations. A fitting end, wouldn’t you agree?
