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.
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. !!!)
VSM offers a ready-to-use data model which represents the needs of modern Product IT and is centered around Services.
To more easily map this into your specific situation, here a few example based on our LeanIX data:
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.
These entities are part of the VSM data model (extensions will follow over the course of time):
Typical data sources
Relations to other entities
The 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.
Available via the Service Catalog
"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)"
Available (Manual creation only) in form of a Product Portfolio
The responsible development team behind the service, allowing easy identification of owners
Available (manual creation only) via the Team list
Covers the offered and consumed APIs of the services
Not yet available, will be shown as a API Catalog
Major technologies used by the services, e.g. programming languages, frameworks, or cloud services.
Not yet available, plan to present as a Tech Radar
Which Software Libraries (in which version) are used by which Service
CycloneDX from CI/CD and other custom integrations
Not yet available, will be shown as a Library list
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)
Updated 2 months ago