Why Transformation Is Becoming the Wrong Model

Most large organisations have become familiar with transformation. They establish a current state, define a target state, identify the gap between the two and create a programme to close it. Enterprise Architecture supports that journey by helping the organisation understand how changes to capabilities, processes, information and technology fit together.

There is nothing inherently wrong with this model. It has helped organisations manage large and complex changes for decades. The problem is that it assumes the destination will remain relevant long enough for the organisation to reach it.

That assumption is becoming harder to defend.

AI makes the problem particularly visible. An organisation may begin a two-year transformation programme based on assumptions about which activities require people, which can be automated and which technologies are mature enough to use. Six months later, some of those assumptions may already have changed. New capabilities become available, costs shift, regulations develop and competitors experiment with different operating models.

The organisation is still moving towards its target state, but the target itself has started to move.

When new technology meets an old organisation

History provides useful examples of this problem. When electricity first entered factories, many manufacturers initially replaced the central steam engine with a large electric motor. The technology changed, but the layout of the factory often remained much the same.

Machines were still organised around the shafts, belts and mechanical structures that had previously distributed power. Electricity improved the existing factory, but it did not immediately change the thinking behind its design.

The larger gains came later, when manufacturers realised that individual machines could have their own motors. Factories could then be reorganised around the flow of work instead of the physical limitations of a central power source. Electricity became important not simply because it replaced steam, but because it allowed organisations to rethink how production itself was organised.

There is a useful parallel with AI.

Putting an AI assistant into an existing process may improve productivity. Adding AI to an existing application may reduce effort. Automating an activity may lower cost or shorten turnaround time. These are worthwhile improvements, but they still leave most of the underlying organisation unchanged.

The more important question is what that organisation would look like if the work itself had been designed with AI available from the beginning.

That is no longer primarily a technology question. It is an architectural one.

The limits of target-state thinking

Enterprise Architecture has traditionally given considerable attention to states. We document the current state, design transition states and define the target state towards which the organisation should move. This creates clarity and gives programmes a common direction.

The approach works well when the environment changes more slowly than the transformation programme itself. It becomes much less effective when important assumptions about technology, execution and organisational design can change several times during the journey.

This is where we believe classical Enterprise Architecture is becoming intellectually bankrupt.

The statement is intentionally uncomfortable, but it is not a criticism of Enterprise Architects or of the value the discipline has created. Capability models, information architecture, principles, governance and technology architecture remain important. The problem lies in continuing to apply an architectural model built around relatively stable states to organisations that increasingly need to adapt continuously.

The intellectual limitation is the assumption that an enterprise is mainly a structure that occasionally needs to be transformed.

An AI-native enterprise needs to become something different. It needs to remain coherent while continuously changing how work is performed.

From transformation to evolution

We use the term Continuous Enterprise Evolution to describe this shift.

This does not mean constant organisational upheaval. In practice, it can mean the opposite. Large transformation programmes often create disruption because changes accumulate over long periods before a new operating model is introduced. Considerable investment is made in reaching a predefined state, after which the organisation spends further effort stabilising it.

Continuous evolution allows change to happen in smaller and more controlled increments. Work can be observed, outcomes measured and improvements introduced without redesigning the entire organisation around each new development. The effect of those changes can then be assessed before further changes are made.

The enterprise does not repeatedly move from one finished operating model to another. It develops the ability to evolve while operating.

For business leaders, this has practical consequences. Investment can increasingly follow demonstrated value rather than distant assumptions about a future state. Ideas that do not work can be abandoned earlier. Successful changes can spread faster. Strategy can influence execution without waiting for the next large transformation programme.

The value is not change for its own sake. It is the ability to adapt without repeatedly destabilising the organisation.

The Executable Enterprise

There is another development that makes this possible. More of the enterprise can now be connected directly to execution.

Business rules can influence execution. Policies can increasingly be represented in ways that systems and AI can interpret. Knowledge can guide decisions. Decisions themselves can be supported or, under defined conditions, delegated. Work can move between people, AI and conventional software depending on the circumstances.

We describe this development as the Executable Enterprise.

This does not mean that organisations become autonomous machines. Boards do not become algorithms and human accountability does not disappear. In fact, greater execution flexibility requires greater clarity about authority, evidence, boundaries, outcomes and responsibility.

The important change is that the way work is performed becomes less tightly coupled to a particular application, team or technology.

A business task may be performed by a person today, supported by an AI system tomorrow and largely automated later. The execution mechanism can change while the purpose of the work remains stable.

This is one reason why work becomes such an important architectural anchor.

Applications change. AI models change. Vendors change. Organisational structures change. The work required to achieve a business outcome is often more persistent than any of them.

NativeWork starts from that assumption

NativeWork™ was created around this change in perspective.

It is an Enterprise Architecture standard and method for designing organisations for an AI-native future. Rather than starting with applications or treating AI as another technology to fit into an existing architecture, NativeWork starts with the work required to achieve business outcomes and then connects the information, execution and technology needed to perform that work.

This also changes what architecture is expected to accomplish.

The objective is not to produce a perfect target state and then spend several years moving towards it. The objective is to create an enterprise that can change how work is performed without losing strategic direction, governance, accountability or architectural coherence.

WorkML™ supports that approach by providing a language for expressing these architectural structures in a form intended to be understood by both people and intelligent systems. We will explore that relationship more closely later in this series.

For now, the more important point is the change in architectural ambition.

Architecture without a fixed destination

Enterprise Architecture will still provide direction. Organisations will still need principles, constraints, strategic choices and technology standards. Leaders must still decide what the organisation is trying to achieve and which outcomes matter.

What changes is the assumption that good architecture must describe a relatively fixed destination.

In an environment where execution can continuously improve, a more valuable architecture may be one that allows the enterprise to keep changing while remaining understandable and governable. The role of the architect then changes with it.

The Enterprise Architect is no longer primarily helping the organisation move from today's architecture towards tomorrow's architecture. The architect increasingly helps create an organisation that can continually become tomorrow's organisation.

That is a different ambition from transformation.

It is the beginning of Continuous Enterprise Evolution.

About NativeWork

NativeWork™ is an AI-native Enterprise Architecture standard and method developed by Centipod. It places work at the centre of enterprise design and provides an architectural foundation for Continuous Enterprise Evolution.

WorkML™ is the accompanying language for expressing NativeWork architectures.

Learn more at nativework.org.

NativeWork™ and WorkML™ are trademarks of Centipod. Trademark applications are pending.

This article was created by people. We have used artificial intelligence (AI) to help articulate our message and refine the text. AI was employed as a tool to assist with structuring, identifying grammatical and spelling errors, and improving readability. The final document has been carefully reviewed and approved by our team.