The Enterprise Architect as a Change Agent – Must-have or a Nice-to-have?

The Enterprise Architect as a Change Agent – a “Must-have” or a “Nice-to-have”?

To set the scene, I am going to focus on a very small part of the body of knowledge that constitutes Organizational Development and Change Management theory. OCM theory has numerous models which are used to represent the journey of change management, however the one I am going to discuss here is “Gleicher’s Formula” possibly better known as the “Formula for Change or  the “Change Equation”.

It provides a model which lists three factors that are necessary (but not sufficient) if meaningful change is to take place.

These factors are:

1. A = dissatisfaction of the status quo – or “how things are now”.
2. B = a combined vision of what is possible, or an end state.
3. C = Knowledge of next steps that will take the organization towards the vision.
4. D = Resistance, or the “cost” or “pain” of change.

The equation is as follows:

A*B*C > D

for change to be possible.

 Editorial comment – I have referred here to a Wikipedia article https://en.wikipedia.org/wiki/Formula_for_change  although I have been using the Change Equation in dealing with organizational change for years.

As we look at this equation, let me pose the following questions:

• How many times have we been in a situation where an organization is in dire straits (for whatever reason) and needs to take a different path, but somehow doesn’t have the leadership, or vision, or seems to struggle with how to start down a path to improvement? “We know we’re in trouble from our level, but leadership seems to be unaware or unwilling to step up to the plate to fix the problems”.
• When have we come across situations where a visionary leader has a seemingly obvious ( to external observers) strategy and plan to get there, but the organization seems to be trapped in the past, and unwilling to move out of their comfort zones to change. “We have done things this way for years, and see no need to change now”.
• Have we seen organizations where there is unhappiness, a sense of what needs to be done, but no-one knows quite how to start. “If only ‘they’ would tell us what to do – we can’t do it at our level.”

Now let’s move on to the perspective of an architect and use the Architecture Development Cycle from TOGAF as a model. Everyone who has looked at TOGAF is familiar with this diagram and with the approach to the ADM – the Architecture Development Method.

At a high level and with the Change Equation as a reference point, and also  with due attention to the many good references made to Change Management in TOGAF, I again make some observations and pose some questions:

1. As we address the situation in an organization in order to place the ADM initiative in context of the current situation and the need to deal with existing challenges, how often do we experience situations where there is little or no explicit dissatisfaction with the status quo, or where there are stakeholders who cannot or will not acknowledge current challenges? And when we have moved on to the later activities in the ADC without addressing the current situation (focusing more on the to-be and less on the as-is), how often have there been challenges about why the exercise is being done at all, and even subtle or not-so-subtle actions to stop the project.  Could this represent “A” in the Change Equation?
2. As we attempt to build the architectural vision, and “sell” it to the organization, have we found resistance in the form of acknowledgement that there are existing problems, but lack of clarity or common purpose about what to do about it? Further, as we move down the right hand half of the cycle, how often is there continuing difficulty in getting consensus and agreement about the detailed definition of the future state? Could this represent “B” in the equation?
3. Of course within Transition Planning Iteration, when it is built on a firm foundation from the first two steps, it becomes easier for the team to return to the foundations in order to work through the categorization and prioritization of projects and activities. Just a thought – how much detail and how far into the future do we need to develop here, in order to have a robust plan? And can more detail help cover for possible weaknesses if we haven’t put sufficient effort into the first phases?  Could this represent “C” in the equation?
4. Finally – have we done enough to be able to overcome the cost/pain that will arise as we execute? Is the Architecture Governance Iteration strong enough to deal with the risks, personal costs, “fear factor” and resistance that MUST be overcome to achieve the successful transformation we set out to deliver? This finally relates to the overall necessity for all aspects of the cycle to overcome the resistance to change that we will surely encounter – the need for all the above to be greater than “D” in the equation.

So – as we move through our various engagements and phases of our projects, I would suggest that, as we solve our architectural challenges, we stop every so often and reflect on where we are in relation to the Change Equation.