SAP Technology and Enterprise Architecture

A description of the IT systems (hardware, software, and communication) enabling the Target Business Architecture, Application Architecture, and Data Architecture.

Illustrates the placement of technology components in deployment environments (e.g., data centers).

Determines the number of production instances needed per application (single, regional, or divisional).

Specifies the number and roles of IT environments (e.g., development, testing, production) and their sequence in transport processes.

A way to organize and manage resources, users, and applications within SAP Business Technology Platform (BTP).

A proven enterprise architecture methodology used for developing and managing the lifecycle of an enterprise architecture.

Current IT infrastructure description, serving as the starting point for improvements.

The desired future state of the IT infrastructure.

Comparing baseline and target architectures for technology architecture improvements.

A plan outlining improvements and the steps to achieve the target technology architecture.

Gathering feedback from key partners to integrate their concerns into the architecture decisions.

Shows communication lines and Virtual Private Networks (VPNs) of the IT infrastructure.

Details about the hardware components of the IT infrastructure (e.g., servers, storage).

Shows which application components are delivered and deployed in the IT infrastructure.

Provides guidelines and best practices based on SAP's experience with IT architecture.

Defines the IT environments used for a specific release.

A single instance of an SAP component in a designated role (e.g., development or production).

An independent, logical entity within the SAP environment having separate user data and master records.

Data that stays relatively constant over time (e.g., customer information).

Data related to daily business transactions (e.g., sales orders).

Customization and setup settings for SAP systems.

A traditional SAP system landscape with development, quality assurance, and production environments.

A flexible SAP system landscape with dedicated development environments for parallel projects and production support.

This phase aims to define the desired future state of the IT infrastructure (Target Technology Architecture) and identify improvements needed to get there.

It allows the business, data, and application plans to be implemented through technology components and services, addressing all concerns.

By comparing the current state (Baseline Technology Architecture) with the desired future state (Target Technology Architecture), you identify gaps that need to be addressed.

It outlines the specific steps and changes needed to transition from the current IT infrastructure to the desired target architecture.

Recommended sources include environments and locations diagrams, network diagrams, hardware specifications, and SAP documentation.

It ensures that all key partners are involved in the process and their concerns are considered before finalizing the architecture.

It summarizes and documents the final technology architecture, including decisions, rationale, and future plans.

A SAP solution that combines financial data from multiple SAP systems into a single, centralized system.

A system architecture where different parts of a system are located in different systems or locations.

Using consistent processes, procedures, and technologies across different systems.

The ability of different parts of a system to operate independently.

The optimal balance between benefits of standardization and autonomy in a split architecture.

Advantages of using consistent processes and technologies, such as increased efficiency, transparency, and information sharing.

Advantages of allowing different parts of a system to operate independently, such as faster response to business needs and increased flexibility.

How split architecture affects the way a company manages its systems, leading to trade-offs between centralized and decentralized governance.

A cloud-based ERP solution from SAP that provides comprehensive business functionality, encompassing finance, human resources, supply chain, and more.

A pre-configured environment for SAP S/4HANA Cloud that showcases the solution's capabilities and allows you to test its functionality.

A container within SAP Business Technology Platform (BTP) that holds resources, users, data, and deployed applications.

A central point in SAP Business Technology Platform (BTP) that manages subaccounts, entitlements, and quotas for platform resources.

A hierarchical structure within SAP BTP that allows you to organize subaccounts and resources according to your needs.

A payment model for SAP BTP where you pay only for the resources you consume.

A payment model for SAP BTP where you pay a fixed fee for a set of resources, regardless of usage.

A geographical location where SAP BTP resources are hosted.

Global Accounts in SAP BTP are not limited to a specific environment (development, testing, production) or region.

The right to use a specific resource within SAP Business Technology Platform.

A series of separate environments (like development, testing, and production) used to gradually move software through the development lifecycle.

Each subaccount within SAP BTP serves a specific purpose, like development, testing, or production, allowing for a more structured and organized development process.

This subaccount is used for initial development and testing of software components in a controlled environment.

This subaccount is used to thoroughly test the integrated software before it is released to production, ensuring quality and stability.

This is the final environment where the fully tested software runs and is made available to users.

Directories in SAP BTP serve as organizational units to group and filter subaccounts. They allow you to manage usage, costs, and entitlements for your subaccounts.

The maximum depth of a directory hierarchy in SAP BTP is 7 levels. This means you can have up to 5 levels of directories within a global account.

A subaccount is a self-contained environment within a global account where you deploy applications, use services, and manage subscriptions. Each subaccount can be independently managed and is associated with a specific region.

A subaccount's region determines the physical location where applications, data, or services are hosted. This region doesn't have to be directly related to your physical location.

It enables you to assign a specific quota for services and applications to a directory, which is then distributed to its subaccounts. You can also auto-assign quotas to new subaccounts in that directory.

It lets you control access permissions for a directory. For example, you can allow specific users to manage entitlements for the directory.

Subaccounts in a global account are independent of each other in terms of security, members, data, etc. This allows for separate management and control for each subaccount.

Subaccounts allow you to structure a global account based on your organizational and project needs. They provide separate spaces for managing resources, permissions, and entitlements.

Subaccounts provide a layer of isolation, separating resources and permissions for different projects. This helps to enhance security by preventing unauthorized access or data leaks.

Subaccounts allow you to manage and control data independently for each project. This helps maintain data integrity, prevent cross-contamination, and ensure data compliance.