Post 1 – How to Develop Enterprise Business Architecture
How can Enterprise Architecture teams develop enterprise business architectures? There are seven steps leveraging Gartner’s EA framework and process model that outline the EBA process.
- Define and Scope
Ensure a common agreement and understanding of what EBA is and the value and impact it provides and define the scope of iterations. This is necessary in order to achieve the long-term goals of EA as it outlines the progression path. This step is where the business sponsors are identified as well as critical constraints. Make sure these details are grounded in the defined business goals.
- Organize
Identify and organize the team to do the iteration work. Detail key lead and member roles. The leader should be from business and focus full-time on leading the EBA effort. He or she should also be on the EA core team. The will ensure alignment between the EBA project and EA framework.
Large organizations may find it beneficial to have three EBA teams. One team would consist of people with varying work experiences and from different businesses. The members of this team should allocate a large percentage of their time to this effort. The second team would be a virtual EBA team. They would provide support, advice, and review the EBA efforts. They may take on specific tasks within their domain expertise. Finally, the third team would be for project work and could consist of the core team, the extended second team, and other SME’s as needed.
- Future State
Define requirements, principles, and models for the future-state EA vision. This defines the long-term targets for change and how to move toward the target state. The first task is to define the context for EBA change. This involves understanding the current business and technology trends that impact the business and how the business reacts to these trends. The second task is to identify the business domains to focus on. This includes the anchor model for most EBA work, which all other work will be mapped to. This involves taking a high-level approach to understanding the entire enterprise and its environment.
Three different areas of this future state should be focused on: requirements, principles, models. Focus on the requirements first as this is the demand for change, then define the principles representing enterprise intent, and then model the future state. Requirements utilize the CRV work for the business change requirements (BCRs). Principles should be used to constrain long-term changeable process and organizational design. Models should be the critical business dimensions (people organization, financials, and process) based on future-state requirements and principles.
- Current State
Baseline the current state. The objective of this task is to prepare for the next step – identify the gaps between where you are today and where you want to be. These efforts should include the current-state anchor model, which focus on the high-level details to be created/gathered during further iterations, and the models, which model the critical business dimensions (people, organization, financials, and process) based on future-state requirements and principles. The difference between these models and the one from the future state is that the current state models should be done by the domain experts.
- Gap Analysis
At this point, the gaps between the current state and future state should be clear. The gaps need to be understood by the stakeholders. The EBA team now needs to work with the EA team to integrate the plans.
- Migration Plan
At this step, the EBA team highlights the projects or initiatives in order to close the gap. Roadmaps can serve as valuable guides during this step. These roadmaps can assist in the detailed effort that every viewpoint of the team must facilitate.
- Iterate and Refine
It’s important to remember EBA is a process and not just a project. As the organization evolves, the future state changes. The business, market, economic, social, and environment surrounding the business will also change, which is going to impact EBA efforts. Therefore, the requirements, principles, and models should be regularly revisited and revised.
References:
Burton, B., Robertson, B. (2008). How to Develop Enterprise Business Architecture. Gartner.
Post 2 – How Cardinal Health Leveraged Business Architecture
Leading organizations are finding business architecture a critical piece of EA in order to execute IT and business strategic plans. This is done to articulate strategy and create guidance towards the future-state vision. CEOs and CIOs believe a greater understanding and awareness of business issues is one of the challenges that needs to be addressed for expanding CIO importance.
At least 40% of organization report a lack of clearly defined, articulated, and communicated business strategy. To address this, EA should focus on utilizing business architecture to understand business strategy. Enterprise Business Architecture creates deliverables that guide people, process, and organizational change.
Cardinal Health is a healthcare service company that provides pharmaceutical and medical products. Cardinal Health realized it needed to plan and be prepared for new and changing business models for its future success, so, it created a business architecture team within its EA team.
Cardinal Health then developed business capability models, which provides the relationship between high-level strategic decisions and their impact on business and IT assets and how they need to change. These models encompassed the business capabilities needed in order to meet the business goals and strategies. The models were then applied to different business units which helped Cardinal Health identify the business capabilities of each unit. The capabilities were then classified as noncore, core-competitive or core-differentiating, which helped them understand how a capability supports the business strategy.
One of Cardinal Health’s goals through their initial capability model was to gain an understanding of where their business capabilities and supporting processes intersect across the different functional teams. This model proved beneficial to Cardinal Health as they were able to help educate the organization on what various teams were doing, how they overlapped, and how their resources were being wasted because of it. Within this capability model Cardinal Health also developed a ‘scoring’ feature which helps them identify the complexity of their capabilities; a useful piece of information when considering investment plans.
A current-state model was also developed in order to examine the level of integration and standardization across their enterprise. This helped them identify opportunities for business change and operational improvement. When compared to their future-state model they could then develop plans to improve operational efficiency without interfering with the future-state vision and strategy.
Through all of this Cardinal Health is seeing direct time and cost benefits to several of their projects. It has also provided immediate value by revealing opportunities to leverage shared services and consolidate organizations.
References:
Burton, B. (2013). Leading Companies Leverage Business Architecture to Integrate Business and IT Execution. Gartner.
Post 3 – Understanding Enterprise Business Architecture
Enterprise Business Architecture is not often a well-defined or understood part of Enterprise Architecture. In fact, in my organization, enterprise architecture alone isn’t well understood and is often confused with Enterprise Technical Architecture, even amongst many IT leaders. Many fail to understand that EA is a process of translating business vision into strategy in order for effective change to come about.
Enterprise Business Architecture (EBA) is part of the EA process. EBA defines the guidelines for the dimensions of the business to achieve the desired outcomes. IT and business have become very intertwined. Businesses are changing so rapidly, with new business models, globalization, new users’ skills and broadening ecosystems, traditional business operating models no longer apply. This is where EBA comes in. EBA describes how the core aspects of the business need to change or evolve in order to reach the desired future state. It answers the question “What are the requirements, principles, and models for the enterprise’s people, financials, processes and organizational structure?”. As a result, the EBA process should create artifacts that the business and IT people can use to evolve the business and define the current state for each of the aforementioned business dimensions
EBA is not, however, business process architecture. While a process view is critical to EBA, it is not the core component of EBA. EBA is also not business context and it is not business requirements architecture. EBA is derived from the business context and should demonstrate clear traceability of architectural decisions to the elements of the business strategy. For example, the four major dimensions of EBA – people, financials, process and organizational structure – are in the business context. The business context also creates the high-level functional model, which provides the foundation for the analysis that takes places in EBA.
In addition to understanding the characteristics of the EBA dimensions (people, financials, organizations, and processes) and reflecting on the requirements defined by the business context, it’s important to understand the internal and external factors that might impact these dimensions. Some of these factors might include: compliance, ecosystem, culture and politics, industry, region/location, innovation, behavior, and time. Understanding the EBA dimensions and what could impact them can help an EA team know how these factors can be used to move toward the future state, how they need to be changed, and how the factors need to be mitigated.
References:
Burton, B. (2008). Understand Enterprise Business Architecture to Realize You Future State. Gartner.
Recent Comments