Business continuously changes the way their models and operations for a multitude of justified reasons. Either to introduce new products, respond to change in the market spectrum, cutting costs here and there, or for the sake of testing freshwaters with a complete renovation of the business model. The sky is the limit to why a business might need to introduce change. But how would structure change work within the confinement of enterprise architecture?
I tend to describe such change as the holy trinity. And what I mean by that is when the motivation is already set up for a change from stakeholders, whether a shareholder, a regulator or internal intend, then it becomes an input for a grand level of organization change. I can describe the holy trinity by the following diagram.
This most simple change you usually witness is when an intention or motivation is communicated to the strategy office in which it directly transforms the strategy into initiatives and KPIs. Once the projects are defined, it is taken to the domain architects, or SMEs, from each department to carry out the solution change, whether through internal or external support with the Project Office support. This approach, although successful, finds itself in front of a change paradox that minimizes the impact across the enterprise. So assume that a current change requires an enhancement in a value stream and value proposition that is already critical to the enterprise, so how much change should happen?
Luckily; most of the value streams for small and medium enterprises are straight-forward and rely on one information system. So, it is a matter of a complete solution delivery while maintaining the aspects of the old one like the processes, migrations, and parallel runs. But what happens if a change is one that applies for a sophisticated and convoluted value stream, or rather a change that changes the dimension of the business itself, then how could direct projects cover such complexity?
The is more advent in large enterprises where a change might become such a complex that might take years to deliver. Moreover, change usually happens at a capability level and not at the value stream due to the convolution o the change (thank God for the advancement in API and SOA!).
Luckily, a trend has been progressing within a couple of last years, and that is to embed enterprise architecture as a critical element in planning and orchestrating transitions. In this approach, although not one dimensional, the enterprise architect, along with domain architects, will analyze the need for change from business architecture lenses. Here, value streams, information, organization hierarchy, and capability will be analyzed for the need to change. And then, after examining the need for change, an impact and benefit models will be developed along with multiple optional solutions, much like scenario planning. In the end, a resolution is adopted with collaboration of the EA office, domain architects, and portfolio management office.
This is not strictly followed, however, but it provides the best baseline to have a business-outcome enterprise architect with a more significant benefit across the enterprise as a whole. Nevertheless, in the board universe of EA, there is no approach without its critics, which is fine as long as the one understands what he/she is into.