Developing an EA
Author: Aaron Glassman, PhD
All organizations go through change. To understand how to effectively manage change and to succeed as an Enterprise Architect, one must use both an organizational behavior approach to change, as well as a technology approach to change. Since the effectiveness of change is often based on how people interact with the change process, having buy-in is of the utmost importance to the Enterprise Architect. Consequently, it is imperative to understand organizational behavior. Further, at the enterprise architecture level, change will likely involve many facets of the organization and a variety of actors all of whom will need to be properly engaged.
Kurt Lewin based his change model on physics and the changing states of an organization (Levasseur, 2001). His model describes states the organization must undergo, for example, unfreeze, change, and refreeze, similar to how one would move a block of ice from pole to pole. An organization most likely goes through a similar process: preparing for a change, adapting to change, and solidifying the change through continuous reinforcement. This allows people and processes to embrace the change within the organization. This simple model is the basis of more complex models such as Kotter’s model (Appelbaum et al., 2012). John Kotter amplified Lewin’s model and suggested 8-steps where one begins generating a sense of urgency and ends with making the change persist. To read more about Lewin and Kotter’s models, see the additional readings section.
To have a buy-in, a substantial amount of effort will need to be invested in communication and training on the anticipated change. Managing resistance to change is a necessary skill. There are different types of resistance of which each type manifests itself in covert and overt ways. There is individual resistance that is rational (e.g., fear of losing one’s job) and there is individual resistance that is less rational (e.g., fear of failure). The architect must understand that rational resistance can often be overcome with clear and concise communication. Less rational forms of resistance may not be overcome or will require individualized attention. The Enterprise Architect acts as a Change Manager discovering various needs of the change process. Overt resistance (e.g., gossip) can be discovered through change champions within the organization and properly managed with active communication. Change champions are people who are in close communication with the Enterprise Architect and act as mediators to help facilitate change. They are aware of the both the accumulated positive and negative feedback within the organization and can tailor the Enterprise Architect’s message to the needs of the listener. While the literature suggests that resistance to change is inherently negative, this is not always the case. There may be times when change resistance serves as an organizational smoke detector that the change is in fact bad, needs revisions, or will have unintended consequences. Therefore, it is important for the Enterprise Architect to be open minded and learn from those who resist change and work through Change champions.
Once the organization is primed for change, there are many models of Change management that incorporate the involved people, processes and technologies. For example, the Information Technology Infrastructure Library (ITIL) has dedicated sections on Change and Change management. ISO 20000 uses the Plan-Do-Check-Act (PDCA) model as part of the Service Management Standard. If placed side-by-side, the ITIL models and ISO 20000 models overlap in some areas but also have gaps. No single model is perfect for every scenario. The Information Systems Audit and Control Association (ISACA) uses the COBIT framework (Control Objectives for Information and Related Technologies) as part of a larger IT framework that also includes elements of change and Change management (COBIT 5: A Business Framework for the Governance and Management of Enterprise IT, n.d.).
Within the Change process are several other concepts the Enterprise Architect should be familiar with, for example, configuration control and the organizational structure within which the Change process is administered, for example, Change Advisory Board. While many are familiar with version control, usually referring to software, configuration control is the process of ensuring that only what is contained in the approved Change package is changed; no more or no less. In many organizations, Change Requests (CR’s) or Requests for Change (RFC) are created when a need for change is identified. Then, a CR change analysis is performed to determine the costs, benefits, etc. This is followed by a formal Change proposal submitted to a Change Advisory Board that evaluates these proposals through voting. Once approved, the change (especially IT changes) are loaded into a Configuration Management Database (CMDB) and the changes are pushed across the organization. CMDB provides configuration control to track if the approved changes have been acted upon.
Change is something that must be done regularly to remain relevant, optimized, and maintain a strategic or competitive advantage. The Enterprise Architect adds value to the organization by mastering the holistic change process and leading the organization through change as a Change leader. The Change leader serves as the figure head of the change process and often elects change champions in each business unit. This distributed approach helps push the change message to all corners of the organization as well as collect feedback from other change participations. While the literature suggests between 50%-80% of change efforts are not fully successful, a skilled Enterprise Architect will better effect change. This is because the Enterprise Architect uses a two-layered change approach, the organizational behavior approach in addition to the use of technology change models. Change is necessary for success and those who change better will do better, remain agile, and remain more relevant than those who don’t. Change management has always been and will continue to be a challenge for the Enterprise Architect. However, there is no greater satisfaction than moving an organization forward through a positive change.
- Appelbaum, S. H., Habashy, S., Malo, J., & Shafiq, H. (2012). Back to the future: Revisiting Kotter’s 1996 change model. The Journal of Management Development, 31(8), 764-782.
- COBIT 2019 Implementation Guide: Implementing and Optimizing an Information and Technology Governance Solution
- ISO – International Organization for Standardization. (2016, January 13).
- ITIL® – IT Service Management. (n.d.).
- Levasseur, R. E. (2001). People skills: Change management tools – Lewin’s change model. Interfaces, 31(4), 71-73.
EABOK® Knowledge Areas
Organizational Scope and Structure of EA
Foundations of EA
Developing an EA
- Business Requirements and Value Proposition
- Methodologies and Processes
- Architecture Frameworks
- Data and Information Management
- Project Management
- Change Management
- Testing and Evaluation
- Modeling and Simulation
- Role of Reference Architectures
- How to Build a Reference Architecture
- Coordinating the Creation of a Reference Architecture
Management of EA
EA in Practice
Perspectives on EA
EABOK is an evolving knowledge base and more information will be released as available.
In addition to the EABOK Board members, the content is also contributed by the following MITRE employees:
- Carla Kendrick
- Brenda Yu
- Eddie Wang
- Rose Tykinski
- Wakar Khan
- Mike Russell
This website is managed by the EABOK Consortium and hosted by MITRE to enable stakeholder collaboration within the EA community.
EABOK and the EABOK logo are trademarks of MITRE and are used by The EABOK Consortium with permission.
All other trademarks are the property of their respective owners. All rights reserved.