Business Architecture is never as critical as during times of great change. Great change shifts the very enterprise structures on which we usually rely to manage most other change. It can alter organizational structures, such as during mergers, acquisitions, joint ventures, and restructurings. It can alter process structures, such as during major system implementations, corporate initiatives, and regulatory imperatives. While times of sweeping change are unavoidable, the quality and speed with which we manage change determines our success. This guide describes a business architecture approach to enterprise change. This approach facilitates comprehensive, integrated change even under a compressed timeline.
Before beginning, obtain clear objectives, outcomes, and a capability model for your organization. A capability model is a critical tool which provides a framework for defining scope and analyzing impact. If you don’t have a capability map, start by reading William Ulrich’s article, “Capabilities & Value Streams: Business Architecture’s Essential Alliance”, for an overview. Then, start with an industry reference framework or create a list of agreed upon capabilities within your team. Some industries have readily available reference frameworks (e.g., eTOM, ACORD). For other industries, frameworks must be created in house or developed with a consulting firm (e.g., IBM offers this service, which they refer to as component business models).
Impact Assessment
The purpose of the assessment is to identify impacted capabilities and ensure all aspects and stakeholders are considered. Without this step, teams often suffer from “analysis paralysis” as they try to identify where to begin or they may start in random areas in their haste to start. Often, analysis is disjointed, especially for areas with multiple stakeholders or considerations. The assessment surfaces hidden impacts quickly, stimulates conversation, and identifies areas with multiple stakeholders.
During the impact assessment, all capabilities are reviewed so that nothing is missed and a holistic picture is presented from the outset. The initial assessment should take no more than a few hours. The activity is best done with a small team, preferably your steering committee or a program leader. If needed, follow-up can be done for items requiring specific expertise.
Using the objectives and outcomes as your guide, review each capability and determine if it is impacted. For this exercise, “impacted” means that a change will occur in the capability. This could be a change in process, frequency, location, etc… It does not include capabilities that are simply consumed to implement the change. For example, a program management capability may be utilized, but the program management capability itself will not change.
For all impacted capabilities, create a short statement describing the nature and severity of the impact. If known, list specific sub-capabilities as well. Then, identify associated stakeholders. Be careful not to only list stakeholders believed to be effected; any changes should have all capability stakeholders represented. If you wish to present more detail on stakeholder roles, information can be displayed in a RACI matrix.
The resulting deliverable is a list of impacted capabilities, each with an accompanying impact statement and stakeholder list. Decompose the capabilities to the appropriate level for further management. When little decomposition is done, there is less need to manage boundaries between items, however, further decomposition allows for smaller teams and the potential for concurrent work. Typically, a level two or three sub-capability is appropriate. Complete the impact assessment phase by conducting a stakeholder review. The assessment will facilitate validation of scope, stakeholders, project plans, and overall impact.
Difference Identification and Resolution
The purpose of this step is to identify differences and provide a framework for tracking them to resolution. For each of the impacted sub-capabilities, determine if value stream, workflow, or process models are available to support them. If not, the team will need to decide if they can proceed without them. In some cases, if a sub-capability has a small and simple change, this is acceptable. Typically, models that represent the flow of activities, without alternate paths, are required to facilitate the discussion effectively.
For difference identification, guide participants through the models and capture identified differences. For a merger, this could be differences between the current states of two companies. For an IT system implementation or process improvement, this could be differences between the desired and current state. If an item takes longer than about ten minutes, table it and follow up with a smaller, more focused discussion. A first pass, followed by more focused sessions, keeps the team from losing momentum. At the end of difference identification, you will have a list of differences for each sub-capability.
Next, the team can begin difference resolution. Identification and resolution should not be done in the same session. It slows progress, hinders communication and often concerns different stakeholders. Difference resolution could be as simple as obtaining sign-off for a suggestion or it could be complex, requiring a feasibility study or funding. Complex items should be modeled in more detail to ensure understanding. The differences can be managed using traditional project management tools, just be sure to maintain traceability to the sub-capabilities. At the conclusion of differences resolution, the models can be presented with the significant changes highlighted. This visual can be a powerful communication tool. The models also provide summary and context to underlying future state documentation, such as updated policies and procedures or statement of work agreements.
Collaboration with IT and OCM
Ideally, in a merger, IT requirements are done after difference resolution, so that IT can support the needs of the future state. However, it is usually impractical to postpone IT decisions. See Geoffrey Balmes’ article, “Business Architecture: Post Merger/Acquisition” for techniques on managing IT and business integration in parallel. Also, a business architecture approach will support your organization change management and training team well. See Geoffrey’s other article, “The Role of Business Architecture and Organizational Change Management in Business Transformation” for more information on how these two disciplines complement each other.
Successful Enterprise Change During great change, organizations struggle to remain focused on their objectives and navigate through the distractions and noise. Business architecture provides stability and direction, even if organizational and process structures are unstable. It enables teams to mobilize quickly, focusing on the most impacted capabilities, and provides a framework for defining the future in a structured way. A business architecture approach gives organizations the speed, focus, and alignment needed to successfully manage enterprise change.
