SAP and EA: A Brief History

Expensive open-ended enterprise software development carries a lot of risk. The failure of IT projects has been widely publicized with most projects experiencing cost overruns, running behind schedule, and ultimately turning out to be misaligned with business goals. Packaged solutions came to being as a response to the market demand for lower costs, shorter implementation cycles, and less uncertainty. Software vendors such as SAP developed module-based packaged solutions that could be implemented in phases which allowed for greater management and control which lead to more predictable results.

Packaged business solutions were now a part of the multiple deployment routes an organization can take in order to implement systems that align with their business objectives. Naturally, SAP felt that there was a need for an architecture with a specific focus on their packaged solutions. In order to support the achievement of all the benefits of their packaged business solutions, SAP both adapted existing and created its own standards, methodologies, and governance structures adapted to SAP’s packaged business solutions. Today, there has been a continuous refinement of this approach, resulting in what SAP calls its rapid deployment solutions – preconfigured applications with a standardized implementation approach and the required materials to support it that results in a drastically shorter implementation time.

Generally speaking, preexisting EA frameworks can support SAP customers’ digital transformation and business-IT alignment initiatives, but the SAP Enterprise Architecture Framework maps directly to SAP’s methods, services, and tools (such as SAP Enterprise Architecture Designer which we shall introduce in this chapter.)

Beyond packaged business solutions, SAP EAF was also introduced to support the integration of Service-Oriented Architecture (SOA) patterns. SOA has many definitions but is generally an approach to software design in terms of services. A service can be considered as an activity with a specific outcome. It is a unit of functionality that can be accessed and executed over a network. It performs automated tasks, responds to hardware events, or listens for data requests from other software, for example, an API. A service can exist independently or be part of a larger group of services that collectively provide a specific outcome or provide the functionality of a software application. SAP EAF explicitly addresses the content that package-enabled SOA solutions offer in general – and the SAP-specific content in particular.

Over the years, SAP customers have utilized Enterprise Architecture as a tool for aligning business and technology initiatives throughout their organizations. SAP applications are typically only one part of the technology landscapes overseen by IT executives, managers, and solutions architects. The goal is to equip readers with the knowledge to thrive in such environments by providing a foundational understanding of Enterprise Architecture.

SAP customers can make informed and relevant decisions on strategic business transformation projects that speak to the “to-be” state articulated by EA. Standards, guidelines, and service-level agreements must be documented for the deployment and maintenance of these applications. This process is simplified in the case of packaged solutions as solution providers such as SAP have existing best practices and service-level agreements.

Overall, SAP EAF takes TOGAF and focuses it on SAP solutions to empower enterprises in implementing SAP solutions at a lower cost, with minimal risk and higher chances of success.

The SAP Enterprise Architecture Framework

The SAP Enterprise Architecture Framework was officially launched in 2007 and is based on The Open Group Architecture Framework (TOGAF). It essentially comprises supplementary information, optimized content, and artifacts intended to accommodate packaged business solutions and Service-Oriented Architecture (SOA). SAP leaned on its decades of experience with prepackaged business solutions to formally document how to navigate the critical stages within the architecture process.

Similar to TOGAF, SAP EAF delivers a framework for an iterative process for the entire enterprise that is specifically mapped to SAP methodology. The SAP EAF accelerates architecture creation by providing best practices and artifacts that are relevant to its solutions and would normally have to be developed from scratch. Additionally, it provides the structure to store and arrange the architecture in a way best suited for SAP solutions and also one that is conducive for articulating the architecture to stakeholders.

SAP EAF empowers enterprises to drive business change through tailored implementations that focus on smaller rapid projects. It is important to note that this was also SAP’s response to the growing popularity of agile methodologies. Historically, implementations were generally long-term (and costly) endeavors best suited to the Waterfall methodology. SAP’s previous implementation methodology, ASAP methodology, was a traditional Waterfall method. With the growth of agile methodologies, SAP now has the improved Activate methodology to accommodate more flexible and rapid development.

The SAP EAF itself can be further adapted to suit different engagement models. SAP EAF provides predefined architecture patterns for different architecture development styles. Iterations can be defined and executed in a way that best suits the enterprise’s circumstances.

Figure 4-1 offers an overview of the SAP Enterprise Architecture Framework.

An illustration of the S A P enterprise architecture consists of framework extensions and resource base extensions. Below it, S A P extensions have mapping and tooling extensions, followed by TO G A F foundation that has the architecture development method and resources.

The next section will dive into how SAP customers can leverage SAP EAF.

How Can SAP EAF Be Used by SAP Customers?

SAP solution implementations require major investments in terms of time, money, and skills. This is further complicated by the existence of multiple deployment options. SAP customers require a clear vision of what a successful implementation should look like as well as the guidelines, standards, and governance that leads to a successful implementation. The SAP Enterprise Architecture Framework provides the big picture and framework to select the best deployment option through an understanding of the potential impact of change, the risks each deployment option faces, and ultimately making decisions based on quantitative evidence.

SAP Enterprise Architecture Designer

In the context of SAP Enterprise Architecture Framework, architecture is the modelling of the enterprise that is used for activities such as change impact analysis, requirements analysis, and cost/effort estimation in order to plan and execute successful implementation projects. It allows the enterprise to have a clear understanding of the benefits and the issues of a specific endeavor before any implementation work is ever done. The information is articulated from multiple perspectives to accommodate all stakeholders becoming a single source of truth. Modelling visualizations depict the interdependencies that exist throughout the enterprise which may have not been immediately apparent to individual stakeholders.

The SAP Enterprise Architecture Designer (SAP EAD) is the tool responsible for developing the architecture. The SAP EAD is a user-friendly central platform that maintains and integrates the organization's business, data, application, and infrastructure layers within a heterogenous environment. SAP EAD is a web-based collaborative tool that stakeholders in different roles can access and use. This book has emphasized the importance of stakeholder involvement; such a tool gives all relevant stakeholders the opportunity to participate directly in the planning and design of the architecture.

Governance rules and standards can be implemented on this central platform to ensure that all architecture activities and architecture changes adhere to them. This supports compliance from the very beginning of the Enterprise Architecture endeavor. SAP EAD enhances the understanding of the objects in the environment and the relationships between them. This is important for activities such as change analysis. Any change to an infrastructure object should be fully understood not only in its own context but also in the context of the related business, application, or data objects. Reports of this sort of analysis can be generated and distributed to interested parties. EA Designer is available both on-premise and in cloud versions for deployment.

All relevant users can access the central tool to execute the activities they’re responsible for and which can be subsequently utilized as input for the next step in the architecture development process. SAP EAD as an end-to-end tool is illustrated in Figure 4-2.

A flow diagram illustrates the flow of information from a business user to an architect to a developer.

Figure 4-2 depicts how different types of users can utilize SAP EAD for their specific end goals. The business user can document business strategy within the business architecture domain, whereas the enterprise architect can use SAP EAD to develop models. The outputs of the preceding processes are architectures, plans, and designs that can be utilized by different stakeholders such as executives, auditors, and service providers.

SAP EAD has functionality that enables collaboration such as the ability to share models via email, comment on models, create reports, and generate implementation code to share with development teams.

As the Enterprise Architecture is essentially a living asset that must continue to evolve alongside the enterprise and its environment, SAP EAD remains useful by facilitating the evolution of the architecture by continuously managing the architecture. SAP EAD graphically compares versions of models and architectures to support the analysis required for informed decision making in regard to the evolution of the architecture.

In the following chapters (Chapters 5–7), we shall explore the functional capabilities of SAP Enterprise Architecture Designer in more detail.

Returning to the Iterative Process

SAP EAF is inspired by TOGAF. The TOGAF Architecture Development Method phases described in the previous chapter form the basis of the iterative processes in SAP EAF. The next phases are the differentiator because they tackle the aspect of making the architecture work and keeping the process running within an SAP context specifically.

Opportunities and Solutions

Once an enterprise goes through the steps of developing the baseline architecture and the target architecture in terms of the business, data, application, and infrastructure layers, the enterprise must now evaluate the best deployment option to take. The enterprise can now decide on the specific projects to be undertaken in transitioning toward the target architecture. Important factors such as budget, timelines, and dependencies come into play, and the model comparison functionality of the SAP EAD take center stage.

In TOGAF’s ADM, this phase may include making a decision or decisions about custom development, packaged solutions, or reuse. In the context of SAP, there are prepackaged business solutions that will address business needs and the sub-options available such as on-premise or cloud implementations. Furthermore, this stage seeks to identify new business opportunities based on insights from the architecture work that has been carried out. Ultimately, the outcome of this stage will be the foundation of the implementation plan required to move to the target architecture.

The gap analysis between current business processes and the target business processes conducted in the earlier stages directs this phase by highlighting the missing functionality that will have to be purchased and implemented. Logical groupings of the required functionality allow us to separate them into specific projects aligned with the business strategy. For instance, functionality that is related to the sharing of data across the organization may lead to an integrated ERP system like SAP S/4HANA. All of this information will also help to determine whether an incremental approach is required and therefore initiate the development of transition architectures that will ensure the continuous delivery of business value.

Based on the gap analysis, there is likely to be a great emphasis on the implementation of missing functionality. It is important to not forget the current functionality that already exists but may need to be updated or replaced in order to better serve the enterprise. There are recommended steps in identifying the opportunities and solutions available to an enterprise during the EA process.

Migration Planning

This stage is a consolidation of the previous stage that results in a final architecture road map including the implementation and migration plans that support it. The enterprise must ensure that the architecture road map is aligned with how it manages change within the organization. SAP EAF offers templates for developing these plans in different scenarios and in the context of different organizational cultures. Having a central tool such as SAP EAD enables the necessary collaboration between project managers, project sponsors, and portfolio managers required to develop the implementation plan.

The implementation and migration plans provide a schedule for implementation of the solution described by the architecture road map. The implementation and migration plans include timing, cost, resources, benefits, and milestones for the implementation.

It is important to note that the architecture road map has been developed since earlier stages of the iterative process; it is now being finalized at this stage with all factors from each stage being taken into consideration.

Implementation Governance

Implementation Governance is about building a repository of all of the information or successful management of the various implementation projects. The implementation must follow the enterprise’s standards for corporate, IT, and architecture governance. SAP EAF provides standards, principles, and guidelines specific to SAP solutions which enable the enterprise to take a more focused approach. Implementation Governance goes beyond the implementation as one of its goals is also to define an operations framework for the maintenance of the solution.

Implementation Governance is also crucial to the next stage (Architecture Change Management) because it is critical that the governance body establishes criteria to determine whether a change request warrants just an architecture update or whether it warrants starting a new cycle of the Architecture Development Method.

Architecture Change Management

Architecture Change Management is about ensuring that all changes are carried out in conformance to the governance standards. This includes assessing any formal change requests to decide on whether the enterprise should initiate a new architecture evolution cycle. This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment. One of the advantages of Enterprise Architecture is that it enables an organization to rapidly adapt to change. Architecture Change Management facilitates this by having clearly defined steps that ensure that a need for potential change can be detected, assessed, and deployed.

Architecture Change Management forms the basis of the Enterprise Architecture being a living document by facilitating its evolution. It is Architecture Change Management that is responsible for the enterprise responding to new business needs and therefore adjusting the Enterprise Architecture accordingly. Once again, SAP EAD’s impact analysis capabilities, SAP’s business, and reference technical models provide value since they provide insight into the impact of potential changes or provide reference models for executing the change in the context of SAP solutions.

It is important to note that the architecture itself may continue to suit an organization while the underlying solutions no longer do so. An architect must be able to pick this up by identifying where solutions are no longer delivering business value and a change is required. Understandably, Architecture Change Management must be integrated with performance management and reporting to record both pre- and postchange analyses. If a particular change will have a high impact on the enterprise, then a separate strategy to manage its high impact must be defined.

In the final analysis, the Architecture Change Management is about determining the scenarios under which the Enterprise Architecture will be allowed to change after it has been implemented and the process by which that will happen.

Summary

The first half of the architecture development method is primarily concerned with developing the architecture, whereas the second half is focused on deploying and maintaining it. It is at this stage that it becomes critical to narrow it down to SAP-specific best practices, standards, tools, and reference models in order to increase the enterprise’s chances of success. Tools such as the SAP Enterprise Designer greatly enhance an enterprise’s ability to create, maintain, collaborate, and govern an enterprise’s architecture.

The next chapter will explore how SAP Enterprise Designer facilitates the architecture modelling process of the Business Architecture domain.