11. Perspectives
11.4 The Business Architecture Perspective
BABOK® Guide
The Business Architecture Perspective highlights the unique characteristics of business analysis when practiced in the context of business architecture.
Business architecture models the enterprise in order to show how strategic concerns of key stakeholders are met and to support ongoing business transformation efforts.
Business architecture provides architectural descriptions and views, referred to as blueprints, to provide a common understanding of the organization for the purpose of aligning strategic objectives with tactical demands. The discipline of business architecture applies analytical thinking and architectural principles to the enterprise level. The solutions may include changes in the business model, operating model, organizational structure, or drive other initiatives.
Business architecture follows certain fundamental architectural principles:
- Scope: the scope of business architecture is the entire enterprise. It is not a single project, initiative, process, or piece of information. It puts projects, processes, and information into the larger business context to provide an understanding of interactions, integration opportunities, redundancies, and inconsistencies.
- Separation of concerns: business architecture separates concerns within its context. It specifically separates what the business does from:
- the information the business uses,
- how the business is performed,
- who does it and where in the enterprise it is done,
- when it is done,
- why it is done, and
- how well it is done
Once the independent concerns are identified, they can be grouped in specific combinations or mappings, which can be used to analyze targeted business issues.
- Scenario driven: there are many different questions that a business tries to answer to provide the blueprint for alignment. Each of these different questions or business scenarios requires a different set of blueprints containing a different set of information and relationships, with different types of outcomes and measures to determine success.
- Knowledge based: while the primary goal of business architecture is to answer these business questions, a secondary but important goal is to collect and catalogue the different architectural components (what, how, who, why, etc.) and their relationships in a knowledge base so they can quickly and easily be used to help answer the next business question that comes up. The knowledge base is often managed in a formal architectural repository.
11.4.1 Change Scope
.1 Breadth of Change
Business architecture may be performed:
- across the enterprise as a whole,
- across a single line of business within the enterprise (defining the architecture of one of the enterprise's business models), or
- across a single functional division.
Business architecture activities are generally performed with a view of the entire enterprise in mind, but may also be performed for an autonomous business unit within the enterprise. A broad scope is required to manage consistency and integration at the enterprise level. For example, business architecture can clarify a situation where the same business capability is implemented by multiple different processes and multiple different organizations using different information models. Given the clarity that comes from an enterprise scope, the business can then determine if this structure is the best way to align with strategic objectives.
.2 Depth of Change
A business architecture effort may focus on the executive level of the enterprise to support strategic decision making, or on the management level to support the execution of initiatives.
While business architecture provides important context, it does not usually operate at the operational decision or process level; instead, it assesses processes at the level of the value stream.
.3 Value and Solutions Delivered
Business architecture, using the principle of separation of concerns, develops models that decompose the business system, solution, or organization into individual elements with specific functions and shows the interactions between them.
The elements of business architecture models include:
- capabilities,
- value,
- processes,
- information and data,
- organization,
- reporting and management,
- stakeholders,
- security strategies, and
- outcomes.
Architecture models enable organizations to see the big picture of the domain that is under analysis. They provide insights into the important elements of the organization or software system and how they fit together, and highlight the critical components or capabilities.
The insights provided by business architecture help keep systems and operations functioning in a coherent and useful manner, and add clarity to business decisions. When change is being considered, the architecture provides details on the elements that are most relevant for the purposes of the change, allowing for prioritization and resource allocation. Because an architectural model also shows how the parts are related, it can be used to provide impact analysis to tell what other elements of the system or the business might be affected by the change.
The architecture itself can be used as a tool to help identify needed changes. The performance metrics for each element of the architecture can be monitored and assessed to identify when an element is under-performing. The importance of each element can be compared with the performance of the organization or system as a whole. This assists decision makers when considering where investment is needed and how to prioritize those decisions.
The function of business architecture is to facilitate coordinated and synchronized action across the organization by aligning action with the organization's vision, goals, and strategy. The architectural models created in this process are the tools used to clarify, unify, and provide understanding of the intent of the vision, goals, and strategy, and to ensure that resources are focused and applied to the elements of the organization that align with and support this direction.
Business architecture provides a blueprint that management can use to plan and execute strategies from both information technology (IT) and non-IT perspectives. Business architecture is used by organizations to guide:
- strategic planning,
- business remodelling,
- organization redesign,
- performance measurement and other transformation initiatives to improve customer retention,
- streamlining business operations,
- cost reduction,
- the formalization of institutional knowledge, and
- the creation of a vehicle for businesses to communicate and deploy their business vision.
.4 Delivery Approach
Business architecture creates a planning framework that provides clarity and insight into the organization and assists decision makers in identifying required changes. The architectural blueprints provided by business architecture provide an insight and understanding of how well the organization aligns to its strategy. This insight is the trigger for change or other planning activities.
For each blueprint provided, business architecture may define:
- current state,
- future state, and
- one or more transition states that are used to transition to the future state. Business architects require a view of the entire organization.
In general, they may report directly to a member of senior leadership. Business architects require a broad understanding of the organization, including its:
- environment and industry trends,
- structure and reporting relationships,
- value streams,
- capabilities,
- processes,
- information and data stores, and
- how all these elements align to support the strategy of the organization.
Business architects play an important role in communicating and innovating for the strategy of the organization. They utilize blueprints, models, and insights provided by business architecture to continually advocate for the strategy of the organization and address individual stakeholder needs within the scope of the organization's goals.
There are several factors central to a successful business architecture:
- support of the executive business leadership team,
- integration with clear and effective governance processes, including organizational decision-making authorities (for example, for investments, initiatives, and infrastructure decisions),
- integration with ongoing initiatives, (this might include participation in steering committees or other similar advisory groups), and
- access to senior leadership, departmental managers, product owners, solution architects, project business analysts, and project managers.
.5 Major Assumptions
To make business architecture useful to the organization, business analysts require:
- a view of the entire organization that is under analysis,
- full support from the senior leadership,
- participation of business owners and subject matter experts (SMEs),
- an organizational strategy to be in place, and
- a business imperative to be addressed.
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.
Table 11.4.1: Business Architecture 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, defence, 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 |
.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.
Table 11.4.2: Business Architecture Techniques
|
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. |
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.
11.4.5 Impact on Knowledge Areas
This section explains how specific business analysis practices within business architecture are mapped to business analysis tasks and practices as defined by the BABOK® Guide. This section describes how each knowledge area is applied or modified within the business architecture discipline.
Each knowledge area lists techniques relevant to a business architecture perspective. BABOK® Guide techniques are found in the Techniques chapter of the BABOK® Guide. Other business analysis techniques are not found in the Techniques chapter of the BABOK® Guide but are considered to be particularly useful to business analysts working in the discipline of business architecture. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.
.1 Business Analysis Planning and Monitoring
During Business Analysis Planning and Monitoring, the discipline of business architecture requires business analysts to understand the organization's:
- strategy and direction,
- operating model and value proposition,
- current business and operational capabilities,
- stakeholders and their points of engagement,
- plans for growth, governance, and planning processes,
- culture and environment, and
- capacity for change.
Once these elements are understood the business analyst can then develop an understanding of which architectural viewpoints are relevant to the analysis.
Governance planning and monitoring activities primarily focus on:
- selecting which projects or initiatives will provide the most benefit in achieving the business strategies and outcomes, and
- determining which frameworks or models exist or are utilized within the organization.
BABOK® Guide Techniques
- Acceptance and Evaluation Criteria
- Brainstorming
- Business Capability Analysis
- Decision Analysis
- Estimation
- Functional Decomposition
- Interviews
- Item Tracking
- Metrics and Key Performance Indicators (KPIs)
- Non-Functional Requirements Analysis
- Organizational Modelling
- Process Modelling
- Reviews
- Risk Analysis and Management
- Roles and Permissions Matrix
- Root Cause Analysis
- Scope Modelling
- Stakeholder List, Map, or Personas
- Survey or Questionnaire
- Use Cases and Scenarios
- User Stories
Other Business Analysis Techniques
- Business Process Architecture
- Capability Map
- Project Portfolio Analysis
- Service-oriented Analysis
.2 Elicitation and Collaboration
Business analysts working in the discipline of business architecture typically deal with a great deal of ambiguity and uncertainty. When undertaking Elicitation and Collaboration tasks, business analysts consider changes in organizational direction based on external and internal forces and changes in marketplace environment. The types of changes can frequently be predicted, but external market pressures frequently make the pace of the change unpredictable.
As business architecture requires many inputs from across the organization, access to (and the availability of) stakeholders is critical to success. Business analysts elicit inputs such as strategy, value, existing architectures, and performance metrics.
Advocacy for the organization's strategy is central to the communication strategy of business architects. As members of various steering committees and advisory groups, business architects utilize formal communication channels within projects, initiatives, and operational groups to communicate the organization's strategy, explain the organizational context, and advocate alignment with the strategy.
Ensuring stakeholders understand and support the organization's strategy is an essential function within the discipline of business architecture. Business architects may impose scope and constraints on a project or initiative as a means to ensure the activity aligns to the organization's strategy, which may be viewed unfavourably. It is the role of the business architect to bridge the needs and desires of individual stakeholders, projects, and operational groups with the context and understanding of the organizational goals and strategy. The business architect's goal is to optimize the enterprise's goals and strategy, and discourage activities that achieve a narrow goal at the cost of sub-optimizing the entire objective. This is an exercise in both elicitation and in collaboration.
The business architect acquires a deep understanding of the strategy, drivers, motivations, and aspirations of the organization and those of the stakeholders. Once this level of understanding is achieved, the business architect collaborates with all levels of the organization including senior leadership, managers, the project management office (PMO), product owners, project managers, various business analysts, solution architects, and IT personnel to bridge gaps in understanding and communicating the importance of alignment with organizational strategy. Facilitating effective collaboration requires that the business architect is able to understand the wide variety of perspectives and contexts from which each stakeholder operates. The business architect must also be able to communicate with each of these stakeholders in a language that is mutually understood and supported.
BABOK® Guide Techniques
- Brainstorming
- Document Analysis
- Focus Groups
- Functional Decomposition
- Glossary
- Interface Analysis
- Interviews
- Item Tracking
- Observation
- Prototyping
- Stakeholder List, Map, or Personas
- Survey or Questionnaire
- Workshops
Other Business Analysis Techniques
- none
.3 Requirements Life Cycle Management
It is essential that business analysts working in the discipline of business architecture have executive support and agreement of the work to be undertaken. An architecture review board comprised of senior executives with decision-making powers can review and assess changes to the business architecture. This group will often also engage in portfolio management by making decisions regarding the investment in and prioritization of change based on their impact to business outcomes and strategy.
Business analysts working in the discipline of business architecture understand how projects impact the business architecture on an ongoing basis and work to continually expand, correct, or improve the business architecture. They also identify possible emerging changes in both internal and external situations (including market conditions), and decide on how to incorporate these changes into the business architecture of the organization.
BABOK® Guide Techniques
- Balanced Scorecard
- Benchmarking and Market Analysis
- Business Capability Analysis
- Collaborative Games
- Data Modelling
- Decision Analysis
- Estimation
- Interface Analysis
- Item Tracking
- Lessons Learned
- Metrics and Key Performance Indicators (KPIs)
- Organizational Modelling
- Process Analysis
- Process Modelling
- Reviews
- Risk Analysis and Management
- Roles and Permissions Matrix
- Root Cause Analysis
- Stakeholder List, Map, or Personas
- SWOT Analysis
Other Business Analysis Techniques
- Archimate®
- Business Process Architecture
- Business Value Modelling
- Capability Map
- Enterprise Core Diagram
- Project Portfolio Analysis
- Roadmap
- Service-oriented Analysis
- Value Mapping
.4 Strategy Analysis
Business architecture can play a significant role in strategy analysis. It provides architectural views into the current state of the organization and helps to define both the future state and the transition states required to achieve the future state.
Business architects develop roadmaps based on the organization's change strategy. Clearly defined transition states help ensure that the organization continues to deliver value and remain competitive throughout all the phases of the change. To keep competitive, the business must analyze such factors as:
- market conditions,
- which markets to move into,
- how the organization will compete in the transition state, and
- how to best position the organization's brand proposition.
Business architecture provides the enterprise context and architectural views that allow an understanding of the enterprise so these questions can be analyzed in the context of cost, opportunity, and effort.
BABOK® Guide Techniques
- Balanced Scorecard
- Benchmarking and Market Analysis
- Brainstorming
- Business Capability Analysis
- Business Model Canvas
- Business Rules Analysis
- Collaborative Games
- Data Modelling
- Document Analysis
- Estimation
- Focus Groups
- Glossary
- Metrics and Key Performance Indicators (KPIs)
- Organizational Modelling
- Reviews
- Risk Analysis and Management
- Stakeholder List, Map, or Personas
- Survey or Questionnaire
- SWOT Analysis
- Workshops
Other Business Analysis Techniques
- Archimate®
- Business Process Architecture
- Capability Map
- Customer Journey Map
- Enterprise Core Diagram
- Project Portfolio Analysis
- Roadmap
- Service-oriented Analysis
- Strategy Map
- Value Mapping
.5 Requirements Analysis and Design Definition
Business architecture provides individual architectural views into the organization through a variety of models that are selected for the stakeholders utilizing the view. These architectural views can be provided by capability and value maps, organizational maps, and information and business process models. Business analysts working in the discipline of business architecture employ expertise, judgment, and experience when deciding what is (and what is not) important to model. Models are intended to provide context and information that result in better requirements analysis and design.
The architectural context and the ability to reference readily available architectural views provides information that would have otherwise been based on assumptions that the analyst must make because no other information was available. By providing this information, business architecture minimizes the risk of duplication of efforts in creating capabilities, systems, or information that already exist elsewhere in the enterprise.
Design is done in conjunction with understanding needs and requirements. Business architecture provides the context to analyze the strategic alignment of proposed changes and the effects those changes have upon each other. Business architects synthesize knowledge and insights from multiple architectural views to determine if proposed changes work towards or conflict with the organization's goals.
Business architecture attempts to ensure that the enterprise as a whole continues to deliver value to stakeholders both during normal operations and during change. Business analysts working in the discipline of business architecture focus on the value provided by the organization from a holistic view. They attempt to avoid local optimization where effort and resources are put into a single process or system improvement which does not align with the strategy and garners no meaningful impact to the enterprise as a whole—or worse, sub-optimizes the whole.
BABOK® Guide Techniques
- Acceptance and Evaluation Criteria
- Backlog Management
- Balanced Scorecard
- Benchmarking and Market Analysis
- Brainstorming
- Business Capability Analysis
- Business Model Canvas
- Business Rules Analysis
- Collaborative Games
- Data Dictionary
- Data Flow Diagrams
- Data Modelling
- Decision Analysis
- Document Analysis
- Estimation
- Focus Groups
- Functional Decomposition
- Glossary
- Interface Analysis
- Item Tracking
- Lessons Learned
- Metrics and Key Performance Indicators (KPIs)
- Non-Functional Requirements Analysis
- Observation
- Organizational Modelling
- Process Analysis
- Process Modelling
- Prototyping
- Reviews
- Risk Analysis and Management
- Roles and Permissions Matrix
- Root Cause Analysis
- Scope Modelling
- Sequence Diagrams
- Stakeholder List, Map, or Personas
- State Modelling
- Survey or Questionnaire
- SWOT Analysis
- Use Cases and Scenarios
- User Stories
- Vendor Assessment
- Workshops
Other Business Analysis Techniques
- Archimate®
- Business Process Architecture
- Capability Map
- Customer Journey Map
- Enterprise Core Diagram
- Project Portfolio Analysis
- Roadmap
- Service-oriented Analysis
- Value Mapping
.6 Solution Evaluation
Business architecture asks fundamental questions about the business, including the important question of how well the business is performing.
To answer this question, several other questions must be answered:
- What outcomes are the business, a particular initiative, or component expecting to achieve?
- How can those outcomes be measured in terms of SMART (Specific, Measurable, Achievable, Relevant, Time-bounded) objectives?
- What information is needed to measure those objectives?
- How do processes, services, initiatives, etc. need to be instrumented to collect that information?
- How is the performance information best presented in terms of reports, ad hoc queries, dashboards, etc.?
- How do we use this information to make investment decisions in the future?
For example, at a more detailed level, an important part of capability definition and process architecture is to identify the specific performance characteristics and outcome that those capabilities or processes are expected to achieve. The actual measurement is rarely conducted by business analysts. It is usually done by business owners, operational, or information technology managers.
Business analysts working in the discipline of business architecture analyze the results of measurements and factor these results into subsequent planning.
BABOK® Guide Techniques
- Balanced Scorecard
- Benchmarking and Market Analysis
- Brainstorming
- Business Capability Analysis
- Collaborative Games
- Focus Groups
- Item Tracking
- Lessons Learned
- Metrics and Key Performance Indicators (KPIs)
- Observation
- Organizational Modelling
- Process Analysis
- Process Modelling
- Risk Analysis and Management
- Roles and Permissions Matrix
- Root Cause Analysis
- Stakeholder List, Map, or Personas
- Survey or Questionnaire
- SWOT Analysis
Other Business Analysis Techniques
- Business Motivation Modelling
- Business Process Architecture
- Capability Map
- Customer Journey Map
- Service-oriented Analysis
- Value Mapping