Enterprise Architecture Blog Posts
Need a little more room to share your thoughts with the community? Post a blog in the SAP Enterprise Architecture group to explain the more complex topics.
cancel
Showing results for 
Search instead for 
Did you mean: 
AndreasPoth
Product and Topic Expert
Product and Topic Expert

The SAP Enterprise Architecture Methodology bundles

  • concepts and artifacts, the associations between them, and
  • practices supporting various use cases.

It is based on various principles, which are the focus of this blog posting.

A principle is a fundamental belief that helps to make concrete decisions.
Goals, objectives, and core values influence principles.

 

Within a team, it's essential to agree on common principles.
Common principles empower people to make consistent decisions with speed, high confidence, and clarity.
Regularly applying agreed principles is a prerequisite to creating a consistent overall result.

Contrariwise, the lack of common principles makes decision-making difficult since thinking must always be done from scratch. The absence of principles leads to exhaustive discussions and decisions that can be easily questioned or even overthrown.

 

In the elaboration of the SAP Enterprise Architecture (EA) Methodology, we agreed on various principles, such as

  • Separation & mapping of Business & IT solutions,
  • Use of Industry Standards,
  • Respect and Connect to other Architecture Contexts,
  • A Collaborative Approach & Content Fluency,
  • Defined Content Ownership,
  • Sustainability and Simplicity.

 

We share these principles since we believe they are critical to all enterprise architecture endeavors.
In addition, SAP EA services help customers to clarify their organization's enterprise architecture principles to determine target and transition architectures efficiently.

 

Separation and Mapping of Business & IT Solutions

The SAP EA Methodology carefully separates Business from IT Solution aspects.
The clear separation allows you to clearly

  • define business needs independent from concrete solution architecture or the SAP portfolio
  • map recommended solution architecture to the expressed needs of the business
  • explain the business impact of IT solutions in a business language

The clear separation and mapping of business and IT in the SAP EA Methodology and SAP reference architecture is the basis for bridging the gap between business and IT for our customers.

 

Use of Industry Standards

In the SAP EA Methodology, we leverage proven industry standards.

Examples are:

  • We use BPMN from the Object Management Group®  to model concrete process flows within our Solution Architecture.
    The SAP EA Methodology gives concrete guidance on using the BPMN concepts to describe Solution Process Flows in IT landscapes and extend the BPMN notation where needed, e.g., to specify integration. (https://www.omg.org/bpmn/)

  • Also, we based our Enterprise Architecture Development Cycle on the de-facto standard from TOGAF®, tailored to our needs and leveraging SAP Reference Architecture content.
    (https://www.opengroup.org/)

  • We used the APQC cross-industry Process Classification Framework® to derive multiple Business Activities in the reference architecture content area.
    The APQC Process Classification Framework® ("PCF") is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. The PCF is intended to facilitate organizational improvement through process management and benchmarking, regardless of industry, size, or geography. To download the full PCF or industry-specific versions of the PCF, as well as associated measures and benchmarking, please visit www.apqc.org/pcf.

Using proven, well-known industry standards reduces training efforts for practitioners. Created architecture artifacts are easier to understand.

For some topics, there are different, similar, or even conflicting standards available in the industry. In the SAP EA Methodology, we carefully decided which standards to apply.



Respect and Connect To Other Architecture Contexts

Enterprise architecture's discipline aims to drive more effective business and IT operations.
It shall help to overcome the fragmentation of processes within the whole enterprise.


Obviously, enterprise architecture touches many architecture contexts:
areas of interest around diverse expert groups with their own language, concepts, and models.

Examples of architecture contexts are:

  • Integration architecture
  • Data architecture
  • System landscape architecture

Strategic enterprise architecture is only relevant when it connects to different architecture contexts and builds on top of them.
Enterprise architecture shall not rule different architectures groups but needs to involve and connect to the available expertise.

The SAP EA Methodology introduces a core model with different architecture views and domains. We relate this meta-model to other architecture contexts. Shared kernels with other architecture contexts bundle the common concepts. Within a shared kernel, we use common languages, agree on shared content and follow a standard change and version management.

Additional mappings relate concepts outside the shared kernels.

With this approach, which follows Domain Driven Design principles, we avoid a single, monolithic and overcomplex (enterprise) architecture model and follow our collaborative approach.

Context_Map.png

 

Collaborative Approach & Content Fluency

Enterprise Architecture shall help to overcome the fragmentation of processes within the whole enterprise.
It serves multiple use cases along the business architecture and the software lifecycle.

At SAP, we see use cases in requirements management, portfolio planning, solution design, rollout, solution implementation, operations, and optimization.


Therefore, enterprise architecture must always be connecting and not separating.
Enterprise architecture content shall flow to all the use cases it supports. It shall constantly be evaluated in the light of the different use cases, extended and optimized.

This content fluency shall support smooth transitions between all phases, save time and effort, support efficient feedback cycles, and be the basis for consistent communication between units and organizations.

Distinct viewpoints on the shared enterprise architecture content support different use cases, possibly extended by use case-specific content.

Different units and organizations creating and using shared enterprise architecture content require a highly collaborative approach and high-level interpersonal skills of all participants. At the same time, all information requires clearly defined ownership and accountability.

At SAP, an open, cross-board area and cross-product architecture working group drives the evolution of the SAP EA Methodology. The ownership of the content is with the experts of the different units.

 

Defined Content Ownership

The ownership of all enterprise architecture content needs to be thoughtfully defined. Available expertise and ultimate accountability in the organization finally define the right to approve.

Sustainability and Simplicity

Due to the broad area of interest, enterprise architecture must focus on and thoughtfully define the key topics and architectural deliverables.

Enterprise architects must carefully validate the relationship between stakeholder value, authoring efforts, concept complexity, and ease of use.
Only conceptional assets that can be sustainably maintained by the authors and be adequately understood by the consumers shall be selected.  
The essence of good architecture is the reflection of shared understanding and the inclusion of meaningful decisions.


questionmark.png
What principles do you miss? What principles do you successfully apply? What did make you change your principles in the past?

2 Comments