Application Modeling Guidelines

📘

Note

These modeling guidelines are for the Meta Model v4. For Meta Model v3 guidelines, see modeling guidelines for the Meta Model v3.

Definition

Applications are software systems or programs that process or analyze business data to support business tasks, processes, or aspects of an organization's business model.

Description

An application is a software tool designed to provide capabilities that help business users achieve specific goals or tasks within their work processes. These capabilities can range widely, such as accounting, customer relationship management, supply chain management, etc.

Applications generate and consume data and depend on various IT components to operate. SAP LeanIX's meta model adopts an application-centric approach, connecting both business and IT aspects. This helps enterprise architects align the organization's business and IT strategies by addressing key aspects such as:

• Business support - whether the application meets functional and technical needs
• Rationalization - if cost savings can be achieved by reducing the number of applications
• Compliance - whether the application adheres to regulations such as GDPR and the AI Act

Examples of Applications: Workday, Confluence, Zoom, AutoCAD, SAP LeanIX, SAP S/4HANA, Salesforce.

Application Fact Sheet Subtypes

The application fact sheet type has three optional subtypes, and they are not included in the predefined meta model by default. You can add these subtypes by following the instructions in the guide: Add Fact Sheet Subtype. After adding the subtypes, also create self-referencing relations between the subtypes. To learn how to create such relations, see Fact Sheet Relations.

These subtypes are:

• Business Application
• Deployment
• Microservice

Business Application

The business application subtype is used to clearly distinguish logical applications from deployments and microservices. You use the business application subtype to model applications and connect the deployment or microservice subtypes to the business layer of the meta model. It allows you to show how microservices and deployments indirectly support business capabilities.

Deployment

Deployments are used to represent multiple technical instances of an application in different environments, such as testing, staging, sandbox, quality assurance, and standby fallback environments.

The deployment subtype helps capture provisioning aspects of these technical instances, including where an application is running, its resources, and operational requirements. It helps track internal cost allocation, technical dependencies, and risks.

Deployments, on their own, do not fulfill a business purpose and cannot exist independently of the business application. They must be related to the business layer through the business application subtype. For guidelines and best practices on modeling deployments, see Deployment Modeling Guidelines.

📘

Note

Deployment fact sheets do not count for pricing, but they must not have direct relations to business capability or business context fact sheets.

Microservice

Microservices are individually deployable building blocks that perform a specific function or task within a larger application, typically self-developed. The microservice fact sheet subtype represents these functional composites of the application.

Modeling microservices is helpful in understanding their technical ownership, identifying opportunities for reuse across different applications, and modernizing architecture from monolithic applications to microservices architecture.

Microservices, on their own, don’t answer typical business application questions and cannot exist independently of the business application. They must be related to the business layer through the business application subtype. For guidelines and best practices on modeling microservices, see Microservice Modeling Guidelines.

📘

Note

Microservice fact sheets do not count for pricing, but they must not have direct relations to business capability or business context fact sheets.

📘

Note

For deployment and microservice subtypes, we strongly recommend maintaining fact sheets through automated integrations. For more information, see Deployment Modeling Guidelines and Microservice Modeling Guidelines.

Modeling Guidelines and Best Practices

Best Practices for Getting Started

While building your inventory, what constitutes an application should be easily understood by everyone in the organization. Applications could be:

• Commercial off-the-shelf (COTS) applications like Oracle Financials or Anaplan
• Open-source applications like Jenkins or Drupal
• Custom-built applications developed by your organization, whether deployed in the cloud or on-premise.
• Even simple tools, like a spreadsheet (XLS file) or a SharePoint site that supports business processes, can be considered applications.

We strongly recommend starting with logical applications in the initial stage, focusing on quick wins around Application Portfolio Assessment. As your EA practice advances, you can expand your modeling to include deployments and microservices using fact sheet subtypes.

Make use of the reference catalogs and SaaS discovery features to model SaaS services. This helps you easily build an inventory of associated IT components and providers, which will be relevant for realizing scenarios and generating reports down the road. To learn more, see Reference Catalog and SaaS Discovery.

Modeling SaaS Services

SaaS services are modeled as applications since they process data and help organizations complete business tasks. Use the reference catalog to automatically add descriptions and other essential details, as well as to automatically create related IT components and providers. For more details, see Applications in the Reference Catalog.

If your organization has a significant number of SaaS services, leverage the SaaS discovery feature. It pulls your most important SaaS services into your workspace through your Single-Sign-On (SSO), Secure Access Simplified (SASE), and Cloud Access Security Broker (CASB) solutions. You can automatically create relevant fact sheets for discovered services or link them to existing fact sheets to update information automatically. These application fact sheets are also linked to the reference catalog, ensuring regular updates and allowing you to create or update associated IT components and providers. For more details, see SaaS Discovery.

For an illustrated example of how to model a SaaS application, see Complete Modeling Example – SAP LeanIX as an Application.

📘

Note

ERPs (e.g., SAP S/4HANA) and other large systems like Salesforce are more complex and are explained in dedicated modeling guides. To learn how to model them, see Modeling Best Practices.

👍

Benefits of Modeling IT Components and Providers

Modeling IT components and providers requires minimal effort when using the reference catalog and SaaS discovery feature. Even if not immediately needed, having them in your inventory is valuable for managing more complex setups. For example, you might have a self-hosted application where the server provider differs from the hosting provider or a SaaS application that relies on an SSO IT component.

Modeling IT components and providers gives you clear visibility into hosting, helps generate important reports like the provider cost report, and offers essential data for better risk management.

Modeling Versions

For most use cases, maintaining version details does not provide significant value. However, if versioning is relevant for you for purposes such as testing, training, or rollout, you can capture it in the Release field of the application fact sheets within the Name & Description subsection. Information in the Release field is suffixed with the fact sheet name to form the full name and display name, distinguishing different versions of the application in reports and diagrams. To learn about fact sheet naming convention, see Fact Sheet Naming Convention.

In SaaS products, when versions are continuously updated, and all users run the latest version, version numbers are generally irrelevant, and we don’t recommend tracking them on application fact sheets.

Modeling Hierarchies (Parent / Child Relations)

Applications often consist of multiple entities or modules within a common ecosystem or platform (e.g., ERP systems, CRM systems). The following illustration shows modeling hierarchy using Adobe Creative Cloud as an example.

• Adobe Creative Cloud is a suite that bundles various applications to assist designers in producing visual content. It is modeled as the parent entity.
• Specific applications within Adobe Creative Cloud, such as Adobe Photoshop for image editing, which support particular business tasks, are modeled as child entities.
• Adobe Creative Cloud could also be part of a broader design platform that includes other applications for different functions, such as video editing. In this case, a platform fact sheet is used to represent the overarching design platform.

Modeling External Applications

There is often a need to model applications that your organization does not own or directly rely on but has to interface with, for example, applications of business partners, service providers, authorities, etc. In such situations, consider the following two approaches:

• For a general view of such external applications in your architecture, create a single composite application fact sheet, for example, External Application, to represent all external applications. Link internal applications to this composite fact sheet through an interface to analyze dependencies and data flows in reports and diagrams. Additionally, connect to other fact sheet types to show how external applications fit into the overall architecture.
• When external applications are crucial to your architecture, create individual application fact sheets for each one. This allows you to use all of SAP LeanIX's capabilities for detailed views and analysis. Even if you don’t own or manage these applications, they impact your architecture and business similarly to internal applications and should be treated the same way for application-based pricing.

Modeling the Underlying Technology of Applications

Modeling the underlying technology of applications is key for use cases such as obsolescence risk management and technology standards management. The technical compositions of applications are modeled using IT component fact sheets.

The application's technical composition can include software, services, hardware, IaaS, PaaS, and SaaS. For detailed guidance on modeling IT components, see IT Component Modeling Guidelines.

Capturing Cost of Applications

The cost of the application can be captured on the relation between application and its IT components. For detailed guidance, see Cost Management.

Antipatterns

This section addresses common pitfalls and antipatterns involving counterproductive ways of modeling applications in SAP LeanIX.

• Application vs. IT component: A common pitfall is confusing applications with IT components.
  • Classical business applications, like ERP systems, are clearly applications. In contrast, operating systems, databases, and virtual machines are IT components.
  • Consider the software architecture to distinguish between the two: applications typically include data, logic, and presentation layers, while IT components do not. If an entity lacks a data or business logic layer, it is likely an IT component.
  • If the entity provides data and business logic to other applications and possibly business users, it is best modeled as an application. For example, if a spreadsheet serves a specific business task, such as a quoting tool or usage analytics, the spreadsheet itself is considered an application, while the spreadsheet software, like Excel, is an IT component of the subtype software.
  • System software, technology services, or hardware (e.g., operating systems, databases, runtime environments, laptops, desktop computers, and other devices) are IT components.
• Versioning: In most cases, versioning for applications doesn’t add significant value and should only be used if it’s relevant to your use case.
• Directly linking applications to providers: Linking applications directly to providers through custom relations in the meta model might initially seem like a time-saving measure. However, this approach can severely restrict reporting capabilities in the long term, including cost reporting and obsolescence risk management.
• Microservices Modeling: SAP LeanIX is not suited to modeling a live microservices landscape. Tracking every microservice, software library, and technical detail manually all of the time can become difficult and can clutter your EA landscape. If you model microservices, automate the process and focus your effort on generating relevant insights for your business. For guidelines on modeling microservices, see Modeling Microservices.

Applicable Use Cases

Applications are essential for all SAP LeanIX use cases. In the initial stage, we recommend building your inventory with applications, business capabilities, and organization fact sheets, as they are essential for generating any meaningful reports and insights.

Insights from Application Fact Sheet

Since applications are central to all use cases in SAP LeanIX, most reports and insights will be around applications. For details on various reports, see Reports. Key reports include the application portfolio report, application landscape report, matrix report, and interface circle map.

Video Tutorial

The following video tutorial provides an overview of application modeling guidelines and best practices.

Related Information

• Complete Modeling Example – SAP LeanIX as an Application
• Modeling guidelines for application subtypes:
  • Deployment Modeling Guidelines
  • Microservice Modeling Guidelines
• Modeling best practices for major IT systems:
  • SAP Modeling Best Practices
  • Microsoft Applications Modeling Best Practices
  • Google Cloud Platform Modeling Best Practices
  • Salesforce Applications Modeling Best Practices
  • AWS Applications Modeling Best Practices