Self-Built Software Discovery

🚧

Early Adopter Release

This feature is currently in early adopter release and may not be available to all customers.

Introduction

SAP LeanIX Technology Risk and Compliance allows you to automatically discover and build the inventory of self-built software components such as microservices and tech stacks. It systematically pulls in data from engineering sources through the API and allows you to ingest SBOMs and developer libraries already in use to build the inventory.

• Microservice discovery: SAP LeanIX Technology Risk and Compliance allows you to automatically discover microservices by relying on community best practices. You can set up automated microservice discovery using a YAML manifest file stored in your Git repository, following the configuration-as-code approach. This allows developers to seamlessly contribute to the technology inventory in SAP LeanIX without having to leave their development context.

  As developers update the manifest file to reflect changes in the microservices metadata, SAP LeanIX automatically detects these changes and updates the inventory accordingly. This ensures that the organization has an up-to-date inventory of all self-built software. Discovered microservices are automatically added to the inventory as fact sheets and updated as needed. To learn more, see Microservice Discovery in Your CI/CD Pipeline.

• Software bill of material ingestion: With the Technology Discovery API, SAP LeanIX allows you to ingest SBOMs from various points in your Software Development Lifecycle (SLDC), such as container registries, CI/CD pipelines, security tooling, and SCM tools like GitLab, Bitbucket, GitHub, and more. The API allows you to easily tie into your build processes where you produce the SBOM and automatically ingest SBOM data generated during the build process of your self-built software, ensuring a near real-time view of your software composition. For more information, see Software Bill of Materials (SBOM).

• Tech stack discovery from SBOM: SAP LeanIX Technology Risk and Compliance uses a curated reference catalog to match detailed SBOM components with tech stack frameworks. If a library matches a tech stack, an IT component is generated and linked to a relevant microservice. Libraries are aggregated when many libraries match a single tech stack. Currently, the tech stack discovery supports the discovery of frameworks and databases. The automatic and continuous detection and cataloging of tech stacks helps you streamline your organization's technology stack. The tech radar report aids this effort by providing a comprehensive visual representation of your technology landscape. To learn more, see Tech Stack Discovery from SBOMs and Radar Report.

Benefits

• Automatic tech stack discovery for improved technology governance: By automatically discovering tech stacks from imported SBOMs, you get accurate and dependable insights into your organization's technology stack. This reduces the manual and cumbersome intake and frees resources to focus on establishing clear architectural governance (via Radar Report) for the organization's tech stack.
• Easy usability through integration with the existing developer toolchain: Seamlessly integrating with the existing developer toolchain ensures fast time to value, and makes developer interaction seamless.
• Establish a trusted inventory of self-built software: Technology inventory remains current, ensuring that you have continuous and real-time insights into your IT landscape from self-built software, allowing for informed decision-making and proactive management.
• Improve time to recover for security incidents: Tracking the usage of third-party components within your applications in a business context enables you to assess and mitigate risks associated with cybersecurity incidents, such as log4j or SolarWinds, and also effectively manage legal infringements (e.g., use of restrictive licenses) your software supply chain.

Getting Started with Technology Discovery

Before you start, provision your workspace for self-built software discovery in the admin area. For details, see Workspace Setup for Self-Built Software Discovery.

To get started with technology discovery, follow these key steps:

1. Discover microservices: Set up automated microservice discovery using a manifest file stored in your Git repository. To learn more, see Microservice Discovery in Your CI/CD Pipeline.
2. Ingest SBOMs: Use the Technology Discovery API to attach SBOMs (CycloneDX and SPDX) to your previously discovered microservices. If you don't have an existing SBOM process yet, refer to our documentation on generating SBOMs. To learn more about SBOM, see Software Bill of Materials (SBOM).
3. Explore discovered tech stack: SBOM components are matched against a curated reference catalog, and IT components are automatically created and linked to relevant microservices. To learn more, see Tech Stack Discovery from SBOMs.

Modeling Guidelines for Self-Built Software

Following our microservice modeling guidelines, self-built software artifacts are imported as microservices, a subtype of application fact sheets.

Currently, many organizations use a product-oriented setup and view microservices as a functional decomposition of their products (applications). This approach aligns with domain-driven design, where microservices focus on a bounded business domain rather than abstract technical concepts.

Best Practices

Before diving into best practices, let's consider an example: a webshop with three microservices—a login micro-frontend, a payment processing backend, and a recommender service. Each microservice provides a unique business capability:

• Payment processing backend: Ensures successful and fast payment checkout.
• Recommender service: Offers tailored suggestions for additional purchases.
• Login micro-frontend: Provides a quick introduction to the webshop.

In these scenarios, both the ingestion and best-practice meta model allow you to analyze this product-oriented setup natively. For instance:

• Which teams power my webshop product?
• If the payment engine is down, what products are affected? What is the business impact (by knowing the affected business capabilities)?
• If I want to make changes or launch a new product, which existing capabilities or microservices can be used? What's the impact if we deprecate the payment engine? Who's affected if we update the API?
• Which technologies power our business (for example, SAP LeanIX's tech stack)?

In summary, this default best practice enables native analysis from the following perspectives:

• API management: By modeling microservices as applications and using providing and consuming relations to bind interfaces (for example, REST API or Async), you can leverage interface circle reports to discern dependencies between core product elements. This is helpful for planning migrations or transformations and understanding the cost of changes to existing product IT elements.
• Clear distinction between product and technology: Distinguish logical product building product / business blocks (microservices) from the technology used (IT components and third-party libraries via SBOM).
• Ownership: By using the dedicated team relation and status as a business artifact (rather than technology), understanding microservice ownership becomes a core element of maintenance.
• Technology standards: Analyze used technologies in the context of their product role to drive technology standardization.

Antipatterns

Modeling every deployed microservice version as a fact sheet is not recommended. Focus on the latest version deployed to production. Including excessive technological details often doesn't aid in making necessary business decisions and can lead to unnecessary clutter.

Alternative Approach to Modeling Self-Built Software

An alternative approach involves using IT component fact sheets as a backbone to capture self-built software, though it comes with some caveats (see below). This method is common in traditional, hardware-heavy IT landscapes, where microservices are viewed as pure technology rather than functional composites. The main advantage of the application-subtype approach is its native support for interface analysis between microservices compared to IT components.

👍

Recommendation

We encourage you to start with the default, best-practice application-based approach and applying it to concrete use cases. The integration capabilities (such as the SBOM API, Manifest API, and Git integrations) will default to that setting. If you believe another approach might be more beneficial, consult your Customer Success Manager for guidance. We can then assist you in provisioning your workspace for that mode.

Currently, the following out-of-the-box capabilities aren't fully supported for the IT component-based mode:

• Ingesting microservices (as IT components) through the manifest API
• Ingesting microservices through the GitHub Enterprise integration
• Automatic tech stack discovery from SBOMs

Detailed Guides

• Workspace Setup for Self-Built Software Discovery
• Microservice Discovery in Your CI/CD Pipeline
  • Manifest File and Schema
  • Configuring Your CI/CD Pipeline
• Software Bill of Materials (SBOM)
  • Generating SBOMs
  • SBOM Explorer
• Tech Stack Discovery from SBOMs