EA in Practice
Author: Mike Russell
The EA provides a roadmap for the organization to better align business processes, technology infrastructure and organizational structure to achieve business outcomes. It provides a foundation to improve how the organization provides services internally to its customers. However, this foundation cannot be established unless the organization can successful move from the enterprise systems it has today – the baseline – to the systems it needs – the objective. EA Transition encompasses this movement, and a well-planned and resourced transition, championed by all stakeholders, is the key to implementing the EA.
Transition isn’t a onetime event; rather it is an incremental, agile and well-planned process that is driven by business needs, not by the IT systems which underpin it. For example, implementing the latest and greatest cloud environment may sound good, but does it really help achieve business goals? While common for an organization to focus on the technology aspects of a transition, the culture of the organization plays an outsized role in any successful transition. The transition must also consider the time horizon the organization uses for planning; too long and the plan will likely be overcome by other events, and too short it may not provide the direction and stability required of the organization.
A successful transition starts with understanding and documenting the current state of the organization. Some questions that may help arrive at such an understanding follows:
- Business need: Determine what business goals the organization is not achieving and what changes are needed to achieve these goals. Are these goals aligned with the business strategy? As changes don’t always point to a technology solution, determining the metrics for a successful transition becomes essential.
- Organization culture: Does the organization’s culture support change at all levels? Has the need for change been accepted by all stakeholders? How should the transition be planned to take staff concerns for having a different organization, or different jobs into account?
- Business Processes: How well do the current processes help the organization achieve its business goals? How well are those processes understood, documented and implemented? Where have these processes been implemented?
- Current IT System State: Is the baseline system understood, and does the staff uses the system as intended? What work arounds, either process or technology, are used today and what problem are those work arounds solving? What technologies does the baseline state use, and what is the long-term viability of them?
- Organizational transition: Is a big change needed or a small change sufficient? Given changes to business processes and IT, does the organizational structure align to this? Are their redundancies or resources that could be put to better use? Who are the stakeholders? What are their equities?
- The External View: How do the entities outside of the organization, customers, suppliers, shareholders, feel about the current organization’s state? Are there issues that need to be addressed? What are their expectations?
Once these areas are understood, the organization has a foundation to begin transition planning. Areas to consider prior to starting the planning process include:
- Future Business State: What will the future state of the business look like when the transition is complete? How will business goals, organizational goals, and fiscal goals be aligned?
- Future Organization State: How will the business be organized in the future state? What changes are needed? What new or modified business processes or technologies may impact the organization? If some staff are no longer needed in their current role, what steps are needed to transition the staff to a new role?
- Future Business Processes: What processes needs to stay the same, what processes need to change, and what new processes need to be developed? Processes should produce something of value which directly relates to achieving a business goal. Often, identifying processes should start with what external entities expects the organization to produce; backing out supporting processes from there. This step is required prior to considering what the technical solutions are needed to support the processes.
- Future IT System State: What IT capabilities are critical to supporting future business processes? What current IT systems provide these capabilities, and what are the gaps? Are there technology innovations that provide a quantitative leap forward and conversely, what is a waste of resources? How will the business move from the current system to the future system while maintaining business continuity? How can the system gracefully degrade to the previous state if something goes wrong?
- Resourcing and Sustainment: Have transition costs been resourced? Is there a sound and justifiable budget for procurement and sustainment?
- The external view: How will external entities, e.g. Customers, suppliers, transition to the new processes and system? Are they expected to change their behavior? What do they expect out of the new system?
The transition planning process identifies incremental phases for developing and introducing improvements in structure, operations, or technology, for example, to migrate from the current architecture to the target one. This results in plans, schedules, and milestones to be executed in a defined timeframe with a specific set of resources. A critical element of transition planning is identifying and empowering a transition leader who is responsible for the overall planning effort, managing the project through the transition, and being a positive influence driving change within the organization.
Transition plans are unique to the organization, however, they all include common elements focusing on people, process, technology, data management and risk management. Often, transition plans within similar business domains, such as finance, manufacturing, and government have many common elements and form a reusable kernel for future transition plans. Common elements of transition plans include:
- Named Projects: Transitions don’t have to be accomplished all at once. Rather, breaking the effort down into related projects, e.g. back office, customer facing, data services, enables the organization to approach transition in a disciplined manner and accordingly, scale the transition effort to a size the organization can handle.
- Timelines: Each project has a defined beginning and an end and such data is aligned to the organization’s budget planning cycle. If the organization is a supplier, e.g. auto parts to an OEM, then the timeline should support continued production and support to the customer including their business cycles as well.
- Milestones: Transition efforts must have decision points where leaders judge the progress of each project and determine if they are ready to go to the next stage in the plan. Milestone reviews should include all stakeholders affected by that phase of the transition and include objective evidence for each decision point.
- Sequencing Projects: It often makes business sense to upgrade one part of the organization before another, for example, upgrading back end business systems before launching a customer-centric online ordering capability. Sequencing the foundational areas that support other business areas will add sustainment to the transition effort.
- Risk: What are the biggest challenges to achieving business objectives? What are 2nd, 3rd order effects and what possible unintended consequences may happen during transition? Risks should be proactivity managed for both the project and at the corporate organization level and reviewed during each milestone completion.
The following are examples of transition plans.
- US Department of Energy, CIO Office, Enterprise Architecture Transition Plan – April 2011
- US Department of Defense, CIO Office, Enterprise Architecture Transition Plan – February 2008
- US Department of State, USAID, Enterprise Architecture Transition Strategy – May 2008
- National Aeronautics and Space Administration, Enterprise Transition Plan, v3.2, May 2009
- Ross, J., Weill, P., Robertson, D., 2006 “Enterprise Architecture As Strategy: Creating a Foundation for Business Execution” Harvard Business Review Press, Brighton, MA.
- Weill, P., Ross J., 2004 “IT Governance: How Top Performers Manage IT Decision Rights for Superior Results” Harvard Business Review Press, Brighton, MA.
- Ulrich, W., McWhorter, N., 2010 “Business Architecture: The Art and Practice of Business Transformation” Meghan-Kiffer Press, Tampa, FL
EABOK® Knowledge Areas
Organizational Scope and Structure 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.