Defining Technology Architecture

Objectives

After completing this lesson, you will be able to:

Analyze the fundamental concepts of technology architecture
Use environments and location diagrams to illustrate geographical representation of solution building blocks

SAP Enterprise Architecture Methodology

The SAP Enterprise Architecture Methodology is a methodology aligned with the TOGAF standard and tailored to the SAP Reference Architecture.

Image that shows the various aspects of requirements management and details for the architecture vision, business architecture, application and data architecture as well as technology 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.

Metro Map

The SAP Enterprise Architecture Methodology - Metro Map outlines the following:

The full set of architecture artifacts (recommended and optional)
Input from the SAP Reference Architecture to define the target architecture both in terms of business and IT domains
References to existing architecture work products such as principles, standards and guidelines as well as existing baseline business and solution architectures

This figure shows an SAP Enterprise Architecture Methodology - Metro Map

The selection of artifacts again very much depends on the nature of the architecture project and the stakeholders involved. These should be selected for the sake of the stakeholders (not for the sake of architecture).

Note

There will be iterations within and across the individual phases (the intention of the visualization is not to give the impression of a waterfall-based approach).

Technology Architecture

The evolution of new technologies is a major driver for change in enterprises looking for new innovative ways of operating and improving their business. The Technology Architecture needs to capture the transformation opportunities available to the enterprise through the adoption of new technology.

While the Enterprise Architecture is led by business concerns, drivers for change are often found within evolving technology capabilities. As more digital innovations reach the market, stakeholders need to both anticipate and be open to technology-driven change. Part of Digital Transformation has arisen due to the convergence of telecommunications and computer capabilities which have opened up new ways of implementing infrastructures.

Solution development methods are also evolving to challenge traditional development methods and are putting pressure on the shared services and common use benefits of the traditional Enterprise Architecture approach. Without a strong Enterprise Architecture approach, the rapid adoption of changing technologies will cause discontinuities across the enterprise.

The flexibility of the TOGAF ADM enables technology change to become a driver and strategic resource rather than a recipient of Change Requests. As a result, the Technology Architecture may both drive business capabilities and respond to information system requirements at the same time.

Specifically, the Technology Architecture describes the technology stack, physical computing environment and required network connectivity that enable the Application and Data Architecture Solution Building Blocks. Examples are the dedicated selection of virtual computing environments (for example, container-based), the availability in selected data center locations and the connectivity from office locations to the data centers where the Solution Application Components are operated.

Technology Architecture - Steps

The objectives of this phase are as follows:

Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, in a way that addresses the Statement of Architecture Work and stakeholder concerns
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

This figure outlines the step towards developing the technology architecture. The objectives within this phase are also listed.

There are a variety of content sources for the artifacts created in the Technology Architecture phase. The above images provides you with an overview that lists the recommended information sources.

The Deployment/Landscape of Technology Architecture

The following image outlines the deployment/landscape of the Technology Architecture. It describes the functions of the Software Distribution Diagram and the Environments and Location Diagram.

Note

The Software Distribution Diagram belongs to the Application Architecture. However, it provides the input for and may finally lead to the Environment and Location Diagram which provides a much higher level of detail of the Solution Building Blocks from the deployment and operational perspective. Use the Network and Communications Diagram for documentation of network communication lines / VPNs and etc.

Environments and Location Diagram

The Environments & Location Diagram shows which Solution Building Blocks are deployed and operated in which data centre location as well as the required physical connections between the Solution Building Blocks.

The physical locations of the users and other external systems that need to interact with the Solution Components must also be considered (see Context Diagram in Architecture Vision) . This also visualizes which data is exchanged over public lines and where VPN security capabilities need to be added.

Environments and Location Diagram

The Environment and Location Diagram illustrates which of your architecture building blocks and solution building blocks are deployed, at which locations. You can also outline different deployment environments such as development, test, and production.

Software Distribution Diagram: Pick up the previously created Software Distribution Diagram and evolve it into the Environments & Location Diagram.

Deployment Environments and Locations: Identify the deployment environments in which your Solution Building Blocks are running. Add more details to the "landing zones" of the Software Distribution Diagram by explicitly naming the data center providers, the data center location and infrastructure specific details per "landing zone". Map the identified solution building blocks to the deployment environments.

Data Flow and required connectivity: Visualize the relationships of type request-response or information flow between the Solution Building Blocks. This helps to understand network requirements.