The previous blogs of the “SAP Data and Analytics Advisory Methodology” provided an introduction to the methodology and an insight into the motivation and key artifacts. This blog provides an overview of the four phases that constitute a structured approach to develop a target solution architecture for data-driven business outcomes and to plan its realization.
The approach to develop a target architecture and roadmap is based on SAP Enterprise Architecture Framework that uses the TOGAF ADM (Architecture Development Method) as a baseline. It was adapted to cater for data and analytics specific aspects, e.g., data domains, data products, data & analytics capability model, or data-to-value use cases.
It is organized in four phases with three steps each.
The core of the methodology is covered in phases II and III where business and data requirements are analyzed, and the target architecture developed. Additionally, there are several aspects that need to be considered before and after the architecture development process. Therefore, phases I and IV can be considered as adaptable accompanying measures to ensure that all aspects for an architecture design and its successful realization is considered.
Phase I sets the stage by defining the scope of the investigation and reviewing all relevant artifacts. It also references tools and methods for an (optional) more foundational analysis on the current situation. The goal is to identify issues or opportunities that are used as baseline for the subsequent phases.
Phase IV completes the investigation by identifying potential impacts on data governance and organizational aspects. This leads to a roadmap or high-level project plan that covers the actions to realize the architecture and enable the organization to create the intended business value.
Both phases are executed only once in context of the project scope while phases II and III can be managed in several iterations depending on the number of business outcomes and use cases in scope. Also, the phases should be tailored to the scope of the customer-specific investigation as some steps depend on how comprehensive the architecture work is intended.
For example, if the investigation focuses on a specific and clearly defined business-outcome then step 3 of phase I (analyze opportunities and improvement potentials) is not required. Or if the target architecture has no impact on governance or organizational aspects, steps 1 and 2 of phase IV will not be considered.
Let me also mention that the methodology does not prefer a specific project methodology (classic vs. agile) but leaves it up to the customers preference and experience. All we can say is the phases II and III are most suited for an agile execution in several waves or sprints.
Let me explain the general logic of the two core phases in more detail as they also incorporate key artifacts and content that was explained in the previous blogs.
The following representation shows the artifacts & deliverables used in phases II and III and its sequence.
Phase II: Business outcome & solution requirements
It all starts with a description of the business outcome that is defined as a business-centric, specific, and measurable action. A business-outcome needs to be linked to strategic initiatives and underpinned by qualitative and quantitative business benefits.
Then, business outcomes are further specified by several customer use cases that outline how the business outcome and its benefits are created. Use cases describe the end-to-end process how data is processed from the source until it creates the business value described in the business outcome. This includes the steps, the actors (e.g., business user, IT admin, Data scientist) and business requirements specific to the use case.
One exercise of the use case analysis is the identification of required data that are used in the final step to define data product(s). A data product a controlled dataset provided by a data domain that is composed of data, metadata, and standard APIs to access (see previous blog for details). Data products do not need to be defined in detail but only in so far as is required for the target architecture development. Especially the end-to-end data flow from source to target and important transformation requirements (inbound/outbound) should be documented at this stage to consider IT solutions in the target architecture for data integration, transformation, or orchestration.
A consolidated view of the architecture context completes phase II.
Phase III: Capability map & solution architecture
There are two ways to develop a target solution architecture for the requirements gathered in phase II: either using the traditional approach by identifying required capabilities f and map them to potential IT solution. Or, if your customer cases can be mapped to the use case categories and patterns, by applying a accelerated path reviewing related reference architectures.
The traditional capability approach is a well-known practice used by Enterprise Architects. Business and IT requirements are normalized by selecting required capabilities from the Data & Analytics capability model. This constitutes a capability map that can be organized by architecture building blocks. These are the mapped to suitable IT solutions and solution features. Finally, the solution architecture is outlined by integrating the IT components to a consistent architecture design considering customer specific policies, guidelines, and rules.
During the analysis of the use cases in phase II it should already be checked if they fit to one of predefined use case patterns. If so, the respective reference architectures can be analyzed and used a baseline for the target solution architecture. Reference architectures are documented based on the SAP solution diagram notation and published in the GitHub repository that contains all official SAP reference architectures.
Here is another example of an SAP reference architecture for the use case pattern “Federated Machine Learning”
The diagrams can be downloaded into draw.io and adapted according to customer needs. This approach helps to accelerate the architecture design process and ensures that SAP solutions are consistently represented in the solution diagram.
It is also possible to combine the two approaches to make sure all required capabilities are considered in the target architecture.
Let me stress once more that the focus of the methodology is on architecture development covered primarily in the phases II and III. All required preparation work (phase I) and realization considerations (phase IV) are included in the methodology to ensure consistency and completeness. Because all aspects impacting the to-be architecture or that are impacted by the architecture need to be considered. Nevertheless, many additional best practices, methods and tools which are required or advisable in phases I and IV are not explained in detail. Instead, there are links to further information or services that provide the necessary support and details.
This completes the overview of the four phases of the Data & Analytics Advisory Methodology. The next blog will discuss phase I in more detail and covers a description of the required templates and tools.
Overview of phases
The approach to develop a target architecture and roadmap is based on SAP Enterprise Architecture Framework that uses the TOGAF ADM (Architecture Development Method) as a baseline. It was adapted to cater for data and analytics specific aspects, e.g., data domains, data products, data & analytics capability model, or data-to-value use cases.
It is organized in four phases with three steps each.
The core of the methodology is covered in phases II and III where business and data requirements are analyzed, and the target architecture developed. Additionally, there are several aspects that need to be considered before and after the architecture development process. Therefore, phases I and IV can be considered as adaptable accompanying measures to ensure that all aspects for an architecture design and its successful realization is considered.
Phase I sets the stage by defining the scope of the investigation and reviewing all relevant artifacts. It also references tools and methods for an (optional) more foundational analysis on the current situation. The goal is to identify issues or opportunities that are used as baseline for the subsequent phases.
Phase IV completes the investigation by identifying potential impacts on data governance and organizational aspects. This leads to a roadmap or high-level project plan that covers the actions to realize the architecture and enable the organization to create the intended business value.
Both phases are executed only once in context of the project scope while phases II and III can be managed in several iterations depending on the number of business outcomes and use cases in scope. Also, the phases should be tailored to the scope of the customer-specific investigation as some steps depend on how comprehensive the architecture work is intended.
For example, if the investigation focuses on a specific and clearly defined business-outcome then step 3 of phase I (analyze opportunities and improvement potentials) is not required. Or if the target architecture has no impact on governance or organizational aspects, steps 1 and 2 of phase IV will not be considered.
Let me also mention that the methodology does not prefer a specific project methodology (classic vs. agile) but leaves it up to the customers preference and experience. All we can say is the phases II and III are most suited for an agile execution in several waves or sprints.
Core phases of the methodology
Let me explain the general logic of the two core phases in more detail as they also incorporate key artifacts and content that was explained in the previous blogs.
The following representation shows the artifacts & deliverables used in phases II and III and its sequence.
Phase II: Business outcome & solution requirements
It all starts with a description of the business outcome that is defined as a business-centric, specific, and measurable action. A business-outcome needs to be linked to strategic initiatives and underpinned by qualitative and quantitative business benefits.
Then, business outcomes are further specified by several customer use cases that outline how the business outcome and its benefits are created. Use cases describe the end-to-end process how data is processed from the source until it creates the business value described in the business outcome. This includes the steps, the actors (e.g., business user, IT admin, Data scientist) and business requirements specific to the use case.
One exercise of the use case analysis is the identification of required data that are used in the final step to define data product(s). A data product a controlled dataset provided by a data domain that is composed of data, metadata, and standard APIs to access (see previous blog for details). Data products do not need to be defined in detail but only in so far as is required for the target architecture development. Especially the end-to-end data flow from source to target and important transformation requirements (inbound/outbound) should be documented at this stage to consider IT solutions in the target architecture for data integration, transformation, or orchestration.
A consolidated view of the architecture context completes phase II.
Phase III: Capability map & solution architecture
There are two ways to develop a target solution architecture for the requirements gathered in phase II: either using the traditional approach by identifying required capabilities f and map them to potential IT solution. Or, if your customer cases can be mapped to the use case categories and patterns, by applying a accelerated path reviewing related reference architectures.
The traditional capability approach is a well-known practice used by Enterprise Architects. Business and IT requirements are normalized by selecting required capabilities from the Data & Analytics capability model. This constitutes a capability map that can be organized by architecture building blocks. These are the mapped to suitable IT solutions and solution features. Finally, the solution architecture is outlined by integrating the IT components to a consistent architecture design considering customer specific policies, guidelines, and rules.
During the analysis of the use cases in phase II it should already be checked if they fit to one of predefined use case patterns. If so, the respective reference architectures can be analyzed and used a baseline for the target solution architecture. Reference architectures are documented based on the SAP solution diagram notation and published in the GitHub repository that contains all official SAP reference architectures.
Here is another example of an SAP reference architecture for the use case pattern “Federated Machine Learning”
The diagrams can be downloaded into draw.io and adapted according to customer needs. This approach helps to accelerate the architecture design process and ensures that SAP solutions are consistently represented in the solution diagram.
It is also possible to combine the two approaches to make sure all required capabilities are considered in the target architecture.
Let me stress once more that the focus of the methodology is on architecture development covered primarily in the phases II and III. All required preparation work (phase I) and realization considerations (phase IV) are included in the methodology to ensure consistency and completeness. Because all aspects impacting the to-be architecture or that are impacted by the architecture need to be considered. Nevertheless, many additional best practices, methods and tools which are required or advisable in phases I and IV are not explained in detail. Instead, there are links to further information or services that provide the necessary support and details.
This completes the overview of the four phases of the Data & Analytics Advisory Methodology. The next blog will discuss phase I in more detail and covers a description of the required templates and tools.
- SAP Managed Tags:
