Data Model

LeanIX Value Stream Management (VSM) is centered around the three pillars Teams, Technology, and Products.

  • Teams consists of the list of teams you are having, their members, and their ownership.
  • Technology contains amongst other ingredients the Service Catalog, which we consider the foundation for most of the work you and your teams will be doing in VSM, as it provides the bridge between the three pillars.
  • Products provide the business context for the services and your teams' work.

Understand Services

LeanIX VSM is centered around *Services. We have chosen this name for three major reasons:

  • Microservices are a great way to build modern software systems, given the right requirements and setup. However, the reality in development organizations is much more dispersed - with legacy software, 3rd party or business-driven low-code software all in need of management. Hence, Software Artifact comprises Microservices and others, utilizing subtypes for easy filtering & navigation
  • Software Assets are a classical way to manage purchasing, deployment & maintenance of applications. We see that this term is heavily loaded and not well-accepted around modern developers.
  • Yet, coining a LeanIX-specific term means that the terms requires a constant explanation.
    Hence, we have chosen the a bit more generic term "Service" which everyone relates to some aspect of the broader "Service" definition that we see fit.
    (!!! TODO: Let's move that definition from the slide below into an inline definition. !!!)

The five dimensions of discovered data

VSM offers a ready-to-use data model which represents the needs of modern Product IT and is centered around Services.


Teams, Services, Products form the Core entities of VSM, along with Tech Stack and APIs

To more easily map this into your specific situation, here a few example based on our LeanIX data:


Some real data from LeanIX to make the data model more tangible


Fixed data model - simplified roll-out and onboarding by leveraging clear guidance

To help our customers and users to get value out of VSM sooner we are using a rigid data model. This allows the product to understand the semantics of each of the entries stored in VSM and to answer specific questions you and your teams may have around these - rather than providing generic functionality that requires you to find the answer yourself.

The Core VSM Entities

These entities are part of the VSM data model (extensions will follow over the course of time):

EntityDescriptionTypical data sourcesStatusRelations to other entities
ServiceThe independently deployable pieces of software. Typically captured in form of a Code repository, often found as a set of a few services running in your Kubernetes clusters. βœ… GitHub
βœ… Kubernetes
βœ… Manual creation
βœ… Custom integration
Available via the Service Catalog Ownership by Teams
Provided APIs
Consumed APIs
Supported Products
Used Libraries
Used Tech Stack
Product"Project-to-Product" is in the DNA of modern engineering organisations. Teams aim to understand and drive the business impact of their work.

In VSM, a product is defined as "how the customer sees and access the service(s)"
πŸ‘· LeanIX EAM
βœ… Manual creation
* πŸ‘· Custom integration
Available (Manual creation only) in form of a Product Portfolio* Supporting Services
TeamThe responsible development team behind the service, allowing easy identification of owners πŸ”­ CI/CD
πŸ”­ GitHub Repository
* βœ… Manual creation
Available (manual creation only) via the Team list* Owned Services
APICovers the offered and consumed APIs of the services πŸ”­ MuleSoft
πŸ”­ Swagger
Not yet available, will be shown as a API Catalog Providing Services
Consuming Services
Tech StackMajor technologies used by the services, e.g. programming languages, frameworks, or cloud services. πŸ”­ OOTB Integrations (e.g., Kubernetes, GitHub, Public Cloud, ...)
πŸ”­ Manual creation
Not yet available, plan to present as a Tech Radar* Using Services
LibraryWhich Software Libraries (in which version) are used by which ServiceπŸ‘· CycloneDX from CI/CD and other custom integrationsNot yet available, will be shown as a Library list* Using Services

General Attributes of all Entities

All of these entities come with

  • a name
  • a (short) "pitch"
  • a (longer) description
  • πŸ”­ a list of tags
  • entity-type-specific data (entered manually and/or discovered automatically)