In the previous blog, I provided details of phase I of the "SAP Data and Analytics Advisory Methodology". This blog introduces phase II and explains how to identify the requirements for a data-driven business outcome and how to build the solution context.
Overview of phase II
Phase II starts with a description of the data-centric business outcome, which 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 of 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.
A consolidated view of the architecture context completes phase II.
Step II.1: Business outcome definition
In general, a business outcome is defined as a business-centric, specific, and measurable target action taken in response to a business direction or disruption. It should be described as an achieved end state that can be verified through measurable results. The guiding questions are what needs to be achieved and why. The definition should be brief and concise, i.e., the key aspects should be included in one or two sentences.
We adopt the term in our context where we focus on data-driven business outcomes.
A business outcome needs to provide a value proposition, i.e., intangible, and quantifiable benefits that are expected from the solution / result. It also needs to be integrated into strategic initiatives or objectives (strategic context). This could come from the business strategy or, in the best case, from a data strategy that provides the key objectives and guardrails. It needs to be clear to which extent a data-driven business outcome fits into the strategy and helps to achieve the goals. Both aspects, value proposition and strategic context, provide more details on the question of why the business outcome needs to be achieved and why it is important.
You should also identify the key stakeholders who will benefit from the business outcome and those who need to be involved to create the results.
Finally, the related business use cases that describe in which ways the outcomes will be achieved should be listed. Use cases are important to derive the business, data and technical requirements that provide the input for the architecture development work.
In practice, you should use one business outcome and investigate at least two related use cases during one architecture development cycle (phases II and III). This is sufficient to develop an initial version of the (sap centric) solution architecture that can be validated against additional business outcomes and use cases that might exist. Each business or use case might involve different business and IT stakeholders.
A thoroughly defined business outcome definition document is the key reference for the subsequent analysis. Therefore, this artefact should be aligned and signed off by the business owner and the sponsor of the investigation.
Step II.2: Data product and use case analysis
The next step investigates each use case in detail to understand the
- E2E process from source data to value creation - WHAT
- IT and business stakeholders involved in the process - WHO
- Systems, Technology and Data - HOW
- Expectations of stakeholders towards improved experience - WHY.
A good method to conduct this exercise is the data journey map. It consists of four pillars (action, system, people, experience) where you document the use case content during a workshop.
The approach starts the analysis of the E2E process from the end, i.e., from the last step where the consumers of the data benefit from the expected outcome.
For example, if a sales dashboard shall be delivered, the final step is to understand how this dashboard will be used and what benefits this dashboard will provide to the sales organization (expectations). Only when everyone understands the purpose of the dashboard, it can specify what is needed to deliver content.
Next, you define the preceding step and discuss which roles, systems, technology, and data are required to conduct this step. This is repeated until you arrived at the source of the required data that represents the starting point of the process.
In a side panel (idea & parking space), you can document additional overarching requirements or aspects of the use case. This could be security requirements or aspects important for the architecture definition, for example.
Here is an example of a data journey map for a customer use case.
One exercise of the use case analysis is the identification of required data that is used in the final step of this phase to define data product (s). A data product is a controlled dataset provided by a data domain that is composed of data, metadata, and standard APIs to access (see previous blog for details).
In this phase of the methodology data products need not be defined in detail but only to the extent required to develop the target architecture. 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.
The exercise to develop data journey map for business use case is typically conducted in a workshop mode. It should involve business and IT representatives that have a stake in the use cases. The discussions should reflect the desired use case situation in the future.
It helps to consolidate the major aspects of the use case in a use case canvas. It organizes the results of the data journey map into different areas. In here you can also check if the customer use case maps to a use case category / pattern which contains SAP-centric reference architectures. This can accelerate the solution architecture definition conducted in phase III as we will see in the next blog.
Step I.3: Solution context consolidation
In the last step, the business and data requirements are consolidated, and the solution is put into the organizational context. Two diagram types can be used for this purpose, a solution context diagram, and a Data Integration Flow diagram.
A solution context diagram shows the relationship between the intended solution and the organizational units, business roles, and business functions within your enterprise.
This is done in three steps.
- The main solution requirements / capabilities that have been identified in the previous steps are listed in a central box. Focus on the key aspects only.
- Outline the data sources and required data.
- Reflect all business roles and related functions that will use the solution. This helps to understand the usage of solution components to the organization units that perform business functions and helps to understand additional requirements in different areas such as usability, security, support, etc.
A Data Integration Flow diagram is used to consolidate the data requirements from the analyzed use cases from source to consumption. It reflects the source systems, data objects and integration requirements to potential data products which are consumed by the use cases.
If necessary, the data products can be further analyzed in more detail by applying data modelling techniques (e.g. Entity Relationship Model) or inbound and outbound data product requirements analysis. But for a solution architecture definition, this is usually not required. Instead, such analysis would be part of detailed design phase after the final solution architecture has been approved.
This concludes phase II of the methodology that focused on business outcomes & solution requirements for data-centric use cases.
The next blog will cover phase III, which involves developing and evaluating solution architecture options and validating the preferred architecture.
Please reach out to sap-data-analytics-methodology@sap.com to get invited to our SAP Build Work Zone workspace to get access to the presentation and further assets like templates.
- SAP Managed Tags:
