Influencing the Enterprise

A Field Guide for Enterprise-, Domain- and Solution Architects

"The model can be flawless. The room still has to agree."

Even in the new era of AI, Enterprise-, Domain- and Solution Architects are expected to influence some of the most consequential decisions in an organization — while often owning neither the budget, the teams nor the final decision.

Influencing the Enterprise explores the part of architecture that frameworks rarely teach: people.

The lighthouse mark, in charcoal, teal and gold

Why a lighthouse?

The lighthouse represents a steady light on changing waters.

It holds its ground through every tide.

It stays lit from the same fixed point on the shore, through fog, storm and calm, so that whoever is out on the water can see the coastline, the rocks, and their own position a little more clearly.

That's what architecture can offer an organization: making risks visible before they're hit, giving people a fixed point of reference when everything else is moving, connecting others who are each looking at a different stretch of the horizon.

Influence, like light, can travel a long way without ever touching the ship.

The Field Guide

Fifty stories, told across four themes.

A one-year writing project, one story at a time — and more relevant now that AI can do more of the analysis for us. Here are the four threads running through it.

The First Story · Self

The King's Mapmaker

Every story opens as fiction before it gets analytical. This one's about a mapmaker who kept improving his maps long after the map had stopped being the problem — a mistake most architects will recognize a little too well.

Coming soon

More ways to follow along.

A podcast, and a place to get each new story the moment it's published.

The Podcast

Influencing the Enterprise

Conversations about what happens when the architecture is clear — but the organization is complicated.

The Newsletter

On Substack

Each new story, sent out as soon as it's written — plus the occasional note that doesn't make it into the Field Guide.

The Field Guide

Fifty stories, told across four themes.

Here's the question I keep sitting with: when AI can increasingly do the analysis, the modelling, the documentation — the parts of the job that used to take an architect the longest — what's actually left that's uniquely ours?

My answer, and the working thesis behind this whole project, is the ability to influence how the enterprise makes decisions. Not the model. The decision.

Which means the psychology, the politics, the messy human research behind these stories was never really a side interest attached to architecture. I think it's becoming central to the job — more so now that the analysis itself is getting cheap.

So I'm treating the next twelve months as a one-year challenge: fifty stories, written and gathered along the way, each one looking at architecture from the ground most frameworks skip over — the human side of getting something built. Some I'll write myself. Others I hope to shape together with architects who've lived through the moments they describe.

They won't arrive in order. A story about a hallway conversation might sit right next to one about a boardroom standoff, and which number it happens to be will matter far less than which of four themes it belongs to:

Each story starts the same way: the fiction first, then two questions — what's really happening beneath it, and what an architect could do differently. No new framework here, and no universal answers. Just a year spent paying attention to something I think matters more now than it used to: the space between having the right insight and actually creating impact with it.

Self · How do I show up?

The King's Mapmaker

The first story from a year-long field guide · Written by Ioana Bour

A Story from the Field Guide

The King's Mapmaker

Once upon a time, in a kingdom obsessed with expansion, there lived a mapmaker named Elias. Elias had mapped every river, mountain and marsh in the realm. His maps were so accurate that generals carried them into battle and merchants framed them in their offices.

One spring, the King announced that his army would march east to conquer a neighboring valley. Elias studied the route and went pale. Between the army and the valley lay the Black Marsh, a place where horses sank, wagons vanished and even mosquitoes were rumored to have military training.

Elias rushed to the General.

"You cannot take this route."

The General examined the map.

"Very impressive."

"So you'll change the route?"

"No. The King wants us there by Tuesday."

Elias returned the next morning with a larger map. He colored the marsh bright red and added skulls.

The General thanked him for improving the visualization.

The army marched.

Three days later, half the supply wagons were stuck in mud.

Elias was furious. He produced a forty-page document entitled Principles for Responsible Eastward Movement and scheduled a Cartography Review Board.

The General did not attend.

Finally, the court jester found Elias drawing an even more detailed swamp.

"My friend," said the jester, "your maps are magnificent. But have you considered that your problem may no longer be cartography?"

For the first time, Elias stopped drawing.

He went to find out why Tuesday mattered so much to the King.

What's really happening?

Notice what Elias does the moment nobody listens: he doesn't ask why, he just does more of what he's already good at — a bigger map, a brighter red, eventually a forty-page standard nobody asked for and a review board that meets without the General anywhere in the room. It's an easy trap, and most of us have fallen into some version of it. The architecture gets ignored, so we answer with more architecture. It feels like rigor at the time. Most of the time it's really just avoidance.

Here's the part of the job nobody puts in the posting: Enterprise, Domain and Solution Architects are routinely asked to shape decisions they don't own — not the budget, not the delivery team, often not even the applications the decision is actually about. Elias assumes a better map will change the General's mind, because that's what's always worked before. But the General was never arguing about the marsh. He was standing inside a decision Elias couldn't see the shape of — a King, a deadline, maybe a promise made to someone else entirely.

Why Tuesday?

Maybe the King made a promise he can't walk back. Maybe supplies run out on Wednesday. Maybe there's a rival army closer than anyone's said out loud. Elias doesn't know yet — and that's the point. Before you can influence a decision, you have to understand the system making it, not just the merits of your own recommendation.

There's a useful distinction here from social psychology: some power is positional, the kind that comes with a title and lets you reward, punish or simply instruct. Some is personal — your expertise, the information you hold, the trust you've built over time. Most architects start the job with almost none of the first kind. Elias keeps acting as if he has it anyway, expecting the map itself to compel action the way an order would. What he actually has, and barely uses, is real information the General doesn't.

What could an architect do differently?

Stop acting like you have authority you don't have, and start building the kind of influence you actually can earn. That doesn't mean the architecture stops mattering — the map still has to be right. It means accuracy alone was never going to carry the day. What moves a decision is understanding who's making it, what they're actually optimizing for, and what constraint they're under that you simply can't see from your seat.

Elias's real mistake wasn't the marsh. It was spending three rounds improving a document when one honest conversation would have gotten him further.

A place to start: pick one recommendation of yours that's stuck. Before you touch the diagram again, find whoever's closest to the decision and ask them straight: "What would need to be true for you to be comfortable with this?" Then actually listen to the answer — there's usually a constraint in there you didn't know about.

Reflection

Think of an architectural decision you are currently struggling to influence.

Am I still drawing a better map? Or do I understand why Tuesday matters?

← Back to the Field Guide Next story — coming soon

Coming soon

Influencing the Enterprise — The Podcast

Conversations about what happens when the architecture is clear — but the organization is complicated.

"Tell me about a time you knew what the right architectural decision was, but couldn't get the organization to make it."

About

Not a framework. Not a guru. A field guide.

Architecture frameworks teach us a great deal about how to describe an enterprise. They teach us considerably less about what happens when people disagree.

Influencing the Enterprise is about the part of the job that never quite makes it onto a diagram: authority, trust, stakeholder psychology, storytelling, negotiation, politics, knowing when to push and when to fold. The stuff that quietly decides whether the good architecture actually happens.

This isn't trying to give you a new way to structure the work, and it won't hand you universal answers — anyone promising those hasn't done the job. What it is: fifty stories, written over a year, checked against real research and tested against how decisions actually get made — not the tidy version from the slide deck.

Every story follows roughly the same shape: the fiction first, then what's actually going on underneath it, then what an architect could do differently. The stories are made up. What they're pointing at, unfortunately, is not.

There's a podcast coming too, eventually — conversations with architects, executives and the other people in the room when these decisions actually get made.

"The goal isn't to become the most powerful person in the room. It's to help the room make a better decision."

About the author

Ioana Bour

I'm Ioana Bour, an Enterprise Architecture leader, architect and coach based in the Netherlands.

I've spent much of my career working at the intersection of business and technology — first as a technical & management consultant and later in Business & Enterprise Architecture. Today I lead a team of Enterprise Architects in a large financial organization, working on questions that cut across organizational boundaries: future-state architecture, business processes, simplification, governance, operating models and the changing role of architecture in increasingly autonomous organizations.

Over the years, I became increasingly interested in something architecture frameworks don't teach particularly well: what happens after you've worked out what the architecture should be?

Architects rarely own all the teams, budgets or decisions required to make that architecture happen. We work through other people. We need to understand their priorities, challenge their assumptions, bring different perspectives together and sometimes convince people considerably more senior than ourselves. And occasionally, after doing all of that, we need to accept that the organization has chosen a different path.

My work as a trained coach made me even more curious about this side of our profession. Architecture taught me to look at systems, dependencies and structures, but coaching taught me to pay closer attention to the people inside those systems — how we listen, what we don't say, what makes us defensive, how trust develops, and why asking the right question can sometimes achieve more than presenting the right answer.

Influencing the Enterprise grew out of the intersection of those two worlds.

There's also a more current reason this feels urgent to me. I lead a team of architects inside a large financial organization, and I'm already watching AI take over more of the analysis, the modelling, the documentation — the work that used to fill most of an architect's week. It hasn't made the job smaller. If anything, it's made the part nobody's automated yet — getting an organization to actually act on good architecture — the part that matters most.

This is not a new architecture framework, and I certainly do not claim to have all the answers. Let us make it a place to explore the situations that Enterprise, Domain and Solution Architects encounter every day but that rarely appear on architecture diagrams: authority and influence, trust, stakeholder psychology, storytelling and so on.

Newsletter — coming soon

I'll be sending each new story out on Substack as soon as it's written. The link will live here once it's up.

Influencing the Enterprise

The lighthouse represents a steady light on changing waters.

Fifty stories, told across four themes.

The King's Mapmaker

More ways to follow along.

Influencing the Enterprise

On Substack

Fifty stories, told across four themes.

The King's Mapmaker

The King's Mapmaker

What's really happening?

What could an architect do differently?

Influencing the Enterprise — The Podcast

Not a framework. Not a guru. A field guide.

Ioana Bour

Trust & Authority

Collaboration & People

Insight & Direction