Software Artifact Mapping

Map your cloud accounts and cloud resources to Software Artifacts in your VSM workspace

Link Cloud Resources to Software Artifacts

Part of our recommended tagging policy is to associate your cloud resources to the Software Artifact they belong to. These tags can then be used to group the resulting Compute Environments and Cloud Accounts in LeanIX Value Stream Management to the corresponding Software Artifact, e.g., one with category Microservice.

📘

Mapping Cloud Accounts vs Cloud Resources

For the mapping to Software Artifacts, tags can be used on both individual Cloud Resources (e.g., Virtual Machines or Serverless functions) and Cloud Accounts (e.g., Azure Resource Groups).
See below for the details and advantages of either approach.

For example, if you added a tag microservice: MyService to all virtual machines that are used to run the microservice "MyService" in the cloud and provided a Software Artifact mapping "microservice": "microservice", LeanIX Value Stream Management can group these resources to a Software Artifact of category "Microservice" and name "MyService".

Map Cloud Tag Keys to Software Artifacts

  1. In your LeanIX Value Stream Management Workspace, go to Administration > Integrations > Public Cloud Integration > Configure.
  2. Map tag keys to Software Artifact categories in the configuration (where you also configured the Cloud Accounts) using the configuration snippet shown below.
{
  "artifactMappingPerTagGroup": {
    <tag key>: <software artifact category>,
    ...
  }
}

You can assign different tag keys to the same Software Artifact category, e.g., when different tag keys are used in different Cloud Providers or in different Business Units in your company.

📘

Tag keys and values are treated case-sensitive

The keys and values for the tags (AWS, Azure) respectively labels (GCP) are treated in a case-sensitive way. i.e., if you are using MicroService in AWS and microservice in GCP, please configure a mapping for both MicroService and microservice. Please also keep in mind that different artifacts will be created for tag/label values with different cases (e.g., invoice-management vs Invoice-Management).

The following categories are defined in the standard data model:

  • thirdParty
  • legacy
  • library
  • microfrontend
  • microservice
  • tooling

Using Self-service-configuration, additional categories can be added to your workspace, and referenced here thereafter.

📘

Use the categories' IDs when defining the mapping

Please use the IDs of the categories when defining the mapping, not their label. (I.e., microservice instead of Microservice.)

When omitting a category, or providing an invalid category (one not defined in the data model), saving the update configuration is disallowed. If custom categories are required, please add them to the data model first.

Here is an example for a configuration:

{
  "aws": {
    "accounts": [
      {
        "arn": "arn:aws:iam::123456789012:role/LeanIXCloudDiscovery",
        "extensions": [
          "organizations"
        ],
      },
      {
        "arn": "arn:aws:iam::210987654321:role/LeanIXCloudDiscovery"
      }
    ]
  },
  "artifactMappingPerTagGroup": {
    "microservice": "microservice",
    "microserviceId": "microservice",
    "tool": "tool",
  }
}

Note that in this example both cloud tag keys microservice and microserviceId are assigned to the same Software Artifact category "microservice".

  1. Click the button Overwrite all configurations to save your configuration.
  2. Click the button Scan now to start the discovery process. Wait until all scan runs show the status COMPLETED. (Refresh the browser page if necessary.)

Mapping Cloud Accounts to Software Artifacts

The first option is to assign the Cloud tags on the level of your AWS Accounts, Azure Resource.Groups or Google Cloud Projects. This is recommended if a single Software Artifact is managed by one Cloud Account, e.g., Azure Functions being part of an Azure Resource Group that is used for one Microservice.
A relation will be added automatically between the Cloud Account and Software Artifact, which is flagged as Based On: Account Tags.
In addition, a relation between all Compute Environments in that Cloud Account and the mapped Software Artifact will be added as well. These relations will be flagged as Based On: Mapped Account.

Mapping Cloud Resources to Software Artifacts

Another option is to assign the Cloud tags directly on the resource-level. This is recommended if different Software Artifacts are managed within one Cloud Account, e.g., EC2 instances running in a Team-level AWS Account that are used for different team-owned Microservices.
In this case, a relation between the individual Compute Environments and the Software Artifact will be added automatically. These relations will be flagged as Based On: Resource Tags.
Also, a relation between the Cloud Resource's Cloud Account and the Software Artifact will be added as well. This relation is flagged as Based On: Mapped Resources.

📘

AWS only

For AWS, the presence of Cloud spend information within a Cloud Account will also result in the creation of a relation between a Cloud Account and Software Artifact. As soon as for a Cloud Account a non-empty cloud spend has been found for one of the Software Artifacts (identified via a corresponding tag), a relation between that Cloud Account and Software Artifact will be added, and flagged as Based On: Cloud Spend Information`.
In this case, a relation to the Software Artifact will not be added for all Compute Environments in the Cloud Account, since the account is considered to be only partially mapped .

Resulting Relations in VSM based on these Mappings

Once the mapping from Cloud Resources and/or Cloud Accounts to Software Artifacts is established, VSM uses this mapping to automatically various relations to Software Artifacts.

Relations between Software Artifacts and Technologies in VSM

Based on the established mapping between Cloud Resources and Software Artifacts, a relation between the corresponding Technology Fact Sheet (e.g., for "AWS EC2") and the Software Artifact will be added. This applies both for mapped Cloud Resources and mapped Cloud Accounts:

  1. for individually mapped Cloud Resources, a relation will be added for each Software Artifact and Technology for which at least one mapped Cloud Resource has been found
  2. for mapped Cloud Accounts, a relation will be added for the Software Artifact mapped to the Cloud Account, and to all Technology Fact Sheets for which at least one Cloud Resource has been found in the Cloud Account.

Overview on the Resulting Relations

The following table summarizes the different relations and their flagging. Please note that these relations and flagging can be combined, e.g., an AWS Account can be mapped to the same Microservice based on Cloud Spend Information and individually mapped Resources.

Scenario

Relation between ...

... and

Based On

Tags on Cloud Account

Cloud Account

Software Artifact

Account Tags

Compute Environment
(for all Cloud Resources in the Cloud Account)

Software Artifact

Mapped Account

Technology
(for all Cloud Services with at least one resources in the Cloud Account)

Software Artifact

N/A

Tags on Cloud Resource

Cloud Account

Software Artifact

Mapped Resources

Compute Environment

Software Artifact

Resource Tags

Technology
(for the resource's Cloud Service)

Software Artifact

N/A

Cost Allocation Tags

Cloud Account

Software Artifact

Cloud Spend Information

28742874

Example: Cloud Account to Software Artifact Mapping

Browse Software Artifacts in the Inventory

  1. In your LeanIX Value Stream Management Workspace, go to Inventory.
  2. Filter for Type: Software Artifact.
  3. Filter for Data Source Tag: Public Cloud.
19721972

Cloud Software Artifacts in Inventory


Did this page help you?