So far, I have covered the first two phases of the methodology to develop a target architecture for data-driven business outcomes:
Phase I: Scoping & Baseline Analysis
Phase II: Business Outcomes & Solution Requirements
In this blog, I will focus on phase III discussing capability mapping and solution architecture development.
Overview of phase III
In the first step of phase III, we focus on an EA technique called capability mapping. It is used to select essential data and analytics capabilities based on business and technical requirements identified in phase II. Each required capability is then mapped to software products from SAP and other vendors.
Based on the resulting solution map, architecture options can be developed depending on the customer’s landscape. Alternatively, SAP Reference Architectures can be used to check whether the use cases from phase II fit into the defined use case categories and patterns. Afterwards, the architecture options are assessed.
The final step is to document the preferred architecture in more detail to enable further activities such as implementation planning or proof-of-concept scoping. The latter is recommended to validate the fit-for-purpose of the solution architecture.
Step III.1: Capability analysis & solution mapping
A (business) capability describes what an organization does, expressing the activities the organization performs to achieve its desired strategic goals and business outcomes. They provide a common language that can be used by businesses to articulate demand and IT to define solutions.
A capability model organizes capabilities into different levels or domains and enables visualization for analysis, e.g., to outline strategic importance, availability, maturity, or level of IT support.
In this methodology, we provide a Data & Analytics Capability Model that was developed by SAP (and is being revised at the time of this writing). Of course, if a company already has an in-house capability model, it can be used as well. The important thing is that the model covers all the aspects needed to develop a target architecture.
In practice, the capability analysis can be performed in two ways: either the (Enterprise) Architect identifies the relevant capabilities based on the requirements discussed in Phase II and validates them with the stakeholders.
Another approach is to gather the relevant stakeholders and let them discuss and define the required capabilities in their own words. As a reference the Data & Analytics Capability Model areas can be used to assign the capabilities. In the following example the areas are marked in blue and capabilities in yellow. Finally, the defined capabilities will be mapped to the standard capabilities of the Data & Analytics Capability Model.
The resulting capability map is used to identify applicable standard software solutions from SAP or other vendors. If no standard solution is available, a custom solution needs to be considered. This results in a solution map that serves as the basis for developing the solution architecture in the subsequent steps.
Step III.2: Develop architecture options
Developing a solution architecture can be a comprehensive task, especially when solutions from different software vendors are involved. In the case of an SAP-centric architecture, you should review the use case patterns and related reference architectures available in the SAP Discovery Center. This can speed up the architecture development process even if such a reference architecture is not used with all included components.
Here is an example pattern from the data & analytics use case category “Advanced Analytics” called “Federated Machine Learning”.
This reference architecture applies to use cases where machine learning (ML) models are trained with data from SAP applications and data that resides on Hyperscaler data stores.
SAP Datasphere is used for data federation while the ML Model is deployed at the Hyperscalers thereby removing the need for replicating or moving data. By abstracting the data connection, data load, and model training (with flexibility and provision for user provided training scripts), model deployment, and inferencing for Hyperscaler machine learning processes, the FedML Python library provides end to end integration with few lines of code.
This example also demonstrates that the SAP Reference Architecture can also include partner solutions or Hyperscaler service components.
SAP BTP Reference Architectures are represented as SAP BTP Solution Diagrams that are based on consistent notation and design guidelines developed by SAP. The BTP Solution Diagram Repository contains all the information you need to develop a standard BTP Solution Diagram. You can download the SAP BTP Reference Architecture solution diagrams and customize them in tools such as draw.io.
However, architecture options are often identified that need to be assessed and evaluated. In such cases, the methodology provides a quantitative assessment approach. It involves the definition of relevant assessment criteria and the use of a scoring metric from 1-5, with 5 indicating best fit. This can be advanced with qualitative aspects.
Step III.3: Validating and finalizing target architecture
It is good practice to validate the preferred architecture option by performing a proof-of-concept (PoC). A PoC is a rough prototype of the target architecture to demonstrate its feasibility.
For SAP BTP-centric architectures, this can be achieved quickly by subscribing to and trying out the most relevant BTP services. Most BTP services can be tested for free or at a reduced cost. See also the Mission Catalog in SAP Discovery Center. Missions represent use cases that can be implemented on the SAP Business Technology Platform, with step-by-step guidance and well-established support from subject matter experts and the SAP community.
The methodology does not provide a detailed PoC approach, but is limited to steps that are typically performed, which are:
- Target setting and questions to be answered.
- Planning proof of concept
- Build and test proof of concept solution.
- Review and document results
- Next steps/ go – no-go.
After the validation step, the architecture may need to be further detailed to reflect all the components required for implementation planning. You can use the SAP BTP Solution Diagram notation that was introduced earlier, or the architecture drawing approach commonly used in the organization.
This complements phase III of the methodology.
Conclusion
- What phase III is about? Phase III is where you figure out what data and analytics capabilities you need, what software products can provide them, and what your target architecture should look like.
- How to choose and map the capabilities? You use a capability model to pick the essential capabilities that match your business and technical requirements. Then you map each capability to a software solution from SAP or other vendors.
- How to develop and assess architecture options? You check if the SAP reference architectures fit your use cases. If not, you come up with different options based on your solution map. You compare the options using some criteria and pick the best one.
- How to validate and finalize your target architecture? You do a proof-of-concept to see if your chosen option works well. Then you document your target architecture in more detail so you can plan for the implementation.
The final phase IV covers data governance aspects and describes how to develop a roadmap for implementing the target architecture. The former topic was not yet covered in the current release of the methodology. Therefore, I look forward to announcing the next release soon.
Please contact to sap-data-analytics-methodology@sap.com to get invited to our SAP Build Work Zone workspace to get access to the presentation and other assets such as templates.
- SAP Managed Tags:
