For decades, Enterprise Architecture has been taught as a journey from current state to future state. But enterprises do not stand still long enough for the journey to work quite like that.
We Have a Strategy, Maybe, Somewhere
Many Enterprise Architecture frameworks offer a wonderfully reassuring logic. Understand the business strategy; document the current architecture; design the future architecture; identify the gaps; build the roadmaps; then execute.
It is orderly, rational and difficult to argue with. There is only one small problem. This does not seem to be how organisations work with EA in practice. Most organisations do have a strategy, somewhere. There is usually a strategy presentation, an annual report, a set of management priorities, investment plans and perhaps a handful of must-win battles. Ask six executives what the strategy means for the decisions being made today, however, and the answer may become considerably less precise.
And meanwhile, the organisation moves. A competitor changes direction. AI creates a new opportunity. Regulation intervenes. An acquisition appears. Performance disappoints or exceeds expectations. A new CEO arrives with different priorities. The strategy has not disappeared. But which version of it should architecture now respond to?
The strategic mountaintop may be perfectly visible. Unfortunately, the enterprise is already moving on tracks laid decades ago, and those tracks do not move simply because the destination shifts.
Svyatoslav Kotusev spent much of his research life challenging the gap between EA in theory and EA in practice. In his 2017 article “Critical Questions in Enterprise Architecture Research”, he reviews empirical studies showing remarkably different approaches in real organisations. In one study, 45% documented both current and future states, while 37% documented only the current state and 10% only the future state. Other studies cited in the article found EA roadmaps in only around 60% of organisations.
That leaves us with a slightly uncomfortable question. If the framework is optional, the as-is is optional, the to-be is optional and even the roadmap appears to be optional, what exactly is not optional in today’s Enterprise Architecture? Is strategy optional as well?
Perhaps frameworks, and many of us practitioners, have spent too much time defining EA by its artefacts and metamodels, and not enough time defining it by what EA enables an entire organisation to do when people collaborate through standardised processes and reusable terms, take responsibility and make informed decisions together.
Strategy Has an Annoying Habit of Drifting
There is another problem with putting strategy at the beginning of an architectural assembly line: strategy evolves.
Strategy may begin with a predefined intent, but innovation, feedback, new opportunities and changing conditions continuously reshape it. As a result, strategy can evolve much faster than the digital landscape around it.
Kotusev points to something most experienced architects will recognise. Business strategy may be ambiguous or difficult to translate directly into information systems. And, inconveniently, strategy can change substantially faster than the underlying IT landscape can be modernised.
A landscape assembled over twenty years does not politely rearrange itself every time management produces a new strategic presentation or replaces a CxO. This does not make Strategy-to-Execution wrong. It makes it incomplete as a definition of Enterprise Architecture.
If EA can only create value after receiving a clear business strategy from above, architects could spend considerable time waiting for an input that never arrives in quite the form expected.
Meanwhile, the enterprise has 500 applications to operate. Seven technologies are approaching end-of-support. There are duplicate systems, regulatory obligations, cyber risks and investment decisions to make. And architects can work on all these things even when the strategy is outdated, unclear or simply not reflected in the current landscape.
While EA theory puts Strategy-to-Execution high on the agenda, much of the everyday value of EA is created much closer to the existing portfolio and its stakeholders. This is also what we offer with innovative Next-Insight.
Unfortunately for architecture theory, the enterprise has a habit of continuing to operate while we architect it.
Jeanne Ross Starts Somewhere Else
This is where the work of Jeanne Ross and colleagues becomes particularly interesting. Rather than assuming the latest strategy should provide the stable foundation, their operating-model thinking asks a more fundamental question: how much business process standardisation and integration does this organisation require?
This leads to the familiar operating models of diversification, coordination, replication and unification. And the distinction matters. A unification model, for example, deliberately combines high process standardisation with high integration. Shared processes and information, supported by a strongly integrated digital foundation, become characteristics of the enterprise itself.
They are not simply consequences of this year’s strategy. Strategy can change on top of that foundation. This subtly reverses the normal EA argument. Instead of saying: “Strategy defines the architecture we need”, we can also say, “Architecture creates an organisational capability through which different strategies can be executed”. This gives target architecture a different purpose: not simply to implement today’s strategy, but to create the flexibility needed to support tomorrow’s strategic choices about platforms, systems, cloud and the wider digital landscape.
Kotusev himself points towards the operating-model thinking of Jeanne Ross and colleagues as an alternative to assuming that formal business strategy must always be the starting point for architecture. This makes architecture much less interesting as a description of some distant future. It becomes interesting as part of how the organisation operates today. It also changes the value equation. EA should not have to wait for the future state to be realised before producing value. It should create value in year one, more value in year two, and continue to grow with the organisation.
Business Architecture Sounds Different in the Boardroom
There is a similar lesson in Business Architecture. I have listened to many excellent explanations of Business Architecture. The more experienced the practitioner, the less the conversation seems to be about modelling and the more it becomes about management.
Imagine a management team representing six organisational silos. There is an investment budget to distribute. The discussion is about where the enterprise needs to change, which business areas should receive investment, which capabilities matter, which outcomes are expected and what initiatives are already consuming resources. Choices are made.
Those choices and the relationships behind them are documented. A few months later, something new arrives and needs funding. We do not start another grand architecture exercise. We bring the same information back into the management room and ask: If we want to invest in this, what are we prepared to change, postpone or stop?
That is alignment. And I would argue that this is Business Architecture in perhaps its most useful form. The capability map is not important simply because capabilities are aesthetically pleasing boxes to put on a slide.
It is useful because capabilities provide a relatively stable language through which six organisational silos can discuss priorities and investments as one enterprise.
The architecture allows management to remember why previous decisions were made and to understand the implications of making the next one. What appears in a repository as objects and relationships is, in reality, a mechanism for having better management conversations. This is where Business Architecture stops being architecture documentation and becomes management infrastructure.
And Then the Customer Asks for the System List
There is, however, another curious observation from practice. Those sophisticated Business Architecture conversations are rarely where organisations actually start. Talk about Strategy-to-Execution, Business Architecture or something with AI, and people willingly sign up for the next webinar. These are the headlines that create ambition and interest.
Then an organisation buys an EA platform, the implementation workshop begins, everybody sits down, and remarkably often the first practical question is: “Can we start by importing our application list?”
Of course we can. In fact, after seeing this happen repeatedly, I have begun to wonder whether there is anything immature about it at all. Perhaps the system list is simply a very rational place to start. The organisation already has the systems. Those systems have owners, costs, vendors, technologies, integrations, lifecycle states and risks. They support business processes and have risks, all of them. Projects change them. Regulations constrain them.
Start with 500 applications. Identify the owners. Add lifecycle status. Connect technologies. Add costs and risks. Connect applications to the business processes or capabilities they support. Add dependencies and initiatives as they become relevant. Very quickly, the humble system list stops being a list. It becomes part of an enterprise navigation of connected metadata.
And eventually that online connectivity can connect applications to capabilities, capabilities to strategy, technologies to risks, risks to controls and initiatives to investment decisions. There is no requirement to model the entire enterprise before being allowed to improve any of it.
Perhaps this explains something I have observed many times. Architects who create results for stakeholders do not necessarily wait for strategy to arrive from the top. Very often, they start building from the middle out, delivering value already by the first onboarding steps.
Enterprise Architecture Is Four Continuous Practices
This leads me to think about Enterprise Architecture not as a journey, but as four continuous practices operating around a shared body of enterprise knowledge.
These four practices are not stages. They happen simultaneously. Each has its own processes and deliverables, and each can mature independently.
An organisation may be excellent at Application Portfolio Management and relatively immature in Business Architecture. Another may have sophisticated solution architecture but poor portfolio transparency. A third may have strong governance and regulatory controls but little meaningful Strategy-to-Execution.
And perhaps that is perfectly fine. Because organisations do not necessarily need to start Enterprise Architecture in the same place.
Some start with strategy and Business Architecture. Some start with solution architecture and architecture governance. Some start with risk and compliance. And, in my experience, a surprisingly large number start with an Excel file containing a list of systems. The system list implemented e.g. with Next-Insight becomes connected to owners, technologies, capabilities, processes and risks. Investment decisions become connected to capabilities and initiatives. New solutions become connected to the landscape they are changing. Governance becomes connected to the people actually accountable for decisions. The repository is not the architecture. It is the shared context that allows these four practices to connect.
Perhaps this is the fact behind Kotusev’s uncomfortable empirical observations. Frameworks may be optional. Current and future states may be optional. Roadmaps may be optional. Even an explicit strategy may sometimes be missing. But enterprises still have to make decisions about what they own, what they change, what they invest in and what they govern.
That requires visibility, context, delegation and a holistic view. This is where Enterprise Architecture can make a difference.
Maybe Enterprise Architecture does not need one mandatory starting point. It just needs to become useful somewhere, connect from there, and become part of how the enterprise actually operates.
If this sounds closer to how Enterprise Architecture actually works in your organisation, perhaps we should talk. Book a talk here.
