Lighthouse mark for Influencing the Enterprise

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 also 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.

Latest Story · Self

The Keeper of Imperial Maps

A chief planner spends twenty years learning to answer his emperor's questions before they're asked. Then a new emperor asks a different one.

Beyond the Field Guide

More ways to follow along.

Get each new story by email, follow along on Instagram, or wait for the podcast — coming soon.

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

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

A Story from the Field Guide

The King's Mapmaker

Illustration of the mapmaker Elias drawing a map at his desk, from 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 The Bridge That Was Almost Built on Time →
Organization · How do decisions really happen?

The Bridge That Was Almost Built on Time

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

A Story from the Field Guide

The Bridge That Was Almost Built on Time

Illustration of the architect Apolodor presenting a bridge model to the King and his Lords, from The Bridge That Was Almost Built on Time

Once upon a time, a king ordered a construction of a new bridge towards a territory newly conquered. Since it was not an easy conquest, it was important that the best of the bridge builders had to be chosen and the bridge – to be a first of its kind. For such a bridge just any builder would not do. So the King's men travelled across seven seas and seven realms and found Apolodor, the most celebrated bridge architect there was.

The job was not easy. The bridge had to be majestic, bordered by two even more majestic gates upon which two marble statues of the King had to be placed. Apolodor made several plans and presented them in the King's council. The King was easy to convince – he easily picked the most majestic design.

The other Lords had several questions: the Lord of the Roads wanted to know how many horses and carriages the bridge could carry, the Lord of Troops asked how many soldiers can march over the bridge in safety, the Lord of Fish wanted to make sure that fishermen's boats would not be obstructed while the bridge was being built, the Lord of Subjects' Safety enquired about rails, wind, separate lanes and what would happen if a distressed horse would start running erratically up and down the bridge. All other Lords present (24 of them!) asked their questions. Apolodor wrote down every question, comment and promise. Then he returned to his team with many notes and a beginning of a headache.

But he also saw one empty chair at the Council and went to ask the Chancellor who is usually seated there.

"The Lord of Naval Forces"

"Oh, then I must speak to him! How do I find him?" enquired Apolodor.

"Don't worry", said the Chancellor waving a hand, "he's off salvaging what can still be salvaged after the war. We haven't seen him in a year"

"But the bridge does cross a river…"

"I wouldn't worry; he cannot be bothered with celebratory projects. I wouldn't stop any work for this, he is likely not to have any second to spare."

"Understood", replied Apolodor, thinking to himself "I anyway have enough work now and besides, 24 Lords are quite enough". Off he went turning the plans into almost reality.

Six months later all requirements were happily reconciled in the final design and – as customs required – he went again to the King's council to present a most detailed 1:1000 model of the bridge.

"Magnificent", said the King.

"Extraordinary", whispered one Lord.

"Spectacular", shouted another.

"Absolutely superb", added three others. Many did not say a word, for there was no word to describe the glory of what they were seeing.

"This cannot be built."

Silence. Apolodor turned trying to see who spoke.

It was the 25th Lord. The Lord of Naval Forces. He got up from his 25th chair and went to point at the model:

"The King's latest generation of warships will not be able to pass under this bridge. They are taller and wider than the old fleet. This bridge you are building is a wall to them and they will be trapped never to conquer other territories again."

The King was not smiling anymore.

Apolodor could not believe his ears. He enquired about the length and height of the new ships and went to measure the model. The Lord was right. After all this work. Everything (except the King's statues) had to be reconsidered – the positioning of the bridge, the exact location, the type of pillars and the width between them, the height of the bridge.

Apolodor packed away his model and returned to the drawing desk, no other time to spare now!

What's really happening?

Apolodor did many things right. He identified his stakeholders, he understood the non-negotiables (among which, the King's statues...), he treated everybody with respect and managed to accommodate their wishes with an exemplary design.

He also noticed that one of the Lords was missing and guessed it could be an important stakeholder, after all the bridge did go over a river. But he had to listen to the Chancellor. The bridge was definitely a Prio 1 on the Portfolio of celebratory projects and Lord 25 did not have time for celebratory projects.

One can judge that this is down to luck – it could have also been a Lord that truly did not care. And one can be right.

But what Apolodor did wrong is that he mistook interest for power or influence. Just because a stakeholder is not interested does not mean that they will automatically approve a design.

This is where it is important to get accustomed with the power-influence matrix used in mapping stakeholders.

  • High power & high interest = manage these stakeholders closely
  • High power & low interest = keep these stakeholders satisfied with information
  • Low power & high interest = keep these stakeholders informed
  • Low power & low interest = monitor to see if power or interest changes
Stakeholder matrix diagram showing four quadrants: manage closely, keep satisfied, keep informed, and monitor, illustrated with the King, Lords, and the Lord of Naval Forces from The Bridge That Was Almost Built on Time
Who is your 25th Lord?

This story was about a stakeholder with high power and low interest. He was not interested in the bridge, he was interested in whether the new naval fleet could pass underneath it. And once he realised it wouldn't, his interest also increased.

As important as it is to map these positions, it is equally vital to realise that they are not fixed:

  • someone not interested today may become very interested tomorrow, especially if the design affects their budget, their risk, people, autonomy
  • power is also less obvious than only an organisational chart; stakeholders can influence decisions also through expertise, relationships, control over resources

What could an architect do differently?

Drafting a stakeholder matrix is a good starting point. It is a nice step to be done with the entire design team – together you can uncover more nuances about your stakeholder field.

In my experience it is good to pay particular attention to two quadrants:

  • High power & low interest – these are precisely the stakeholders that will not volunteer their time to help you with your cause, but who have the power to block your deliverable if it goes against their own vision. It is important to keep informing them and check their thoughts. Ask open questions, wait for answers
  • Low power & high interest – these stakeholders will make time for your project or artefact. They are definitely interested in the topic – many times for their own learning or to apply their expertise – and add clear value in brainstorming sessions. The risk is to spend too much time with them to the detriment of the stakeholders with more power.

There is also a useful check to do just before approval: revisit your stakeholder map. Did anything change? Did you miss any high-power stakeholder? The organisation you have mapped in the beginning may no longer be the organisation standing behind the decision today.

Reflection

Think about an upcoming approval for a part of your recent work.

Who is sitting in the 25th chair? Who is sitting in the other 24?

← Back to the Field Guide The Druid's Daughter →
People · How do I work with people who see the world differently?

The Druid's Daughter

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

A Story from the Field Guide

The Druid's Daughter

Illustration of Masteria looking toward her village, from The Druid's Daughter

The year is 50 BC. Word has spread of a small Gaulish village, but not yet of another Gallo-Roman one, where the old druid Herbamatix now feels ready to pass his mistletoe knife to his daughter, Masteria.

Since childhood Masteria was a curious child, always interested in puzzles and always ready to lend a helping hand. Going together to see villagers in need, she would listen to her father's line of questioning and then try to diagnose herself.

"What do you think yourself, Masteria?"

The question always came. Masteria was delighted her father was asking her and her father was delighted to hear her answer. Many times her creativity brought breakthroughs and faster recovery times and Herbamatix himself was thrilled - so much talent in his own daughter.

It was now announced that Masteria is to be called for all matters and that she is equipped with all knowledge Herbamatix himself had. Villagers trusted her fully.

Five years passed and Masteria was putting all her effort into her job. She bought a Roman cart so that she could reach the villagers and the forest faster, she arranged her herbs in alphabetical order and standardised her remedies. She even started carrying clay tablets to scribble what needed to be done so that her advice could be followed to the (Latin) letter. Her pride was growing and so was her efficiency. In five years she had already surpassed her father in number of home visits per year and she also started working on a compendium of common ailments and home treatments - in the hope that people can help themselves too.

Masteria was delighted. Herbamatix less so.

"So how much time do you spend per patient now?"

"Much less!" said Masteria proudly

"Efficient", said Herbamatix with a nod to himself that doesn't usually belong with a congratulation.

The truth is that after five years Masteria has seen everything. Sometimes she could look through the doorway and already know what needed to be prescribed. She became more direct and she confidently told them what needed to be done. Soon there was no point anymore in asking questions. So she stopped asking them. Some villagers followed her advice to the letter, some didn't. And within this second category there was even a worse group, those who repeatedly made the same mistakes.

"No surprise you got a stomach upset after putting mud in your mouth! This is the third time; didn't we discuss this before?? Mud. Does. Not. Heal. Cavities!!!"

Soon villagers grew partly ashamed, partly afraid, partly offended and slowly-but-surely learned to do without Masteria's help. By the time Masteria was called, problems that were once simple became very complicated to treat.

One winter a contagious outbreak stemming from the Roman garrison could not be contained after the first family infected turned to relatives for help instead of calling Masteria. At some point, the entire village was sick. And what is worse, Masteria knew this could all have been avoided.

Feeling defeated, she went to see her father.

"Father, I have a problem."

"What happened, Masteria?" asked Herbamatix from the middle of his garden.

"People avoid me on purpose!"

Herbamatix waited.

"They call me only when everything else fails. They know I can help them. Why do they deliberately avoid the only person that can truly help them?"

"That is a good question. What do you think yourself, Masteria?"

How well she knew this question. She sighed.

"I suppose I was not very patient with them…"

Herbamatix did not say anything.

"But it is so difficult, I just want them to get better fast!"

"Must be very frustrating. What do you think they want themselves?"

Masteria's jaw opened. Then closed.

"Probably the same…"

"Interesting…" Herbamatix picked up his mistletoe knife again and turned back to his gardening.

"That's it? I came here for advice!"

Herbamatix smiled. Masteria stared at him, then started to laugh.

"I see what you are doing…"

Herbamatix continued his pruning. Masteria came and sat next to him.

"If I want people to understand, maybe I should give them a chance to understand my line of thought…

And perhaps I should ask them what they have already tried…

And maybe I should see them before something actually goes wrong…"

Herbamatix finally looked up at her:

"They all sound like great ideas."

Masteria smiled.

"Heh, it seems I came up with them all by myself."

"Must be the excellent education", smiled Herbamatix.

The next morning a farmer came to Masteria for help. She saw his swollen arm, she knew which herbs would work, she was ready to go get them, but she stopped. She grabbed two chairs.

"Tell me, what happened?"

What's really happening?

Masteria has become very good at her job. This is admirable in itself given that she had big shoes to fill. She became very efficient at it and was able to get to the core of the issue and treat more patients faster. The problem is that efficiency often has the awful side-effect of replacing curiosity.

Of course, her diagnoses are not wrong. In fact, she is right most of the time. The problem is what happens to the relationship when the expert already knows the answer before the stakeholder had the chance to explain it. The paradox is perhaps recognisable: the more certain someone becomes, the less likely they are to be involved if their confidence is read as inflexibility or as arrogance. Her expertise, though not less valuable, has become much more difficult to access.

From Masteria's perspective, she is saving people time (and people!). From the villagers' perspective, calling Masteria increasingly means that they are to be scolded. So they adapt, they go to other 'experts', much less suited to solve their problems. Sometimes these experts even come from outside the village itself! Sounds familiar?

Have you grabbed two chairs?

For an architect, grabbing two chairs can be surprisingly literal. Sitting next to someone before looking together at the diagram, asking what they have already tried, what worries them and what they are trying to achieve – before jumping to the solution. You may still end up recommending what you had in mind five minutes prior. But now they are ready to listen. And you are ready to change your recommendation to better fit their situation.

What could an architect do differently?

Expertise is partly about pattern recognition. What my team and I call 'connecting the dots'. An experienced architect will see things faster than someone encountering them for the first time. Of course, you should not pretend to know and turn all discussions into hour-long brainstorm sessions. But making sure you are attuned to the other is a must for a productive conversation.

In coaching 101, a first framework we learn to get a bit of confidence while asking open questions is GROW: Goal – Reality – Options – Way forward. It sounds like this:

  • Goal — What do you hope to accomplish? What does success look like?
  • Reality — What's actually happening? What have you already tried?
  • Options — What haven't you considered yet?
  • Way forward — What will you do differently, starting now?

You've already seen it in action. Herbamatix never tells Masteria what her problem is or what to do about it. "What happened, Masteria?" is Reality. "What do you think yourself?" and "What do you think they want themselves?" are Options, dressed up as simple curiosity. And the two chairs she grabs the next morning — nobody suggested those to her. That's her own Way forward, which is exactly why it sticks.

GROW framework diagram — Goal, Reality, Options, Way forward — illustrated with Masteria and Herbamatix at the table, from The Druid's Daughter

Last but not least, when an architect is brought in too late, it is worth asking if we are looking at more than only a governance or mandate question. Can it be that stakeholders actually don't feel like involving Architecture? Like Masteria, we should eventually ask ourselves, "What is it like to ask us for help?"

Reflection

Think of your last meeting with one of your stakeholders.

Have you created the space for the other person to tell you what is happening? How about what is really happening?

← Back to the Field Guide The Castle on the Border →
Impact · How does architecture create change and impact?

The Castle on the Border

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

A Story from the Field Guide

The Castle on the Border

Illustration of the architect Reginald studying his castle design while the King's ministers look on, from The Castle on the Border

Once upon a time a king ordered the construction of a new castle at their kingdom's newest border. The castle had to be strong enough to deter invaders, majestic enough to impress anyone approaching the kingdom, comfortable enough for the king and the queen to spend their summers there. The view over the sea was too beautiful to only waste on soldiers. Architects from across the kingdom and beyond were invited to submit their designs. Eventually one emerged as it truly was the most majestic and beautiful of them all. The winning design belonged to Reginald, an architect whose castles on paper looked almost as impressive as they eventually did on stone.

It was now time for our architect to come to the king's ministries and bring his design closer to reality. All ministers and Reginald met during the Crown's Council, where given its importance, the castle was the only agenda point of the day.

It was first the ministers' turn to ask their questions:

"Can it be built in time for the king's birthday next year?"

"Yes."

"Can the necessary marble and timber be sourced?"

"Yes."

"Will it accommodate for its double purpose, military defense and leisure?"

"Yes."

"Without compromising on each requirement?"

"Yes."

"Was it high enough to overlook the sea?"

"Yes."

The queen leaned forward:

"From the royal bedroom?"

Reginald is looking at the drawing:

"Yes, your Majesty"

Everyone was pleased.

Reginald closed the drawings.

"I have a few questions, too. Most important one, when do we start?"

Silence.

"I mean, has the Ministry of Roads planned the road required to transport the stone? And to build the permanent road afterwards?"

The Minister of Roads became unusually interested in his papers.

"Are the materials and workers ready to be given to me for supervision?"

The Minister of Built Environment honestly did not have the answer with him.

"How about after the construction is done, are we taking measures already to make the castle part of the Ministry's catalogue to plan for regular inspections and potential repairs?"

More silence.

"Which garrison will provide the soldiers?"

The Minister of War looked at the Minister of Something Else.

"We have not decided yet"

Reginald had now more questions than answers. He looked around the table, then again at his drawings. The castle was there. Majestic as he drew it. But the road was not. And there was also no construction camp and no indication of how the castle is to be run once ready. And yet without these, there would be no castle.

What's really happening?

The first round of questions is about whether the design satisfies the desired outcome. The second round of questions is whether the design actually works.

Reginald gradually discovers that nobody else in the Council has considered the changes around making the design work, both during construction and operation time. In architecture terms, both can be true: the target-architecture is literally beautiful and the organisation needed to implement it is nowhere near ready. A target state can be perfectly designed while the path towards it remains completely undesigned. Reginald noticed this, he himself had thought of all the questions, but not even a road was drawn on his design. The castle is the target architecture, the missing road is what has to become true for the target state to become real: the impact of change and its dependencies, the enabling conditions and the transition architectures.

Did you draw the road?

If not, how will stakeholders realise a road is actually needed for executing the vision?

What could an architect do differently?

Architecture should not stop at describing the desired future state. The lesson here is to not only architect the destination, but to also make the journey visible to all relevant stakeholders.

  • What does my design mean for the business?
  • What does it mean for the CIO?
  • What dependencies do I see?
  • Who needs to do what to accommodate for the new design?
  • (and more importantly) Have I made these dependencies visible, or are they only in my head?

Reginald obviously thought of all the questions while creating the design, but he did not make the impact or the change needed to get there part of the story.

It is important to also mention here that an architect does not need to personally recruit the workers and the soldiers or prepare for maintenance, he or she is not a program manager either. However, architecture must make visible that these elements are required in the first place. Coming back to Reginald, as building the castle was dependent on having a road ready, the road itself belonged in the conversation.

Reflection

Think of your last design or architecture.

Did you make the impact on the (delivering) organisational units visible? Did you draw the road?

← Back to the Field Guide The Owl Who Was Always Right →
Self · How do I show up?

The Owl Who Was Always Right

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

A Story from the Field Guide

The Owl Who Was Always Right

Illustration of Owl flying toward the council of animals gathered on a sandbank, from The Owl Who Was Always Right

Once upon a time, in a faraway forest all animals lived in complete harmony. Whenever something of importance had to be done or had to be built, the king of animals summoned his council: the Beaver (who knew everything there is to know about dams), the Fox (who knew everything there is to know about markets and commerce), the Bear (who knew everything about defence), the Deer (who knew every path, stream or meadow in the forest), the Rabbit (representing villages of rodents) and the Owl (who knew everything the others also knew).

Owl was not only the longest-serving in the council, but he possessed the talent of understanding what humans did and translating that to useful did-you-knows for the animal kingdom. For example, Owl knew how deep foundations for burrows needed to be laid in sandy soil, how much weight an oak tree could carry, he knew the average rainfall per month and he also knew how busy the forest would get in the different seasons. But most importantly, Owl also knew when someone was wrong.

One morning, the King called his council. A new bridge had to be built.

Beaver unrolled a drawing:

"Good thinking, your Majesty. I was waiting for this. The best place is this exact point. Here the river is narrow enough".

"Actually", said Owl, "the banks are clay in that area. The bridge will not hold".

"And it is far from civilisation!" weighed in Fox. "Let's add it next to the market".

"That road you're pointing at is not the main road to the market" answered Owl. "It would not help at all".

Deer suggested another location.

"Protected orchids", said Owl.

Bear wanted towers for soldiers.

"Not needed. We are in the middle of the forest here" was Owl's answer.

"Not even for making it look good?"

"That is inefficient."

By lunch time Owl won every argument, and the King thanked him for his wise contributions.

"What would I do without you", he said.

But the location of the bridge was nowhere near being chosen.

Over the following weeks, the Beaver brought new drawings, the Fox came with new ideas, the Rabbit even conducted a survey to see what the villagers would prefer. All in vain, the Owl shut down all ideas.

At one point, the Owl was seen marching triumphantly towards the Council meadow carrying seventeen tree barks filled with calculations. The entire meadow was empty.

"This is strange" thought Owl. "Everybody should be here, how are we going to build the bridge otherwise?"

After some time, he decided to fly and find the others. Eventually he heard voices coming from the sand bank in the middle of the river. Here they were.

Beaver was showing the others a drawing of his. Fox was nodding. Deer was calculating something in the sand. Bear was pointing something on the horizon to the Rabbit. The Owl landed among them.

"What are you doing here?" asked Owl.

Eventually the Rabbit muttered:

"Brainstorming…"

"Without ME?! But I know all the answers!"

"That is true…" said Fox. "And that is precisely the problem."

"What do you mean??"

"Unfortunately you also think for the rest of us…" dared Deer.

Then everybody was silent. Owl picked at the drawings. He saw three mistakes. Then four. But this time he did not dare to say anything.

For the first time, Owl understood something. They did not invite him because he knew too little, they stopped inviting him because when he was present, everybody seemed to know less.

"What if… you explain your plans to me? I will not interrupt."

The animals started talking, argued for a while after discovering the flaws Owl also saw but had not communicated. They came up with new ideas. Owl did not say anything. He found it incredibly difficult.

Finally Beaver looked at him:

"Well, Owl, will it work?"

"I don't know yet. Let's work it out together"

What's really happening?

Owl has fallen into a trap that is particularly tempting for experts: he has confused being right with being useful.

Every correction he has made was… correct. But something else is happening at the same time. When such an expert is in the room, people become either shy to propose their ideas or disengaged – after all, he knows it all. When questions disappear, conversations stall and relationships between stakeholders become colder and colder.

Influence rarely disappears with an announcement. Nobody tells Owl that it has become too difficult to deal with him. He is simply not invited anymore to some of the meetings. His expertise has not become less valuable, but has become harder to use.

Has your conversation moved?

Owl would have thought that the Council has become more efficient: fewer questions, fewer debates, fewer objections. Or that building the bridge is suddenly not a priority anymore. What he did not realise is that the conversation has moved elsewhere.

Architects rarely get a notification when this happens. So pay attention to the silence. Are people still bringing you new ideas to test? All your stakeholders, or only the select group of architects that already admire your expertise?

If you start to recognise the silence, the question is not always "How to position myself at the right table, I have the mandate!", but "What needs to change for my stakeholders to want to brainstorm with me again?"

What could an architect do differently?

Architects are often invited into conversations because they know things others don't. They are passionate about the 'content': about the product, the value proposition, about how things are done and integrated and they also know the history of it all sometimes better than the leading stakeholders.

The temptation is to demonstrate that knowledge. But there is no prize. Especially if it's done like the Owl does.

Of course you should not withhold expertise, only change the way you introduce it.

  • Instead of: "That won't work because X.", ask "How are you thinking about X?" or
  • "There's one constraint I think we need to bring into this. Can we test the idea against it?" or
  • "I see a problem, but before I jump in, take me through how you're thinking about this."

Instead of only asking "How quickly can I spot what is wrong with the proposal?" or "How quickly can I find the solution?", try asking "How can what I know help this group think better?". That means in practice welcoming ideas, letting someone explore something you already assume won't work, asking open questions, correcting assumptions without shutting people down.

Sometimes, the time 'at the table' is the architect's most valuable contribution. It is not about giving back a bullet-proof solution, but about making the table smaller, so everyone at it is a little closer to the middle of the conversation.

Reflection

Think about your last few architecture conversations. Who still brings you ideas before they are fully formed?

When someone proposes something flawed, what is your first instinct? Do you seek to understand their thinking or to show them what they've missed? And if some stakeholders have become unusually quiet: have they stopped thinking about the problem, or has the conversation simply moved somewhere else?

← Back to the Field Guide The Keeper of Imperial Maps →
Self · How do I show up?

The Keeper of Imperial Maps

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

A Story from the Field Guide

The Keeper of Imperial Maps

Illustration of Cassian studying the imperial map while the young Emperor Hadrian gestures beside him, from The Keeper of Imperial Maps

The year is 107 AD. We are in Rome, with Emperor Trajan victoriously returning from conquering rich Dacia. Two long wars are finally over and Rome becomes greater, richer and more admired than ever. But now the real work starts. And we are not talking only about Trajan's Column representing the great battles, but about fully connecting the Empire with the new territories. Roads had to be extended, fortifications strengthened, aqueducts, markets, ports, public buildings had to be erected.

And somewhere among all those plans sat Cassian, the most trusted Chief Planner, the Keeper of the Imperial Maps. He was entrusted with the Imperial Plan and led a literal army of engineers, surveyors and builders. When a governor wanted a new Via, Cassian considered whether it made sense and where it was to be connected. When two provinces requested competing investments in water, trade or defence, Cassian was the first to notice. His maps covered everything in the Roman Empire from West to East, from North to South. Emperor Trajan valued him greatly.

Whenever Trajan had an idea, he would summon Cassian:

"What do you think?"

Cassian would study his maps, ask questions and sometimes disagree. Trajan would usually push back:

"But how could it be done?"

Over the years, Cassian became very good at understanding his emperor. He knew Trajan believed that Rome's strength depended on connecting its growing territories fast, he knew which roads the emperor considered strategically important and which provinces he wanted developed. Soon, Cassian could anticipate Trajan's questions before he asked them. And he worked hard to make sure fewer questions were asked over time. When two alternatives were possible, Cassian knew which one Trajan would prefer.

Trajan was delighted. One afternoon, when a senator asked Trajan whether he would discuss the possibility of a new colosseum in his province, Trajan said

"Ask Cassian, he can answer better than I do, sometimes I think he can replace me while I sleep!"

The room laughed. Cassian could not have imagined a greater compliment.

10 years later there is a new emperor. Hadrian calls for Cassian, the continuous and knowledgeable Keeper of the Imperial Maps.

Cassian arrives carrying all the plans he has spent years preparing: future roads, future military infrastructure, future eastern initiatives – the logical continuation of everything Rome has been, is and, in Cassian's mind, is meant to become.

Cassian begins confidently while opening his maps:

"Emperor Trajan's plan was…"

Hadrian raises his hand to stop him.

"I know Trajan's plan. I want to know what you think."

Cassian is not sure he understands:

"My Emperor?"

"You have spent twenty years studying this Empire. You know all the roads, cities, borders and dependencies better than anyone. You know why choices were made in the past."

Hadrian points at the maps:

"So tell me: what did we get wrong? What does Rome need now?"

Cassian looks down at the Imperial Maps. For years he had become better at predicting questions and reading his emperor's mind. And yet he cannot do it now.

What's really happening?

Cassian has not suddenly become incompetent, quite the opposite: over twenty years he has developed an extraordinary understanding of his emperor's strategy. Eventually he becomes so good at translating strategic intent that Trajan does not need to explain anymore. That sounds like success, but is it? Cassian has fallen into a trap that is particularly tempting for experts: he has confused serving his most senior stakeholder with serving the thing that stakeholder is meant to serve.

Cassian initially challenges Trajan, then he understands his emperor, he learns to anticipate him – first the questions, then the answers – then he becomes his voice. That means he has moved from understanding strategy to anticipating strategy to internalising strategy. His behaviour is rewarded at every step. It is what makes him effective towards the emperor. But his reason for existing is Rome as a whole. Sometimes even the most experienced architects may fall into the same trap.

The closer we work with senior leadership, the better we become at understanding what they want to achieve. The organisational awareness is valuable, because it separates investments that are likely to receive support from the rest. But taken too far, it can turn architecture into an increasingly sophisticated implementation of assumptions that nobody is challenging anymore.

So the danger is not that Cassian understands Trajan too well, or that he will need time to understand Hadrian. The danger unfortunately is that Cassian stopped asking the difficult questions – not only towards the emperor, but to himself.

Whose maps are you carrying?

Cassian arrives to Hadrian carrying the Imperial Maps. Metaphorically however, he forgot he was also carrying twenty years of Trajan's thinking. He missed that 'Imperial' meant 'Empire,' not 'Emperor.'

So whose maps are you carrying? And if your most senior stakeholder were promoted elsewhere, which parts would you still defend in front of their successor?

What could an architect do differently?

Proximity to stakeholders is something all architects strive for. The problem is losing the distance necessary to remain independent and useful to the enterprise or the domain. Understanding the strategy is more than becoming the echo of the most senior stakeholder.

A useful discipline is to separate three questions that can easily be tangled together:

  • What has leadership decided? This is the strategic direction that architecture needs to enable
  • What assumptions does the architecture direction depend on? These are the topics architecture should continue to test as circumstances change.
  • What do I see, from my enterprise-wide (or domain-wide) perspective, that leadership may not see? This is where architectural judgement adds value.

Of course, and very importantly, this does not mean that the sole purpose of architecture is to challenge direction to demonstrate independence. Cassian does not need (and should not) argue with Trajan every morning. But he does need to preserve the distance to observe when yesterday's assumptions do not fit today's situation.

Reflection

Think about one important architecture you are currently shaping.

If your most important stakeholder left tomorrow, how much of your architecture would you still defend?

← Back to the Field Guide Next story — coming soon
Stories

Every story published so far.

Out of a planned fifty. New ones arrive out of order — check the Field Guide to see which theme each belongs to.

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."

Portrait of Ioana Bour
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.

Read on Substack Follow on Instagram
Trust & Authority
Collaboration & People
Insight & Direction

For Enterprise-, Domain- and Solution Architects