11.4.2 Business Analysis Scope
.1 Change Sponsor
Ideally, the sponsor of a business architecture initiative is a senior executive or business owner within the organization. However, the sponsor may also be a line-of-business owner.
.2 Change Targets
The following list identifies the possible primary change targets resulting from a business architecture analysis:
- business capabilities,
- business value streams,
- initiative plans,
- investment decisions, and
- portfolio decisions.
The following groups of people use business architecture to guide change within the organization:
- management at all levels of the organization,
- product or service owners,
- operational units,
- solution architects,
- project managers, and
- business analysts working in other contexts (for example, at the project level).
.3 Business Analyst Position
The goal of a business analyst working within the discipline of business architecture is to:
- understand the entire enterprise context and provide balanced insight into all the elements and their relationship across the enterprise, and
- provide a holistic, understandable view of all the specialties within the organization.
Business architecture provides a variety of models of the organization. These models, or blueprints, provide holistic insight into the organization that becomes the basis for strategic decisions by the leaders of the organization. To develop a business architecture, the business analyst must understand, assimilate, and align
a wide variety of specialties that are of strategic concern to the organization. To do this they require insight, skills, and knowledge from:
- business strategy and goals,
- conceptual business information,
- enterprise IT architecture,
- process architecture, and
- business performance and intelligence architecture.
Business architecture supports the strategic advisory and planning groups that guide and make decisions regarding change within the organization. It provides guidance and insights into how decisions align to the strategic goals of the organization, and ensures this alignment throughout the various transition states as the change moves towards its future state.
.4 Business Analysis Outcomes
Business architecture provides a broad scope and a holistic view for business analysis.
The general outcomes of business architecture include:
- the alignment of the organization to its strategy,
- the planning of change in the execution of strategy, and
- ensuring that as change is implemented, it continues to align to the strategy.
These business architecture outcomes provide context for requirements analysis, planning and prioritization, estimation, and high-level system design. This provides insight and alignment with strategy, stakeholder needs, and business capabilities. Architectural views and blueprints provide information that may have otherwise been based on assumptions, and minimize the risk of duplication of efforts in creating capabilities, systems, or information that already exist elsewhere in the enterprise.
The various models and blueprints provided by business architecture are its key deliverables. These include, but are not limited to:
- business capability maps,
- value stream maps,
- organization maps,
- business information concepts,
- high-level process architecture, and
- business motivation models.
11.4.3 Reference Models and Techniques
.1 Reference Models
Reference models are predefined architectural templates that provide one or more viewpoints for a particular industry or function that is commonly found across multiple sectors (for example, IT or finance).
Reference models are frequently considered the default architecture ontology for the industry or function. They provide a baseline architecture starting point that business architects can adapt to meet the needs of their organization.
The follow table lists some of the common reference models.
| Reference Model | Domain |
|---|---|
| Association for Cooperative Operations Research and Development (ACORD) | Insurance and Financial industries |
| Business Motivation Model (BMM) | Generic |
| Control Objectives for IT (COBIT) | IT governance and management |
| eTOM and FRAMEWORX | Communications sector |
| Federal Enterprise Architecture Service Reference Model (FEA SRM) | Government (developed for the U.S. Federal Government) |
| Information Technology Infrastructure Library (ITIL®) | IT service management |
| Process Classification Framework (PCF) | Multiple sectors including aerospace, defense, automotive, education, electric utilities, petroleum, pharmaceutical, and telecommunications |
| Supply Chain Operations Reference (SCOR) | Supply chain management |
| Value Reference Model (VRM) | Value change and network management |
Table 11.4.1: Business Architecture Reference Models
.2 Techniques
The following table lists techniques that are commonly used within the discipline of business architecture, and are not included in the Techniques section of the BABOK® Guide.
| Technique | Description |
|---|---|
| Archimate® | An open standard modelling language. |
| Business Motivation Model (BMM) | A formalization of the business motivation in terms of mission, vision, strategies, tactics, goals, objectives, policies, rules, and influencers. |
| Business Process Architecture | The modelling of the processes, including interface points, as a means of providing a holistic view of the processes that exist within an organization. |
| Capability Map | A hierarchical catalogue of business capabilities, or what the business does. Capabilities are categorized according to strategic, core, and supporting. |
| Customer Journey Map | A model that depicts the journey of a customer through various touch points and the various stakeholders within the service or organization. Customer journey maps are frequently used to analyze or design the user experience from multiple perspectives. |
| Enterprise Core Diagram | Models the integration and standardizations of the organization. |
| Information Map | A catalogue of the important business concepts (fundamental business entities) associated with the business capabilities and value delivery. This is typically developed in conjunction with the capability model and represents the common business vocabulary for the enterprise. It is not a data model but rather a taxonomy of the business. |
| Organizational Map | A model that shows the relationship of business units to each other, to external partners, and to capabilities and information. Unlike a typical organizational chart the map is focused on the interaction between units, not the structural hierarchy. |
| Project Portfolio Analysis | Used to model programs, projects, and portfolios to provide a holistic view of the initiatives of the organization. |
| Roadmap | Models the actions, dependencies, and responsibilities required for the organization to move from current state, through the transition states, to the future state. |
| Service-Oriented Analysis | Used to model analysis, design, and architecture of systems and software to provide a holistic view of the IT infrastructure of the organization. |
| The Open Group Architecture Framework (TOGAF®) | Provides a method for developing enterprise architecture. Phase B of the TOGAF Architecture Development Method (ADM) is focused on the development of business architecture. Organizations following TOGAF may choose to tailor Phase B to adopt the business architecture blueprints, techniques, and references described in the BABOK® Guide. |
| Value Mapping | Value mapping provides a holistic representation of the stream of activities required to deliver value. It is used to identify areas of potential improvement in an end–to–end process. Although there are several different types of value mapping, a value stream is often used in business architecture. |
| Zachman Framework | Provides an ontology of enterprise primitive concepts based on a matrix of six interrogatives (what, how, where, who, when, why) and six levels of abstraction (executive, business management, architect, engineer, technician, enterprise). Business architects may find that exploring the executive or business management perspectives across the different interrogatives provides clarity and insight. |
Table 11.4.2: Business Architecture Techniques
11.4.4 Underlying Competencies
In addition to the underlying competencies, business analysts working in the discipline of business architecture require:
- a high tolerance for ambiguity and uncertainty,
- the ability to put things into a broader context,
- the ability to transform requirements and context into a concept or design of a solution.
- the ability to suppress unnecessary detail to provide higher level views,
- the ability to think in long time frames over multiple years,
- the ability to deliver tactical outcomes (short term), which simultaneously provide immediate value and contribute to achieving the business strategy (long term),
- the ability to interact with people at the executive level,
- the ability to consider multiple scenarios or outcomes,
- the ability to lead and direct change in organizations, and
- a great deal of political acumen.
