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.

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 customers. To get an overview of modeling guidelines, see Modeling Guidelines for Self-Built Software Discovery.

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.