Adopting SAP Data and Analytics Advisory Methodology

This lesson introduces the SAP Data and Analytics Advisory Methodology (DAAM), an architecture development approach based on standard enterprise architecture frameworks, specifically The Open Group Architecture Framework (TOGAF) and SAP Enterprise Architecture Framework (SAP EAF).

Its purpose is to provide guidance in the design and validation of solution architectures for data-driven business outcomes. The methodology consists of four phases, ranging from analyzing the initial situation and defining the desired business outcomes to developing a solution architecture and a road map for successful realization.

The SAP Data and Analytics Advisory Methodology consists of four phases: Defining the project scope and identifying pain points (Phase I), defining business outcomes and requirements (Phase II), developing the target architecture based on the requirements gathered (Phase III) and recognizing the impact on data management to create a project plan (Phase IV). The central phases II and III can be carried out iteratively to refine the target architecture step by step. The process is adaptable to different project methodologies and is suitable for agile implementations.

1. Defining the project scope and identifying pain points (Phase I).
2. Defining business outcomes and requirements (Phase II).
3. Developing the target architecture based on the requirements gathered (Phase III).
4. Recognizing the impact on data management to create a project plan (Phase IV).

The central phases II and III can be carried out iteratively to refine the target architecture step by step. The process is adaptable to different project methodologies and is suitable for agile implementations.

The SAP Data and Analytics Advisory Methodology is organized into four phases, each having three steps.

The central part of the methodology occurs in phases II and III, where business, data, and technical requirements are analyzed, and the target architecture is developed. These two phases can be iterated, depending on the business outcomes.

However, phases I and IV are essential for establishing the project scope and identifying potential impacts on data governance and organizational aspects.

These phases may need to be adapted based on the project's scope and complexity.

• Phase I: Includes defining the scope, reviewing relevant artifacts, and identifying pain points or opportunities for the upcoming phases.
• Phase II: Involves defining the business outcome as well as business and solution requirements. Use cases are developed to outline the business benefits and processes involved from data collection to creating business value.
• Phase III: Translates the collected requirements into an architecture context and a solution concept that outlines architectural building blocks and their interrelations. This phase explores the development of a target solution architecture based on requirements identified in phase II. This process can either follow a traditional capability approach or use predefined use case patterns to review related reference architectures.
• Phase IV: Wraps up the investigation by recognizing the potential impacts on data governance, which leads to the formulation of a high-level project plan or road map.

Phases II and III must be managed in multiple iterations depending on the number of business outcomes and use cases to gradually develop and refine the target architecture.

The methodology doesn't favor a specific project methodology and can be adapted to fit the customer's preference and experience. Phases II and III are most suitable for an agile execution in waves or sprints.

In the following, the individual phases are investigated deeper.

Release of SAP Data and Analytics Advisory Methodology

Phase I of architecture development involves preparing for the subsequent work. It includes defining the scope, planning the architecture investigation, and analyzing the current data management and analytics situation. This phase is crucial for successful project execution as it sets the foundation by understanding goals, resources, and current issues. It helps to organize the subsequent architecture development process in Phases II and III.

This lesson explains how the SAP Data and Analytics Advisory Methodology works. The best way to do this is with a small example.

The Statement of Architecture Work serves as a comprehensive guide for stakeholders to understand the investigation's objectives, tasks, timelines, and stakeholders.

The statement of work contains the following points:

• Mission or purpose, and main drivers.
• Scope of investigation, considering organizational, business process, functional/data domain, data architecture, and data scope dimensions.
• List of key deliverables, such as reports, architecture models, capability heat maps, or prototypes.
• A plan outlining milestones and due dates for deliverables - Key roles and resources involved, including the sponsor, project lead, and key business and IT contributors.

This statement provides a clear road map for the investigation, ensuring alignment and understanding among all stakeholders.

In this step, the focus is on providing artifacts to understand the current customer situation within the defined scope. These artifacts can include architecture representations, data models, process descriptions, responsibility matrixes, organizational charts, and capability maps. These materials must be stored in a central repository for accessibility and collaboration and must be shared with participants before the workshop to prepare them for discussion.

A capability assessment can also be conducted during this stage to gauge the current data and analytics expertise using the provided capability model or a comparable one. Also, data governance aspects can be discussed, with related issues reevaluated in Phase IV.

The first workshop is an opportunity for the project team to analyze the current data and analytics landscape, data storage locations, data integration and management processes, and the use of analytics tools. These analyses form the foundation for further phases of the method.

The final step of the process offers various tools and methods for analyzing current challenges in data management and analytics and for identifying potential improvements or new data-driven business opportunities.

The tools and methods include SWOT analysis, design thinking, fishbone diagrams, and SAP's Data and Analytics Strategy Assessment.

The result is a prioritized list of issues, often organized using a Business Priority Matrix to focus on the most impactful topics. The Business Priority Matrix considers the "Complexity" and "Business Impact" dimensions to effectively prioritize the issues.

The selected issues are then translated into business results for investigation in the subsequent phases of the target architecture development.

In the second phase, the desired business outcomes are defined and the solution requirements are determined. This includes aligning the requirements with the business objectives and identifying the necessary technical solutions.

In this concept, you see how the DAAM works. The best way to do this is with a small example.

In the context of data-driven business outcomes, a business outcome is a measurable action that aligns with the business and data strategy. It provides a value proposition, integrates into strategic initiatives, and identifies key stakeholders and associated use cases.

During architecture development, at least two related use cases are analyzed to develop an initial solution architecture. A well-defined business outcome must be aligned and signed off by the business owner and investigation sponsor and serves as a key reference for subsequent analysis.

This step provides detailed information for each use case, including:

• The end-to-end process from source data to value creation.
• The IT and business stakeholders involved.
• The systems, technology, and data used.
• The expectations of stakeholders.

The data journey map is a useful tool to conduct this exercise, involving four pillars (action, system, people, and experience) where use case content is documented during a workshop.

The approach starts the analysis of the E2E process starting from the end, understanding the purpose and benefits of the desired outcome. It then defines the preceding steps and identifies the required data, ultimately leading to the source of the required data.

More overarching requirements or aspects of the use case can be documented in a side panel, such as security requirements or aspects important for the architecture definition. One exercise of the use case analysis is the identification of required data for defining data products, which are controlled datasets provided by a data domain. At this stage, the end-to-end data flow from source to target and important transformation requirements must be documented to consider IT solutions in the target architecture.

The data journey map exercise is typically conducted in a workshop mode with business and IT representatives. It helps to consolidate the major aspects of the use case in a use case canvas. Also, check if the customer use case can be assigned to a use case category/pattern that contains SAP-centric reference architectures, which can accelerate the definition of the solution architecture in Phase III.

In the final step, the business and data requirements are combined, and the solution is placed within the organizational context. Two types of diagrams are used for this, a solution context diagram and a Data Integration Flow diagram.

The solution context diagram details the relationship between the solution and organizational units, business roles, and functions within the enterprise. It involves listing solution requirements, outlining data sources and required data, and reflecting business roles and related functions.

The Data Integration Flow diagram consolidates data requirements from analyzed use cases, outlining the flow from source to consumption. This highlights source systems, data objects, and integration requirements for potential data products consumed by the use cases.

If necessary, data products can be further analyzed using data modeling techniques or inbound and outbound data product requirements analysis, typically during the detailed design phase after the final solution architecture has been approved.

In the first step of Phase III, the so called capability mapping, an EA technique, is used to select essential data and analytics capabilities based on business and technical requirements. Each required capability is then mapped to software products from SAP and other vendors.

Architecture options are developed based on the solution map or by using SAP Reference Architectures. The preferred architecture is then documented in more detail, enabling further activities such as implementation planning or proof-of-concept scoping to validate the solution architecture's fit-for-purpose.

This lesson explains how the DAAM works. The best way to do this is with a small example.

The baseline for the architecture development work in phase III is a solution concept diagram. It represents a logical architecture representation consisting of architecture building blocks and its relations. Consider that they are still solution agnostics.

Capability analysis can be conducted by the Enterprise Architect identifying relevant capabilities based on Phase II requirements and validating them with stakeholders. Alternatively, stakeholders can discuss and define the required capabilities using the Data & Analytics Capability Model as a reference.

The resulting capability map is used to identify standard software solutions from SAP or other vendors. If no standard solution is available, custom solutions can be considered. This solution map serves as the basis for developing the solution architecture in subsequent steps.

Developing a solution architecture involving solutions from different software vendors can be complex. When creating an SAP-centric architecture, reviewing use case patterns and related reference architectures available in the SAP Discovery Center can streamline the architecture development process, even if not all components are used.

SAP BTP reference architectures are presented as SAP BTP Solution Diagrams, based on consistent notation and design guidelines. This information can be found in the BTP Solution Diagram Repository.

However, architecture options are often identified that must be assessed and evaluated. The methodology provides a quantitative assessment approach for evaluating identified architecture options, involving relevant assessment criteria and a scoring metric from one to five, with five indicating the best fit. This assessment can be enhanced with qualitative aspects.

For SAP BTP-centric architectures, you can quickly achieve this by subscribing to and trying out the relevant BTP services, most of which can be tested for free or at a reduced cost. The Mission Catalog in SAP Discovery Center also provides missions that represent use cases for implementation on the SAP Business Technology Platform, offering step-by-step guidance and support from experts and the SAP community.

The methodology does not provide a detailed PoC approach but includes typical steps:

1. Setting targets and addressing questions.
2. Planning the proof of concept.
3. Building and testing the proof-of-concept solution.
4. Reviewing and documenting the results.
5. Deciding on next steps.

After validation, the architecture may need further detailing to reflect all necessary components for implementation planning. You can use the SAP BTP Solution Diagram notation or the organization's commonly used architecture drawing approach.

In the final phase, guidelines for data management are defined and road maps for implementation are drawn up. This ensures that data is managed responsibly and future developments are clearly planned.

This section explains how the DAAM works. The best way to do this is with a small example.

The baseline for Step 1 and 2 of Phase IV is a high-level data and analytics maturity assessment with a focus on data governance. Step 1 covers topics around data strategy, data quality and KPIs, data architecture, and processes. Step 2 deals with organizational aspects. As not all focus topics might be of interest in the context of the architecture investigation, the most relevant aspects must be select.

The assessment provides five maturity levels ranging from "initial" to "data-driven".

Data Governance is a framework that defines the rules, processes, and accountability that enables organizations to manage data as a product:

• Rules encompass standards, policies, and guidelines.
• Processes enable data management and decision making for related topics.
• Roles and Accountability defines data management responsibilities and decision rights.

Managing data as a product involves managing the availability, usability, security, and integrity of corporate data to deliver business value to internal and external stakeholders. A data set managed this way is called a data product.

The overall goal of data governance is to bring relevant data to the right person at the right time in the expected quality to make the decisions that lead to business outcomes.

The following data and analytics dimensions and focus topics are considered in the first part of the maturity assessment.

In a mature data-driven organization, the data governance and management teams will typically consist of various roles, each with its own set of responsibilities and skills. Examples are:

• Chief Data Officer
• Data Stewards
• Data Domain / Product Owners

Data Governance is considered as an overarching responsibility. Nevertheless, it must be defined how governance boards and teams are organized to define, decide, and establish data governance rules and policies, such as:

• Data Governance Council
• Data Governance Teams
• Data Domain Teams

The following focus areas are covered in the Dimension "Organization" of the maturity assessment:

Finally, all required actions from the assessment are consolidated as an input for the final step of Phase IV that is developing the road map.

A road map is a flexible planning technique to support strategic and long-range planning, by matching short-term and long-term goals with specific IT solutions.

An Architecture road map organizes activities according to business needs and priorities to establish the target architecture over a defined time horizon. The activities can be grouped into functional clusters.

An analytics architecture road map is developed by applying the following steps:

• Step 1: Derive the activities necessary to realize the architecture by comparing the actual and target architecture, while considering the business objectives.
• Step 2: Consider additional activities besides the architecture realization activities, such as actions from the Data and Analytics Governance Assessment, which must be considered during implementation.
• Step 3: Create the road map
  • Define clusters for road map and assign to each activity.
  • Create the road map diagram reflecting activities in context of time horizon and clusters.