The Enterprise Architect as a Change Agent
As I was going through TOGAF[Link] training, I was struck by the parallels between the TOGAF Architecture Development Method or ADM, and the Change Equation used as part of Organizational Change Management or OCM methodology.
This blog looks at the comparison.
To set the scene for the comparison, I will be looking at the roles of Enterprise Architects and Change Agents, followed by a discussion on the parallels between the ADM and OCM.
The Roles of Enterprise Architects and Change Agents
Who is an Enterprise Architect?
First a scenic detour…
An Architect according to the Ancient Greeks
The Ideal Architect should be a person of Letters, a Mathematician, familiar with Historical studies, a diligent student of Philosophy, acquainted with Music, not Ignorant of Medicine, learned in the responses of Jurisconsults, familiar with Astronomy and Astronomical Calculations.(Vitruvius, circa 25 BC)
In addition to those routine architect capabilities described by the Greeks, the Enterprise Architect should also be able to:
- Facilitate the definition of architectures to support business strategies by aligning IT technologies and strategies with business goals and objectives
- Map current enterprise IT landscape, plan target architecture and direct and manage the transition from current architecture to target architecture
- Have a broad knowledge of business processes, organizations, technology, IT strategies and a deep knowledge in relevant (such as SAP) technologies and their solutions
They should also have:
- Experience with definition and integration of business, data, application, and technical architecture layers
- Experience and thought leadership with creating and managing enterprise-wide formal frameworks and supporting repositories
- Ability to align and effectively communicate with customer IT and Business organizations
- Experience managing IT Portfolios
- Knowledge on the capabilities of the applicable technology-based Business Process Platform.
- Soft skills… (*) including leadership, presenting/public speaking, and networking capabilities across the technology partner and customer ecosystems, and the ability to influence change (as a Change Agent), which is what I really want to talk about.
What is a Change Agent?
A definition: A change agent acts as a consultant for an organization and works to evaluate, analyze and implement necessary changes to organizational procedures. The change agent’s role includes serving as a researcher, counselor, trainer or teacher within the organization[Link].
So, based on the EA’s soft skills requirements and the definition of the Change Agent we can hopefully deduce that Enterprise Architects should consider themselves to be Change Agents from time to time. The question then is – how can we set the framework to help EA’s think through their role as Change Agents?
Models for Change Management and Architecture Method
A Model for Change Management
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 a formula developed in the 1960’s (with some confusion as to the creator), known as the “Formula for Change[Reference]” or the “Change Equation”. (As a recovering chemical engineer, I must include at least one equation in any document!)
It provides a model which lists four factors that are necessary if meaningful change is to take place.
The Change Equation is as follows:
Change happens when
C = A*B*D > X
- C = Change
- A = Dissatisfaction with the status quo – or “how messed up things are now”.
This can take the form of poor financial results which are obvious to all, or an intervention by senior management or shareholders who believe that there is considerable room for improvement for the organization.
- B = Vision of what is possible, the future state.
This factor requires visionary leadership and clarity of thought and expression to deliver the message about the desired future and gain commitment to it. When difficulties arise, this vision must provide solid inspiration for the organization. One way to gain commitment to vision of the future and to drive action is to paint a picture of a doomsday scenario by asking the question, “What happens if we do nothing?”.
- D = Knowledge of next steps that will take the organization towards the vision.
This does not suggest a detailed plan but is the start of the process of taking small manageable, visible next steps towards the goal, and away from the current “pain”.
- X = Resistance to change, or the “cost” or “pain” of change.
This is both the monetary cost and the personal cost of change, which results in resistance to the proposed change for reasons such as perceived loss of power and control as well as fear of the unknown and loss of skills resulting from the change.
Finally, the three factors are multiplied together so if any one of them is absent or poorly constructed then their product is zero or very low and will not overcome the resistance.
As we look at this equation, let’s 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”. (B and D missing, A not apparent to all)
- When have we come across situations where a visionary leader has a seemingly obvious (to external observers) strategy and plan to get there, but their organization is 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”. (X beating A, B and D) The situation at Intel, faced by Andy Grove in the 1980’s and 1990’s, is an example of this situation.
- 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.” (D missing)
Examining the above common situations, we can see where elements of the equation are missing or are not clear. The analysis of the situation can help us to initiate plans to address the gaps, using tried and tested OCM intervention techniques.
The Architecture Development Method
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.
Figure 1 Architecture Development Cycle from TOGAF 9
Some Observations linking the two models together
Generally, Architectural Development Cycles start from the top of the diagram and move clockwise through the steps, with some iterations anticipated as shown in the diagram. How does the method have links to the Change Equation?
At a high level, with the Change Equation as a reference point, and with due attention to the many good references made to Change Management in TOGAF, I will make some observations below and pose some questions in order to illustrate the links.
- As we address the situation in an organization to place the ADM initiative in context of the current situation (Architecture Context Iteration) and a 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 may be stakeholders who cannot or will not acknowledge current challenges? And when we have moved on to the later activities without initially addressing the current situation (focusing more on the to-be and less on the as-is), how often have there been later challenges about why the project is being done at all, and even subtle or not-so-subtle actions to stop the project. Could this represent “A”, or lack of “A”, in the Change Equation?
- 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 (from Context to Definition), how often is there continuing difficulty in getting consensus and agreement about the detailed definition of the future state? Could this represent “B, or lack of “B”, in the equation?
- Within the Transition Planning Iteration, when it is built on a firm foundation based on the Change Equation in earlier steps, it becomes easier for the team to justify and work through the categorization and prioritization of projects and activities. A question – how much detail and how far into the future do we need to go here to develop a robust plan, if earlier steps are missing or weak? Could this represent “D”, or lack thereof, in the equation?
- Finally – have we done enough to overcome the cost/pain that will arise as we execute? Are the driving forces in 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 “X” in the equation.
So – as we move through our various engagements and phases of our projects, and as we address our architectural challenges, we might pause every so often and reflect on where we are in relation to the Change Equation, in addition to following the tenets of ADM.
Some great places to stop and take stock would be, for example:
- Does the Architecture Vision cover the elements of the Change Equation, in a way that clearly lays out the case for change including next steps, to start the change transition? (Consider variables A, B and D.)
- Do the Architecture and Transition Planning definitions provide clear and compelling statements about steps to the future and simple initial activities to start? (Consider variables A, B and D again)
- Is there an overwhelming argument for change, accompanied by strong governance to manage the activities in the Governance Iteration? (Consider all the variables)
- Does the Governance Iteration have effective control, communications and support to sustain the change initiated in the earlier iterations? (Consider all the variables – is the vision still compelling; have more pain points been discovered; is the path still heading the right way; is there still enough momentum to overcome resistance?)
While there are many factors that contribute to the success or failure of transformation initiatives, the positive impact of planned interventions to build the case for change and the roadmap to achieve that change can make a significant difference to the outcome.