Belief #8 Best Architectures are embedded with the change organization

Have you ever considered how architecture should be placed in relation to change initiatives in the organization? 

That is the topic of this belief. Irrespective of how we organize change in our organization, the architecture function has to be an integral part of it. It shall not be someone trying to advise or govern the change organization from the outside.  

The first reason for this is to ensure alignment between architecture and the change you envision. For this to happen architecture need to be embedded with the people doing the change. This allows architects to develop architectures good enough to be trusted and have the impact it deserves. Furthermore, creating such architecture requires contextual and updated knowledge as wells as balanced, timely and relevant contributions. This can only be done when you are at the heart of change, not looking at it from the outside. The key is “IT change is business change and business change is IT change”. 

The second reason is cultural, and it is about growing wiser together, creating a common history. Architects and other change agents need to have mutual learnings from previous iterations. This they can feed into the next iterations, and the collaboration builds the necessary trust. This is only possible if the architecture practice embedded into the way of working with change. Thus, also allowing it to evolve from learnings and adapt to the changing needs of the organisation. 

Now you may think; how can architects then stay independent of the initiatives to serve purposes that goes across and above the single initiative? 

Well, there should be no opposing purposes between our target architecture and what the change initiative plans to implement. Target architecture and change are mutually dependent. Thus, if you focus on only one you will “sub-optimise” either architecture or organisation. For example, owner of house has a blueprint from the architect. However, builders do not provide feedback and discuss with architect during construction. Thus it ended up not creating the “target architecture” and hence the value. We must as architects challenge any model that create a wrong incentives structure. An example of such a model is a reporting structure with “green lights” for delivering on time or budget rather than delivering as much value as soon as possible with the lowest possible cost.  

Furthermore, a single architect should never be responsible for initiatives or domains for that matter. Architecture is too important for local kings. It is not a management role. Architecture is a collaborative effort. This is best organized as a team of architects providing services as part of the change setup (not allowing body shopping).  

Lastly, an architecture function must build up and maintain an enterprise-wide architecture model. They shall not leave initiatives to build their own local versions of the big picture. This is not a large and descriptive model of everything in details. Rather, this is a model good enough to ensure the initiative can work independently, while being aligned with the enterprise. One of the main uses of the enterprise architecture model is to scope and define initiative-specific architectures in a wider context, e.g. ownership of data and strategic dependencies. Moreover, learnings from change initiatives feed back into the model. 

What is your experience? We would love to hear our opinion!