Articulating the Architecture Vision

The SAP Enterprise Architecture Methodology is a methodology aligned with the TOGAF standard and tailored to the SAP Reference Architecture.

The SAP Enterprise Architecture Methodology has evolved from the formerly known Industry Reference Architecture (IndRA) framework, an SAP internal project.

It provides a comprehensive approach used by SAP and customers to systematically map IT Solutions to business needs. Internally, SAP uses the framework to build enterprise architecture content. Customers apply the framework to define their desired future business scope and desired target architecture.

The recommendation for our customers is to follow a phased approach. It can be used by any enterprise to find the IT Solutions that meet their business need. Same holds true also for SAP's own IT.

This approach is in line with the TOGAF® standard from The Open Group, a proven EA methodology used by the world's leading organizations to improve their business efficiency.

The TOGAF Architecture Development Method (ADM) cycle is the result of continuous contributions from a large number of architecture practitioners. It describes a method for developing and managing the lifecycle of an Enterprise Architecture.

The ADM is highly iterative: Within phases, between phase, between cycles, stakeholder reviews after the phases.

The SAP Enterprise Architecture Methodology - Metro Map outlines the following:

• The full set of architecture artifacts (recommended and optional)
• Input from the SAP Reference Architecture to define the target architecture both in terms of business and IT domains
• References to existing architecture work products such as principles, standards and guidelines as well as existing baseline business and solution architectures

The selection of artifacts again very much depends on the nature of the architecture project and the stakeholders involved. These should be selected for the sake of the stakeholders (not for the sake of architecture).

Take note that there will be iterations within and across the individual phases (the intention of the visualization is not to give the impression of a waterfall based approach).

The objectives of Architecture Vision are as follows:

1. Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture.
2. Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.

As stated in the first objective, this phase involves the use of a Business Architecture perspective and associated approaches to enhance the identification of required changes to business capabilities in light of analyzing business value issues.

Various sources of information are taken into account to retrieve relevant details.

Principles, Standards and Guidelines, as well as Baseline (as-is) Business and Solution Architectures, which already exist are taken into consideration.

A Stakeholder Map is an important artifact that helps you to identify the needs and notions of the key players in an architecture engagement.

The purpose of stakeholder management is to ensure support for your architecture and improve its quality by addressing the concerns of your stakeholders. You use stakeholder-specific architecture views to adequately communicate your architecture.

Stakeholder management enables the following:

• Identify stakeholders

  Clear identification of stakeholders are key to securing architectural success

• Analyze stakeholders

  An analysis of stakeholders is the essential input into stakeholder management

  Understand how the stakeholders are affected by the Enterprise Architecture

• Manage stakeholder

  Target the stakeholders by a clear communication strategy

  Manage the interests, concerns, and requirements per stakeholder group

Analysis of Stakeholders is the essential input into Stakeholder Management:

• Stakeholder identification is a key factor in prioritizing requirements and communication
• Personal and professional interest may be conflicting
• A single person can have multiple stakeholder roles
• Analysis of informal and indirect relationships needed also
• Do not speculate about individual stakeholder influence or importance

This graph combines the template and example of a stakeholder map. The importance of the stakeholder concern is classified in terms of the engagement and respective artifacts are identified to address the concerns and to provide transparency.

Stakeholders who have been identified as having a high level of influencing power and a positive attitude to the project, are also likely to be critical to the successful adoption of the change project. These stakeholder(s) can directly influence the scope of the project and the progress to date, they can also highly influence other people's views on the project. These stakeholder's should be used as much as possible to help promote the project to other employees and to ensure that a "positive voice" is being heard.

Stakeholders who have low influence but a positive attitude can be used to help promote the project and to gain support from other employees.

Stakeholders with a low influence and a negative attitude should not be forgotten, although their impact on the overall success of the project is not critical, these stakeholders should still be kept informed of the project progress. However, stakeholders with a more positive attitude and higher influence may also be able to convert these stakeholders to have a more positive attitude through regular communication and information to ensure that these stakeholders understand the project and feel involved.

A stakeholder who has been identified as having a high level of influencing power and a negative attitude to the project, are also likely to be critical to the successful adoption of the change project. However, as these stakeholder(s) can directly influence the scope of the project and the progress to date, and can highly influence other people's views on the project, particular attention needs to be paid to these stakeholders to bring them on board with the project and ensure that the project does not face significant resistance. It may be that these stakeholders do not fully understand the project or do not feel suitably involved in which case these issues need to be addressed to prevent negative attitude spreading to other influencing stakeholders and employees.

The Business Strategy Map is a powerful artifact that helps you to retrieve holistic insights into the vision, goals, and value drivers of a firm.

The purpose of the strategy map is to provide a cross-organizational reference of how your company meets its strategic priorities in practical terms through goals, value drivers, and initiatives. It provides strategy insights for your architecture work.

The benefits of the Strategy Map are outlined here:

• It helps you to translate business strategy into business architecture by linking the strategy map to business capabilities.
• It helps you to gain visibility of business readiness for adoption of new / improved business changes.
• It helps you to align Business and IT priorities by ensuring the business critical priorities are addressed in the IT Architecture and roadmap design.

The Business Strategy Map of the SAP Enterprise Architecture Framework is following a slightly different definition then defined by the TOGAF Standard (Driver, Goal, Objective).

1. Strategic Priority is used instead of Driver
2. Value Driver is used instead of Objective

Furthermore, Business Capabilities are linked to Value Drivers (the Business Capabilities might be identified during the definition of the Business Architecture).

Initiatives will implement/mature the required Business Capabilities. Initiatives can either be projects or programs and will deliver one or more outcomes (key results) over time.

Business Strategy Assessment is a core enterprise architecture skill to gain a holistic understanding of external and internal drivers, identify areas of transformation, opportunity and risks.

Business Strategy Assessments can be conducted in the form of surveys or interviews. Questions to the stakeholder need to be tailored accordingly.

Depending on the stakeholder a subset of key questions will be used to gain further insights.

The following figure provides you with an example of the Business Strategy Map for Sustainability.

The Business Model Canvas is a key artifact to capture existing and/or new business model on a one-pager.

The purpose of a business context diagram is to provide a high-level overview of how a business interacts with its external environment. It shows the different entities that interact with the business, as well as the flows of information and materials between those entities and the business.

Benefits of the Business Context Diagram:

• Helps to understand any web of relationships that generates both tangible and intangible value through complex dynamic exchanges between two or more individuals, groups or organizations
• The model promotes strategic clarity by visually distinguishing and prioritizing the business activities most critical to value creation, enabling stakeholders to focus on optimizing key processes and relationships.
• The diagram facilitates the identification of potential innovation opportunities by highlighting areas where information and material flows intersect, which can lead to the development of new products, services, or processes that enhance the business's competitive edge.

The following figure provides you with a step-by-step approach to the Business Context Diagram.

The Business Context Diagram enables the following:

1. Define organizational entities that is capable of performing behavior

   Identify and define business actors (organization, group, person)

2. Identify and define various business flows between actors, for example:

   • Payment flow
   • Product flow
   • Information flow

3. Identify and define structural dependencies business actors, for example:

   Contract association

This figure provides you with an example of "software business sales" in the context of our work on Business Context Diagram.

The Business Model Canvas is a key artifact to capture existing and/or new business model on a one-pager.

The development of a business model is initially performed at a relatively abstract or conceptual level. Maintenance of this summary view encourages and enables the creative thought process that underpins innovation. It also helps to communicate key ideas about the vision and strategy to a broad audience, at a level that is appropriate to generate cross-disciplinary discussion and promote buy-in.

Usually, there is sufficient information available in a draft business model for interested parties to explore overall feasibility and support strategic decision-making. On the other hand, this sketch view does not normally contain sufficient information to perform a risk assessment or to develop a plan to execute the agreed strategy.

Business leaders can obtain powerful leverage using business model artifacts in conjunction with other strategic planning artifacts, Business Architecture views, and organizational change methods to accelerate strategic execution and alignment.

The business model "forces" managers to think rigorously about their business.

A business model's great strength as a planning tool is that it focuses attention on how all the elements of the system fit into a working whole.

Business model artifacts highlight the critical relationships between the various elements that constitute a business in ways that:

• Are not fully covered by other approaches or techniques and, therefore, contribute to a more complete examination of costs, revenues, and other business perspectives

• Are covered by other approaches or techniques - but through a different method or viewpoint - in which case business modeling helps cross-check and correlate other points of information and assumptions

The benefits of use of business models include:

• Improved communication: Improved communication among business executives, by providing a common perspective for the organization's core business logic, can help executives to "get on the same page"
• Providing a Common Perspective: Having a common perspective, structure, and understanding allows for more effective business design6 and enables the successful deployment of an organization's target-state Enterprise Architecture

In summary, business models support clarity of thought using a different point of view from the one provided by traditional strategic planning methods and can foster the greater level of thinking required for innovation.

Outline the existing and intended business model(s):

• Use the Business Model Canvas to visualize and capture current and intended business models
• Leverage business model patterns library to fast track documentation of existing and future business model
• Link to Business Model Pattern reference library
• Tailoring of business model patterns to your business context (value proposition, customer segments, and so on)
• Shortlisting of business models in scope for architecture work

With the help of the business modeling technique existing as well as future business models are getting identified, clustered, and documented. Business models patterns are an accelerator for innovation.

The Business Model Canvas is an elegant, one-page representation of a business model that enables the following:

• It provides a shared perspective and understanding of an organization's business model(s).
• It enables informed discussion among business executives on business issues and necessary change.
• It fosters a design-oriented approach to identify what a business can do differently to maximize value exchanges between market participants.
• It enables collaboration and co-creation of current-state and future state business model options.
• It focuses on the key revenue and cost components supporting an agreed value proposition for a particular customer segment.

The Business Model Canvas is designed to be a hands-on tool for understanding how a business handles its key determinants of revenue and cost, the value proposition it uses to go to market, the customers it serves, and the resources it needs to execute.

The Business Model Canvas is the de-facto industry standard to sketch and describe a business model. The different dimensions outline a business model from a value creation, value delivery, and value capture perspective.

The Sustainable Business Model Canvas is an evolution of the "traditional" Business Model Canvas which considers the dimensions of "Eco-Social Costs" and "Eco-Social-Benefits". This version is very much in alignment with SAP vision of the intelligent, sustainable enterprise.

The statement of architecture work is the contract to start / commence any architecture activities.

The Statement of Architecture Work is a deliverable that defines the scope of your architectural work, including roles and responsibilities supporting your architecture definition as well as acceptance criteria.

The Statement of Architecture Work is a deliverable that defines the scope of your architectural work, including roles and responsibilities supporting your architecture definition as well as acceptance criteria.

TOGAF provides you with a well-structured template for the Statement of Architecture Work.

With the insights gained throughout the Business Strategy Assessment and Business Modeling the scope and context of the architecture will be further detailed out.

Architecture principles define the guardrails of architecture work.

Architecture principles define the constraints with which your architecture must deal. Their purpose is to serve as a guideline you need to consider when developing your architecture.

Define the constraints that must be dealt with, including enterprise wide constraints and project specific constraints (time, schedule, resources, vendors, standards, and so on). Architecture principles define guidelines to be considered when developing an architecture. Describes what a "good" solution or architecture should look like. Used to evaluate and agree an outcome for architecture decision points.

Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions. Each architecture principle should be clearly related back to the business objectives and key architecture drivers.

It is useful to have a standard way of defining principles. In addition to a definition statement, each principle should have associated rationale and implications statements, both to promote understanding and acceptance of the principles themselves, and to support the use of the principles in explaining and justifying why specific decision are made.

Principles are normally created through a workshop process. Common attendees would be the CIO, Chief Architect, Head of Solutions Development, Head of IT Operations plus selected business and IT specialists and key stakeholders. The workshop should be run on a consensus basis - that is, create a set of principles that all attendees can live with, rather than looking for 100% agreement.

This is one of the core artefacts where you can benefit from re-use; SAP Architects have a set of examples that can serve as a "strawman", to accelerate the workshop process.

The following figure outlines and describes the architecture principles.

TOGAF source: https://pubs.opengroup.org/togaf-standard/adm-techniques/chap02.html#tag_02_06

The following figure outlines the "Ease of use" principle based on the TOGAF standard.

An Architecture Principles Catalog is typically structured in different domains or areas, such as business, Application or Security.

In this example, you see typical architecture principles which you can then re-use and adapt for your specific architecture engagement.

The total number of principles should be limited, as having too many would limit the flexibility of the architecture. A good range would be between 10 and 20 architecture principles at the maximum. Remember, they are high level guiding principles for the overall architecture.

You can find further examples of architecture principles on TOGAF.

What are the steps required to create the architecture principles Catalog?

Each step is outlined below.

1. Don't start from scratch. Reuse principles if available in the company or in a catalog provided by TOGAF or by SAP. This is one of the core artefacts where you can benefit from re-use; SAP Architects have a set of examples that can serve as a "strawman", to accelerate the workshop process. Obviously these principles will need to be adapted the company specific situation.

2. This brings us to step 2: To develop good fitting principles, you need to understand the company strategy and goals as well as overall landscape and market trends and so on. In order to do that, you can re-use existing artifacts such as the business strategy map, where the strategic priorities, goals and objectives are clearly stated.

3. Identify architecture principles: As mentioned previously, principles are normally created through a workshop process with Common attendees such as the CIO, Chief Architect, Head of Solutions Development, Head of IT Operations plus selected business and IT specialists and key stakeholders. The workshop should be run on a consensus basis - that is, create a set of principles that all attendees can live with, rather than looking for 100% agreement. The might usually require multiple iterations.

4-5. As mentioned previously, it's very important to identify the rationale and the implications for each of those principles to make them actionable rather than theoretical.

The Solution Context artifact shows the relationship between the proposed solution and the organizational units / business roles / business functions within the enterprise. This diagram outlines the usage of solution components to the organization units that perform business functions and helps to understand requirements in different areas such as usability, security, support, and so on.

Solution context shows the relationship between the proposed solution and the organizational units, business roles, ​and business functions within your enterprise. The purpose of the solution context is to help understand requirements in areas such as usability, security, and support, for example.

Processes, applications, data, and technology that will be added, removed, or impacted by the architecture will need to be clearly outlined.

Checkpoint: Is a stakeholder able to get an understanding of the proposed solution within 10 minutes or is the diagram too complex to provide a rough vision of the future architecture?​

The following figure shows you a template that highlights the solution in focus, including the interaction with user groups and existing solutions.

The solution in focus is described in terms of business capabilities, objectives or outcome to define the solution context which is in scope of the architectural work.

It subsumes the following activities:

1. Enterprise Architecture Practice Capability Assessment
2. Preliminary Business and Technology Capability Assessment
3. Business and Technology Transformation Readiness Assessment

Evaluate the capability of the enterprise to develop and consume the enterprise architecture.

In the Architecture Vision phase, the architect should consider the capability of the enterprise to develop the Enterprise Architecture itself, as required in the specific initiative or project underway.

Gaps in the ability to progress on the architecture development process, whether deriving from skill shortages, information required, process weakness, or systems and tools, are a serious consideration in the vision of whether the architecture effort should continue.

Key questions to be asked:

What is the capability and maturity of the architecture function within the enterprise? What architectural assets are currently in existence? Are they maintained and accurate? What standards and reference models need to be considered? Are there likely to be opportunities to create re-usable assets during the architecture project?

A preliminary identification of required business and technology capabilities to implement business strategy and model.

A key step following from evaluation of business models, or artifacts that clarify priorities of a business strategy, is to identify the required business and technology capabilities the enterprise must possess to act on the strategic priorities.

The detailed assessment of business capability gaps belongs in the Business Architecture phase, where the architect can help the enterprise understand gaps throughout the business that need to be addressed in later phases of the architecture.

In the Architecture Vision phase, a preliminary assessment needs to be done.

The detailed assessment of solution and technology capability gaps belongs in the Solution Architecture and Technology Architecture phase, where the architect can help the enterprise understand gaps throughout the IT that need to be addressed in later phases of the architecture.

In the Architecture Vision phase a preliminary assessment needs to be done.

Questions to ask:

• What is the capability level of the enterprise as a whole? Where does the enterprise wish to increase or optimize capability? What are the architectural focus areas that will support the desired development of the enterprise?
• What is the capability or maturity level of the IT function within the enterprise? What are the likely implications of conducting the architecture project in terms of design governance, operational governance, skills, and organization structure? What is an appropriate style, level of formality, and amount of detail for the architecture project to fit with the culture and capability of the IT organization?
• Where capability gaps exist, to what extent is the business ready to transform in order to reach the target capability? What are the risks to transformation? Are there other considerations to be addressed beyond the basic capability gap?

Evaluating and quantifying an organization's readiness to undergo business and technology change.

The recommended activities in an assessment of an organization's readiness to address business and technology transformation are as follows:

• Determine the readiness factors that will impact the organization: The first step is to determine what factors will impact on the business and technology transformation associated with the migration from the baseline to target architectures.
• Examples of the factors are as follows:
  • Ability to clearly define and communicate what is to be achieved
  • Desire to achieve the results, willingness to accept the impact of doing the work, and the resolve to follow through and complete the endeavor
  • Existing sponsorship and leadership with clear accountability
  • Funding availability in the form of a clear source of fiscal resources, which meets the endeavor's potential expenditures
  • Workable Approach and Execution Model is an approach that makes sense relative to the task, with a supporting environment, modeled after a proven approach
  • IT Capacity to Execute is the ability to perform all the IT tasks required by the project, including the skills, tools, processes, and management capability
  • Enterprise Ability to Implement and Operate the transformation elements and their related business processes, absorb the changes arising from implementation, and ongoing ability to operate in the new environment
• Present the readiness factors using maturity models
• Enable participants to:
  • Assess their current (Baseline Architecture) maturity level
  • Determine the target maturity level that would have to be achieved to realize the Target Architecture
  • Determine an intermediate target that would be achievable in a lesser timeframe
• Assess the readiness factors, including determination of readiness factor ratings
• It will include:
  • Readiness Factor Vision: Determination of where the enterprise has to evolve to address the factor. First, the factor should be assessed with respect to its base state and then its target state.
  • Readiness Factor Rating: Determine how important each factor is to the achievement of the Target Architecture as well as how challenging it will be to migrate the factor into an acceptable visionary state.
  • Readiness Factor Risks & Actions: Derive a series of actions that will enable the factors to change to a favorable state.
• Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
• Include these actions into Implementation and Migration Plan

The Solution Concept diagram provides a high-level orientation of the solution that is envisaged in order to meet the objectives of the architecture engagement. In contrast to the more formal and detailed architecture diagrams developed in the following phases, the solution concept represents a "pencil sketch" of the expected solution at the outset of the engagement.

The purpose of the Solution Concept is to illustrate the major components of the solution and show how it will benefit the enterprise.

The Solution Concept artifact embodies key objectives, requirements, and constraints for the engagement and also highlights work areas to be investigated in more detail with formal architecture modeling.

Its purpose is to quickly on-board and align stakeholders for a particular change initiative, so that all participants understand what the architecture engagement is seeking to achieve and how a particular solution approach will meet the needs of the enterprise.

The given example outlines (in the middle) the architecture building blocks (ABB) in scope of the architecture work. Both on the left and right, additional systems are outlined which will need to be integrate with the solutions in scope. Additional information like internal or external users could be listed in addition to provide a holistic view of the solution concept.