Microservice Modeling Guidelines

Definition

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

• Microservice subtype is not included in the predefined meta model by default. You can add it by following the instructions in the guide: Add Fact Sheet Subtype. After adding the subtype, also create self-referencing relations between other application fact sheet subtypes. To learn how to create such relations, see Fact Sheet Relations.
• SAP LeanIX Technology Risk and Compliance customers can enable the self-built software discovery feature to automatically add the microservice fact sheet subtype, along with essential fields and relations. To learn more, see Workspace Setup for Self-Built Software Discovery.

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

To get an overview of modeling guidelines for self built software, see Modeling Guidelines for Self-Built Software.

Microservices don’t usually answer typical business application questions and generally do not exist independently of the business application. They can be related to the business layer through the business application subtype but can also have direct relations to business capabilities.

📘

Note

Microservice fact sheets do not count for pricing.

📘

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.

Antipattern

SAP LeanIX is an enterprise architecture tool, and it is not intended for modeling individual microservice deployments across different technical environments, as in a Configuration Management Database (CMDB) system.

Modeling every microservice deployment across different technical environments is not recommended, as it creates unnecessary clutter in the workspace with hundreds of fact sheets that provide little value.

Instead, what could be useful is to model instances of microservices in different regions or business units where they are managed separately or have independent implications—e.g., for disaster recovery.