Your architecture team produces capability maps, principles, roadmaps and target states. But what happens next? Does that work help someone make a better decision, and could you explain the difference it made a year later?
I’ve cared about that question for a long time. That’s why I wanted to speak with someone who has studied architecture benefits as a researcher and tested them as a consultant.
Eetu Niemi, Ph.D. is an enterprise architect, consultant and author with about 20 years in the field. His 2016 doctoral thesis at Tampere University of Technology, Enterprise Architecture Benefit Realization, explored how architecture work turns into benefits for the organisation. His books include Enterprise Architecture: Your Guide to Organizational Transformation, and a couple on IT consulting. Interestingly, he also has a debut children’s novel available.
The Foresight-Driven Enterprise Conversations is part of my Substack publication and in these conversations, I use the University of Houston’s description of foresight as the study of change, and I explore enterprise architecture as one way to help organisations respond to change. The connection I want to examine is practical: how does architectural insight become something people actually use? Eetu’s answer kept coming back to one idea, in his words:
The use is the key in enterprise architecture.
Models rarely fail on quality alone
Quality still matters. Architecture descriptions need to be useful and fit for purpose, but producing them is only part of the job. The next question is whether people use them when they plan and decide.
In Eetu’s experience, the bigger problem is the gap between architecture work and the places where decisions happen. The practice needs a connection to strategy, investment planning, portfolio management and delivery, beyond its place in IT. Without it, architects end up talking among themselves, or their analysis arrives after the decision is set. As Eetu put it, the insight alone produces very little.
Welcome to The Foresight-Driven Enterprise. A newsletter for chief architects and forward-thinking leaders building what comes next
Better decisions when the future is unclear, that’s the whole point. As leaders, we know the hardest calls arrive before the facts do. If that’s the seat you sit in, this is for you. There’s a new piece almost every week. I write about how to think clearly about the futures ahead, and how to create the future, by which I mean building toward the one you want while staying ready for the others that arrive. It’s plain language and real methods, the ones I use with the leaders I work with. You get applied foresight and strategy execution, no-nonsense mental models from the field. If you want to think like a futurist, plan like a strategist, and build like an architect, subscribe below.
What makes a model change a decision
I took four practical questions from this part of the conversation: who is the model for, when will they need it, what will it help them see, and what information will make it useful?
Who is it for? Start with a clear user and purpose. Who needs this view, and what are they trying to decide? Following a framework or notation isn’t enough if the result doesn’t meet that need.
When will they need it? Bring the analysis in while there’s still room to influence the decision. Once plans are “set in concrete”, even very good analysis struggles to change them.
What will it help them see? In Eetu’s words, the work “has to bring out something that was not known before.” That might be a hidden dependency, an untested assumption or knowledge scattered across teams, brought into one shared view. Elements and their relations rarely do that for leaders on their own.
What information makes it useful? Add the data the decision needs. Eetu named criticality, cost and quality, and risk, dependencies or strategic importance may matter too. Shown as a heat map, those differences become easy to discuss, as long as the assessment underneath is sound.
Benefits arrive in layers
Eetu’s research found several interacting factors behind benefit realisation. They include the quality of the architecture processes, products and services, how they’re used, and the organisation around them, from its management system to its culture.
But, benefits also arrive at different stages. Shared understanding, clearer communication and identified dependencies tend to come first. Better project outcomes and lower costs can take much longer, and the further you move towards those wider outcomes, the harder it gets to separate the practice’s contribution from the many other things happening in the organisation.
So Eetu starts close to the architecture work: what people understood, what they used and what it helped them decide. Those benefits are the easiest to measure.
How to measure without inventing a new KPI
Ask the people who use the architecture. Leadership, IT management, product owners and project teams are the practice’s customers. Start with interviews to find specific examples, then use surveys to track how views change over time. Make the feedback concrete: what became clearer, which decision changed, what work became easier?
Look at your own practice. Pick one simple maturity model and use the same one every time. A first pass takes about half an hour inside the team, and stakeholder interviews give a fuller picture. Eetu’s advice is direct: “First get your own lot into order,” before you tell stakeholders they don’t use your work. Treat the score as a check on the practice itself, not as proof of business benefit.
Track involvement and outcomes over time. Record where architects took part in planning and decisions, then follow what happened. Eetu suggests following the projects that received architecture support across several years, and comparing their success rate, timetable and budget.
Architects need influence and a clear role
Architects very seldom hold a management mandate. How much authority they have depends on how the organisation defines the role and its governance. A chief architect decides how the architecture function runs, and that’s usually where the mandate ends. What architects bring is a view across organisational boundaries, so people can see the dependencies, risks and consequences of a decision.
Influence comes from being useful and being trusted. Start with the problems decision makers actually face, and talk in terms they recognise. A formal place helps, such as an architecture check in the development or the strategy process. Without one, Eetu’s advice is to start where you can, even with a conversation at the coffee machine. The longer-term aim is to make the practice a dependable part of planning and governance.
The limits of architecture
Eetu put it plainly: “EA is not a replacement for change management.” Architects can help people understand a change and what it will affect, but communication, participation, training and leadership still need their own attention.
I also asked whether the practice mainly keeps order during change or helps an organisation choose which change to pursue. Eetu chose the first: it “brings order to the chaos.” For foresight itself, he said, the method matters less than the architect, and how closely they follow changes in the environment.
My take
Eetu’s answer on capabilities, links foresight to enterprise architecture through capability-based planning. It’s a view I hold and am still exploring, and I made the case for exploring this linkage in my talk on integrating foresight and the enterprise at Intersection 25. In concrete terms, start with your strategic goals and plausible future scenarios, testing the strategies with the scenarios. Then ask which capabilities might become more important and where the organisation has gaps. Connect those capabilities to the processes, teams, applications and data that support them. Eetu goes further to suggest linking this output to solution architecture, so you can see what each change initiative actually changes. That gives investment discussions a clearer basis, without pretending the capability map makes the decision for you. As Eetu said, a capability map alone “just looks nice,” and we need EA to show value not nice artefacts.
On foresight, Eetu suggested that the sensing comes from architects who follow changes in their environment. I see that architect as the modern architect, with alot of focus around AI, some call them AI-Native Architects. But it goes more than that, they are Change agents, catalysts and strategic advisors and have the foresight skill in their back pocket. Meaning, they also know how foresight really works and can apply it for their enterprise. That’s why I argue for foresight as a repeated cycle tied to planning and portfolio rhythms, so what these architects notice reaches the decisions those cycles make. In case you are new to this term, foresight brings structured ways to explore and prepare for plausible futures, and foresight-driven enterprise architects connect what those futures mean for the organisation and feed it back.
Before your next review
Eetu left listeners with one challenge for the next 90 days. Enterprise architects, he said, often struggle in their relationship with senior business management, so aim there.
Choose an upcoming strategy, investment, acquisition or portfolio decision. Look for one with a clear owner and enough time left for your analysis to make a difference.
Build the analysis around the choice they face. Include the information that matters, such as cost, criticality, quality, risk or dependencies, and make your assumptions and gaps visible.
Get the analysis to the decision owner while the options are still open. If you don’t have a direct relationship, work through a sponsor or colleague who can connect you to the right discussion.
Before your next review, ask yourself: which decision in the next 90 days could your architecture work help shape, and who needs to see it while there’s still time to act?
Find Eetu
Website: eetuniemi.net
Substack: Enterprise Architecture Transformation: A Practical Guide
LinkedIn: Eetu Niemi, PhD
Book: Enterprise Architecture: Your Guide to Organizational Transformation (Business Expert Press)
Research: EA Benefits Realization Paper (Coala.fi)
For more of Eetu’s practical writing on architecture and organisational change, take a look at his newsletter, Enterprise Architecture Transformation.
