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. !!!)
24522452

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.

27902790

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:

27782778

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):

Entity

Description

Typical data sources

Status

Relations to other entities

Service

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

  • 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)"

Available (Manual creation only) in form of a Product Portfolio

  • Supporting Services

Team

The responsible development team behind the service, allowing easy identification of owners

Available (manual creation only) via the Team list

  • Owned Services

API

Covers the offered and consumed APIs of the services

Not yet available, will be shown as a API Catalog

  • Providing Services
  • Consuming Services

Tech Stack

Major technologies used by the services, e.g. programming languages, frameworks, or cloud services.

  • :telescope: OOTB Integrations (e.g., Kubernetes, GitHub, Public Cloud, ...)
  • :telescope: Manual creation

Not yet available, plan to present as a Tech Radar

  • Using Services

Library

Which Software Libraries (in which version) are used by which Service

:construction-worker: CycloneDX from CI/CD and other custom integrations

Not 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
  • :telescope: a list of tags
  • entity-type-specific data (entered manually and/or discovered automatically)