Introduction to Application and Data Architecture

The SAP Enterprise Architecture Methodology – 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.

This phase involves some combination of Data and Application Architecture in either order. Advocates exist for both sequences.

Some organizations take an application-driven approach, whereby they recognize certain key applications as forming the core underpinning of the mission-critical business processes and take the implementation and integration of those core applications as the primary focus of their architecture effort (the integration issues often constituting a major challenge).

The level of detail addressed in this phase will depend on the scope and goals of the overall architecture effort.

New solution building blocks being introduced as part of this effort will need to be defined in detail during the phase. Existing solution building blocks to be carried over and supported in the target environment may already have been adequately defined in previous architectural work; but, if not, they too will need to be defined in the phase.

The order of the steps in this phase as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established Architecture Governance. In particular, determine whether in this situation it is appropriate to conduct Baseline Description or Target Architecture development first,

There is a variety of content sources for the artifacts created in the Application and Data Architecture phase. The following figure provides an overview that lists the recommended information sources.

A variety of source exists to "fill" the Application and Data Architecture artifacts with content. Every company has an Application and Data Architecture although it might often not be holistically and formally documented. Depending on the artifact in scope different sources and existing documentation will need to be consulted.

During the Application and Data Architecture phase multiple artifacts are created to provide a holistic understanding of the Application and Data Architecture in scope. The artifacts range from Application Architecture Diagrams and Application Use-Case Diagrams to Software Distribution Diagram and Conceptual Data Diagram.

The term Application Architecture Diagrams serves as a generic placeholder for several Application Architecture related diagrams. The following table shows the diagrams relevant for this training and outlines how they differ.

The Application Architecture Overview Diagram depicts the relevant Solution Building Blocks (in context of SAP Solution Components) and their integrations. It is a sum of all relevant Solution Building Blocks (Solution Components). It is based on Solution Concept Diagram and provides the mapping of Architecture Building Blocks (functional components) to selected Solution Building Blocks (in SAP Context, Solution Components):

• Product Map: A Product Map is a visualization within the SAP EA Methodology capability view, which captures recommended Products or Solution Components per Business Domain or Business Area with the Solution Capabilities that are covered by those components.

• Solution Component Diagram: Architecture blueprint of required solution components and their communication channels. It helps with understanding integration needs and deployment options.

• Solution Value Flow Diagram: Includes a high-level process, described as a list of realized value-adding business activities. It also includes mapping of the realized business activities to the solution components and capabilities.

• Solution Process Flow Diagram: Shows details of concrete process flows through the solution components with drill down to the further integration content. It helps with understanding the solution process and integration on detailed level by example.

• Software Distribution Diagram: Show how solution components are distributed across the IT infrastructure.

One key cornerstone of the SAP Enterprise Architecture Framework is the reference architecture that allows an accelerated delivery of architecture engagements.

The recommended artifacts of the SAP EA Methodology are classified into four interlinked architecture views: capability, process, data, and organization views. Each view encloses aligned business and IT perspectives, enabling business owners, and IT architects to collaborate on new business opportunities.

Having business and IT perspectives closely interlinked allows seamless navigation from business capabilities and business processes all the way down the line to SAP products and implementation artifacts such as APIs, iFlows, data objects, and events. The integration between SAP solutions is depicted on a semantical as well as a technical level. It enables alignment and consistency across SAP solutions and supports integration with non-SAP solutions.

SAP EA Methodology is one of the four pillars of the SAP EA Framework. Reference Architecture Content complies with the artifacts and principles as specified by the SAP EA Methodology. It encompasses Reference Business and Solution Architecture, which includes but is not limited to Intelligent Enterprise Solutions, Modular ERP (planned) and Industry Cloud (planned).

On the reference Business Architecture side, the business capability model consists of the business domain, the business area and the business capability. The business capability is describing what the organization need to know to generate value, independent of how software or technology may support it. Each business capability is assigned to one business area, and consequently to one business domain.

The business process model consists of end-to-end business processes, business process modules, business process segments, and business activities. Business activities are associated to business capabilities, and describe the how an organization creates value and achieves an outcome by performing a series of steps.

On the reference Solution Architecture side, Solution Capabilities are used to describe a functional ability of a single or multiple software components, that addresses and supports a Business Capability.

Being a technology and solution provider SAP has the answer to "a how" when it comes to how technology supports the business to drive value to the organization.

The linkage between business and Solution Architectures is what organizations are really looking for. It helps to answer critical questions, such as which stakeholders or which division of business units could be impacted or involved; what are the strategy and objectives the organization should try to accomplish, and how that refers to requirements, processes, and ultimately to the integration and data that is sitting within business applications.

In the previous chapter, Business Architecture, we saw that there are different ways to get to a business architecture and a related solution architecture. Besides the capability-centric and the process-centric approach, there is a third approach: the experienced based.

An experience-based approach might be applied by seasoned enterprise architects with profound domain knowledge and insights. Both the business as well as solution architecture artifacts are build based on the extensive experience of the enterprise architect. Often the Business Reference Architecture as well as the Solution Reference Architecture is used in addition as a "checklist" for completion or insights into latest solution offerings.

The four interlinked architecture views of the SAP EA Methodology allow navigation from the Business Architecture domain to the IT Solution Architecture domain on all levels. This enables Enterprise Architects to identify the relevant SAP solutions and to develop an Application and Data Architecture based on the Business Architecture to support the current and future business needs.

As outlined in the previous chapter, Business Architecture, the capability centric approach (focus on the WHAT) - in this approach business capabilities are used as the anchor point to identify areas of improvement (higher level of maturity) or gaps addressing the business requirements in support of the business strategy. Business capability maps are created and with the help of heat-mapping exercises areas of concern / action are getting identified. The meta-model of the SAP EA Methodology, and hence the SAP Reference Architecture, allows seamless navigation from Business Capabilities to Solution Capabilities and the underlying applications and components. During Phase C, these are identified to build an Application and Data Architecture which enables the Business Architecture.

In the following figure, the diagram on the left shows a section of the Business Capability Model for the Business Domain Human Resources. The diagram on the opposite side shows as section of the corresponding Solution Capability Map.

As outlined in the previous chapter, the process-centric approach focus on the HOW in contrast of the capability centric approach which focuses on the WHAT.

For organizations thinking along processes, the process-centric approach is the commonly used way forward. With the help of value flows and business process models on various level of granularity, areas of improvements, gaps, and so on, are getting identified.

The meta-model of the SAP EA Methodology, and hence the SAP Reference Architecture, allows seamless navigation from Business Process Model to Solution Process Model and the underlying applications and components. During Phase C, these are identified to build an Application and Data Architecture that enables the Business Architecture.

The diagram on the top shows a section (Reward to Retain) of the generic Recruit to Retire Business Process. The following figure is the corresponding Solution Value Flow, which shows the Business Activities with assigned Solution Capabilities and Solution Components.

An experience-based approach is used by enterprise architects with strong domain knowledge and insights. The Reference Business Architecture as well as the Reference Solution Architecture might act as a "checklist" for completion or insights into latest solution offerings. Both business architecture, as well as solution architecture artifacts, are build based on the experience of the enterprise architect.

Independent of the approach chosen, it is strongly recommend to run the architecture work in iterations (as also foreseen by the TOGAF ADM). A combination of different approaches has been proven as a best practice.