Enterprise Architecture is relevant any situation where we need to change an enterprise. If we then take “enterprise” to mean any human endeavour or undertaking – and not just commercial companies – then enterprise architecture is germane for pretty much any change! A main factor which determines the role of EA is the degree of change. In this guideline we look at three high-level types of enterprise change, to provide some practical tips on how this is used the best ways to involve the EA team.
The three high-level types of enterprise change that we are going to use in this guideline are:
• Developmental – some other words to describe this type of change are maintenance, improvement or enhancement. A key point is that it is taking what currently exists,
and making it better. This might be fixing something that is not working well, or it might be adding some components to augment what is already there. Developmental change doesn’t usually involve a change in the state of the enterprise architecture. For example, maintenance is keeping the current architecture state by simply fixing something
that isn’t running correctly. Improvement or enhancement is usually bolting on something extra by adding components to the architecture; a good example here might be opening up new functionality within an existing customer relationship management system.
• Transitional – here the change actually makes a difference to the architectural state. There is a transition from the current architecture to a transition or target architecture state. The key point here is that there is a problem with the current architecture that is resolved by the new transition or target architecture state. This requires dismantling parts of the current architecture, and replacing them with something that is architecturally different.
• Transformational – here there is also a change in the architectural state, but it is on a different scale than transitional change – it is altogether more radical or innovative. This type of change often supports a fundamental change in strategy, business model, or business direction. True transformational change requires a new way of thinking about the enterprise; it requires a change in mindset. The result is often a massive shift for the enterprise; for example, an organisation that has been around for many years running a bricks-and-mortar business model needs to radically redesign its operations to survive in a bricks-and-clicks world.
The figure shows the differences visually. With developmental change the current architectural state remains; change happens within that state. With transitional change the architectural state gradually evolves into something slightly different. With transformational change the current architectural state is replaced with a radically different target state.
Most EA initiatives fall into the first two categories of change, but there are also plenty of examples of transformational projects. Another key point is that transformational change usually requires a number of incremental or transitional steps, but the end result is a far-reaching break from the past.
Lets’ look now at the role of EA for each type of change.
EA and Developmental Change
Developmental change is relatively easy, and does not require much effort from the EA team. The changes do not require a different mindset. The changes are not likely to cause much disruption, and in fact most stakeholders will not even notice the changes! The most important role for the EA team is in governance: they need to make sure that the changes are compliant with the current architecture, and that they do not introduce any additional risks, constraints, problems, or concerns. From a business perspective, the EA team also need to check that the changes are aligned with current capabilities.
There are always going to be ongoing maintenance and developmental changes that tweak, fine-tune or adjust the current architecture, and it makes sense for the EA team to check that these minor changes fit in with the overall direction that they have set for architectural evolution. On the other hand, they shouldn’t spend too much time on this; after all, these are not architecturally significant changes, and the EA team need to be careful not to waste time on changes that don’t affect the architectural state.
EA and Transitional Change
Transitional change certainly needs to involve the EA team! They need to examine the current architecture to explicitly show how its components and their interactions constrain or limit the needs or strategies of the enterprise. They need to develop one or more options for the evolution of the architecture, and work with decision makers to choose the best road-map for making the changes. A key point here is that the EA team should have the necessary expertise to devise an optimum roadmap which sequences transition architectures in the best possible way to balance the needs of multiple stakeholders, to address stakeholder concerns, to achieve defined goals and strategies, to build capabilities, and to deliver architectural states that are fit for purpose and sustainable.
The EA team should also position individual projects and transitions within a much larger, overall, enterprise-wide context. They need to provide the big picture that shows how each investment contributes to the overall strategic vectors, which in turn guide or lead evolution of the architecture in a consistent direction.
EA and Transformational Change
With transformational change the EA team should be major players. This type of change has a big impact – on the architecture and above all on the enterprise itself. The options presented by the EA team can have a big impact on the survival or the enterprise! An architecture that supports and enables the required capabilities is going to be more successful than one that hinders or hampers. An architecture that is flexible, adaptable and responsive is going to be better than one that is forced into kneejerk reactions to unexpected demands. And an intentional architecture that is fit-for-purpose is going to be more useful than one that is rather random or ad hoc.
The EA team bring a unique contribution to discussions around enterprise change, by bringing a holistic understanding of the components that make up an enterprise and how they support or restrict its needs or strategies. They bring a long-term to short-term investments, and they understand how to balance trade-offs and priorities. They are also the only discipline that covers an organizational, business, and IT perspective. In addition, a good EA team take into account other factors that have a strong bearing on successful change – such as political, social, human, and cultural considerations.
Summary
Each type of change means a different role for the EA team. In many organizations these three types of change are taking place at the same time!
Developmental change requires less architecting and more governance.
Transitional and transformational change is where the EA team really add value. Typically the two types of change go hand in hand – especially in larger organizations. Making the distinction between the two types of change helps determine where and how the EA team should be involved.
With all three types of change the most important thing to remember is to think like an architect – which means providing the artifacts that allow stakeholders and decision makers to understand how the architecture constrains or enables their concerns and needs.
We hope you have found the distinction between these three types of EA change interesting, informative, and above all – useful! As ever, we are interested to know your comments, feedback, advice or suggestions.
