Deployment and Microservice Modeling Guidelines

Definition

Deployment

Deployments are technical instances of an application in different environments, such as testing, staging, sandbox, quality assurance, and standby fallback environments. Deployments, on their own, do not serve a business purpose.

Modeling deployments allows you to capture provisioning details, such as where an application is running, the resources it requires, and its operational needs. It helps track internal cost allocation, technical dependencies, and risks.

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.

📘

Note

Deployment and microservice subtypes 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.

Modeling Deployments

SAP LeanIX offers the deployment subtype to help organizations manage and track the application deployed in various technical environments such as testing, development, quality assurance, staging, etc.

IT Service Management (ITSM) standardizes aspects like the provisioning of different technical environments, user access management, internal cost allocation, etc. The deployment subtype helps you align with ITSM by ensuring that the applications in these technical environments are effectively tracked and managed. This enhances visibility and control over IT resources across different stages of the application lifecycle and environments.

Modeling deployments provide value in specific scenarios:

• To manage obsolescence risk in different environments. For example, whether an older version of a microservice is used in a development or staging environment and is known to have risks.
• For business continuity management, for example, to understand the impact of shutting down a specific deployment.
• For a detailed understanding of technical dependencies for transformation planning, in particular, ERP transformation.
• To manage regional risk, for example, to ensure that applications are not hosted in regions where policies or regulations prohibit them.

We strongly recommend automating the creation and management of deployment fact sheets using Configuration Management Databases (CMDBs), such as ServiceNow. As the number of deployments grows, manually managing deployment details can take a lot of time and effort. Leverage ServiceNow integration to efficiently manage deployment fact sheets by mapping 'Application Services’ from ServiceNow to SAP LeanIX. For more details, see ServiceNow Integration.

Since deployments, on their own, do not serve a business purpose, they do not exist independently of the business application. They must be related to the business layer through the business application subtype. While modeling relations to other fact sheet types, as a best practice, relations to business capabilities, business context, and data objects are maintained on business applications, while IT components, organization, and interfaces are related to the deployment subtype.

👍

Note

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

When application instances serve business purposes, such as having distinct business capabilities and processes or being used in various parts of the organization with different configurations, interfaces, integrations with different systems, data centers, cloud providers, etc., they must be modeled as separate applications and not as deployments.

For example:

• Regional application instances - SAP FI France, SAP FI Germany, etc.
• Application instances in different business units - SAP FI BU1, SAP FI BU2, etc.

Modeling Microservices

Organizations developing in-house software most often need to capture components of their software. The microservice subtype is used to represent these functional composites of the application in SAP LeanIX. It can be useful for:

• Identifying opportunities for reusing microservices across different applications
• Understanding technical ownership - identify which development teams are responsible for specific microservices
• Planning and executing the transition from monolithic applications to a microservices architecture to improve functional fit and adaptability
• Compiling low-level data flow based on APIs
• Distinguishing functional building blocks (microservices) from the underlying technical composites of the application (IT components)

Modeling microservices using the microservice subtype allows you to leverage the full capabilities of reports and diagrams. For example, you can see the data flow between microservices using an interface circle map. As a best practice, we recommend modeling down to the level of specific microservices that form the core of relevant applications. This provides clear visibility into the technical dependencies of the product architecture, which is useful for technical transformations, such as re-architecting key applications.

In certain scenarios, such as during application modernization planning, manual maintenance of microservices can be useful. However, we generally recommend automating the creation and management of microservices fact sheets using SAP LeanIX Technology Risk and Compliance. It automates the discovery of microservices to keep up with frequent changes. While manual maintenance of microservices can become increasingly difficult as the number of microservices grows. To learn more, see SAP LeanIX Technology Risk and Compliance.

🚧

Note

Automated discovery and creation of microservices through SAP LeanIX Technology Risk and Compliance is currently in early adopter release and may not be available to all users.

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.

👍

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

Commercial and logical packages (modules) of software, on their own, support different business tasks and hence should be modeled as applications rather than microservices, even if they depend only on a single microservice.

The following example shows the modeling of microservices:

In the example, B2B Website.com and B2B MobileApps are business applications composed of several microservices like Core Iris, event-mirror, functional-validation, Payment Service, and Checkout Service. A microservice can also relate to multiple applications; therefore, the relationship between applications and microservices should be many-to-many rather than a parent/child relation or requires/required by dependency.

📘

Note

You first need to create this self-referencing many-to-many relation between business application and microservice subtypes in the meta-model. To learn how to create such relations, see Fact Sheet Relations.

You can map the relations between microservices by detailing their APIs using API fact sheets, a subtype of interface fact sheets. This also allows you to represent data flow between microservices. The example below shows the data flow between microservices within each application and across different applications.