<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_NEW_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2025-01-20T13:15:11.000Z

LeanIX fact sheet

<div id="content"><p tabindex="0">In the following, you will delve deeply into fact sheets, understanding the sections common to all fact sheets, as well as what you need to know as a LeanIX admin.</p><div class="kalturaVideoLessonWrapper"><div aria-label="Fact Sheet Overview" class="kalturaVideoLessonContainer" data-testid="video" id="1_o1hwttju"></div></div></div>

Fact sheet overview

Attributes

Relations

Learning to Use the LeanIX Tool for Successful Enterprise Architecture

This video explains the sections you will find in fact sheets, how to maintain the quality seal, subscribe to fact sheets, and modify fields. Learn more in this informative lesson.<br><br># This description was auto-generated #

12. Fact Sheet_1.mp4

In this lesson, we will do a deep dive on fact sheets and explain the sections you will find in all fact sheets, as well as what you need to know as a Linux admin. As a recap, in Linux, each asset of your organization's enterprise architecture is documented in a fact sheet. Fact sheets are used to document and save information regarding architectural objects like the one you just saw, applications, business capabilities, or IT components. With a fact sheet, you can keep all relevant information on a single page and at the same time maintain the dependencies within your IT landscape. Each fact sheet stores specific information to that fact sheet. This is the basic structure of all fact sheets. Starting at the top, first you can see the fact sheet name, fact sheet type, tags, and the fact sheet description. To the right you can see the quality seal. The quality seal is a tool for you to maintain and improve the quality of the fact sheet. You can set the quality seal as draft, approved, or broken depending on the state of of the fact sheet. Next to the quality seal, you can see the subscription role. Here, the users can subscribe to the fact sheet. For example, as application owner or any other custom subscription role that you have defined as an admin. Depending on the permission role, for example, as an admin, you can see other features such as creating a new fact sheet and cloning fact sheets next to the subscription role. Next, you will see the fact sheet information itself. Here, you can see that there are multiple tabs such as fact sheet, subscriptions, comments, to-dos, resources, and others. We will take a look at other tabs in the next lesson. And here we will focus on the fact sheet tab. In the fact sheet tab, you can see relevant information about the fact sheets. These information items are different per fact sheet type depending on the relation to other fact sheets. Those items are called attributes. However, there are default attributes that are available for all fact sheets. For example, you can see that the information section that contains the name, description, lifecycle, and relations to other fact sheets, such as successors and predecessors. All the relations are shown via the relation explorer. This section is available for all fact sheet types. You can also see the dependency section on every fact sheet. This section contains the parent and children relation of the fact sheet. Also in Linux AAM, you can always modify which fields you want to see in your fact sheet. To do that, you click on this icon and click configuration. Here we will see the whole structure of your fact sheet. You have the flexibility to change the field's name, hide or show, or reorder sections and many more. You can check out our documentation page in the resource tab to see in more detail what you can do in the meta model configuration.

Learn about the different attributes and their importance in fact sheets for enterprise architecture. Discover how to assign responsibilities and fill out the necessary information.<br><br># This description was auto-generated #

13. Attributes_2.mp4

In the previous lesson we learned that each fact sheet type has its own attributes. In general, an attribute can be defined as a characteristic or property that provides additional information and context about the various elements within your enterprise architecture. Attributes are represented as fields in the fact sheet in Linux that you would want to be documented and maintained for your analysis. Admins can configure attributes and can adapt help text. It is important to know that by default attributes count towards the completion score of a fact sheet. So think wisely as an admin which attributes you want to capture and what is irrelevant to keep your stakeholders engaged when filling out fact sheets. Let's explore this in detail by looking again at the application fact sheet since this is the first one you should focus on when building your inventory. So let's look at the main attributes that you need on that fact sheet type. Before jumping into the fact sheet it's important to identify the right people to actually fill out that data that is listed in the fact sheet. So assigning the right stakeholders as subscriptions is crucial. This allows further follow-up steps, such as executing surveys, to ensure the critical data is actually collected. Next, we need an application name. Fact sheet name is found in the header, as well as the name and description field at the top. While the description is technically not required for the reports to work, it is ideal to provide descriptions for all applications to avoid duplicates. It also makes it clear which application is used for a WITS purpose. Second, we need to lifecycle information. Lifecycle information helps us determine whether an application is in the early states of an implementation, in production, or whether it's being phased out and no longer in use. The different lifecycle stages are all editable and you can specify them to your needs. At the start, you might not have all the information about your applications, lifecycle stages, and that is okay. You can populate these as you go, as you venture further into utilizing Linx for different use cases. However, as a minimum, we recommend that you specify the active state and ideally provide a rough estimation for when your application will reach the end of life. If you have these lifecycle stages defined, there's a nice roadmap report that you can use to analyze your application's life cycles. Third, we need the business criticality, functional fit, and technical fit attributes. These attributes help us understand how well an application supports your operations, strategy, and business overall. Business criticality attributes can be found under the Business Support section, along with the Functional Fit. Business criticality answers the question on how critical the given application is for your business. Therefore, you can classify your assets in terms of the appropriate service level and disaster recovery requirements. From the options in the dropdown, you can specify whether your asset is mission critical and cannot be down at any time, or if it's more of an admin service that does not impact customer experiences all that much. This attribute is available by default and offers a standard set of options to choose from. Business criticality is often used in combination with the functional fit to gauge the fitness of your application landscape. Therefore, functional fit is the next key attribute that you should look to bring in. The functional fit attribute indicates how well a certain application meets the set business requirements now and in the future. You can set the functional fit attribute to anything between unreasonable and perfect. Technical fit indicates the degree to which an application meets the technology standards established by IT in order to support an appropriate level of functionality to meet the business requirements. So for example, if this is something that runs on outdated technology and contributes to suboptimal business outcome, then the technical fit for this application should be inappropriate. On the other hand, if you have a piece of technology that supports the business well and is a technologically optimized solution, you would mark it as fully appropriate. While the technical fit is not the first attribute that we recommend you to populate, It serves a purpose and usually gets defined in the later stages of your fact sheet definition. Our guidance here is that if you don't already have this metric defined for your applications, it might be worth considering bringing in this data via surveys, which we will discuss at a later point in time. Having the technical fit information filled out will help you identify applications that do not meet your technical requirements to accomplish the business objectives. Fourth, we need to provide business capabilities. These will help determine the application's business purpose and allow it to be visually mapped in various reports. Last but not least, defining responsibilities is also super important. Assigning responsibilities to the fact sheet in Linux can be an effective way to encourage ownership and visibility into who's responsible for which fact sheets. For example, if we look at the subscriptions tab of the Linux application fact sheets, we can see that Paula Watson is specified as responsible. In this role, Paula can track and approve or reject changes submitted to the fact sheet. If you want to edit Paula's subscription for the fact sheet, select the pencil icon and change the type or role as needed. Then hit save. Alternatively, you can delete Paula from the list of subscribers by hitting delete subscription. Another role that a person can be assigned to is that of an observer. An observer is anyone who's interested in a fact sheet, but not actually accountable for it like the responsible. Just like responsibles, observers can edit fact sheet information. Apart from these roles, you can also create custom subscription roles as per your requirements. To add a new subscriber to the fact sheets, click the add person link. Fill out the form and hit save. You will explore more about subscriptions in later courses, but for now, know that the subscriptions is where you can find and assign responsibilities for your fact sheets.

Learn how to use tags and tag groups to classify and enhance the filtering of your applications. Discover best practices and step-by-step instructions on creating and assigning tags.<br><br># This description was auto-generated #

14. Tags_2.mp4

Tags and tag groups are another way to capture information similar to attributes and contextualize your applications. However, they are more lightweight than attributes, meaning that no configuration is needed to create tags. You would use them, for example, in strategic initiatives where you want to classify applications according to a classification system of your choice. Keep in mind to use attributes via the custom fields instead of tags for all information you want to capture in general in the Feqty type. Once applied, tags and tag groups help you classify your assets by adding a label that is visible at the very top of a fact sheet and is hence more prominent in that sense than an attribute. In addition, tags can be used to enhance the filtering of your inventory and to highlight relevant fact sheets in your reports. Here are some best practices for using tags. Using no more than five to seven tag groups per fact sheet type. Use them for the most important and most prominent attributes, for example a strategic initiative, an SLA classification, or any other clustering across faxitypes. Use tag groups if they have a finite number of possible elements, less than 10. Use tags to depict a relatively temporary status, since it's easy and convenient to add and remove tags and entire tag groups. And this is how you create tags. First, you will need to create tag groups. Tag groups, as the name implies, are a way to group your tags logically. You can access tagging options by going to the profile icon and selecting administration. Note that you will need to have admin role privileges in your workspace to do so. Here are where the various tag groups are defined. For example, if we take a look at the service level agreement or SLA tag group, we will see that this tag group consists out of gold, silver, and bronze, which indicates how the service SLAs are defined. To create a new tag group, click on the new tag group button and add a meaningful name and select the faxitype you want this to be applied to. Here you can select a mode. For the mode you have two options, single or multiple. multiple. Single mode allows you to assign only a single of this group to effect sheet. The multiple mode allows you to assign multiple tags of this tag group to effect sheet. However if you select the multiple mode it will not be available as a view in the reporting. So our recommendation is to utilize the single mode tag groups wherever possible as they enable some powerful reporting. Once you're happy with your tag groups click add. Once we have your tag group created we can add some tags to it. Before we do so let's take a look at our or isolate tag group example and click on one of the tags. We can see that this tag has a clear name and a description of what the tag means. Specifying both of these is really important as attributes such as the tag name will show up in the reporting. The tag description will show up when hovering over the tag in the inventory. After we create a tag group, we can start placing tags into it. Assigning a color to your tag can also be quite powerful as it will make the tag stand out from the rest. This can serve as a powerful visual differentiator in reporting and when looking at individual fact sheets.

Learn about the different types of relations in Linux fact sheets and how they can help you navigate and structure your enterprise architecture.<br><br># This description was auto-generated #

15. Relations 2.mp4

In Linux, understanding relations between fact sheets is essential. Today, we'll explore the three distinct types of relations in Linux fact sheets, helping you navigate this landscape. At the core of Linux, on top of the explicit relations connecting two specific types of fact sheets, for example, business capability and applications, you'll find three types of relations between fact sheets. Let's break them down. One, hierarchical relations. Think of these as organizational structures that resemble trees. It's all about parent and child relations. A child factory can only have one parent, but a parent can have multiple children, creating a structured hierarchy. For instance, in the context of organizations, you can create a regional structure like Europe, Western Europe, and the Netherlands, with each level signifying a different parent-child relationship. These relations are perfect for creating clear structures such as regional hierarchies or tech category classifications. For a start, we recommend working with a flat hierarchy and using relations only where it's really necessary, for example, to reflect your organizational architecture. Implementing many hierarchies from the beginning will make your architecture and maintenance of data a very complex undergoing and might not necessarily add any value at all. Two, generic relations. These are versatile relations that can connect any type of fact sheets. An excellent example is the requires required by relation. It's a logical dependency that allows you to establish connections within one fact sheet type or across different types. Within the same fact sheet type, consider a server requiring an operating system. These are both IT components, but only the server is directly linked to the application. However, using logical many-to-many dependencies, you can deduce that the operating system is indirectly linked through the server. These help establish logical dependencies, like how a server requires an operating system or to document relationships between different fact sheet types. 3. Other relations, also known as transitive relations. These are indirect relations that connect fact sheets, which are not displayed on the fact sheet itself. Instead, you might discover them in the Relations Explorer. They facilitate transitive connections, allowing you to read fact sheets indirectly. Imagine the level 2 business capability, Employee Lifecycle Management, connected to its parent, HR. This indirect relation is responsible for including the children of HR when you filter for business capabilities associated with a specific initiative. Understanding these relations will empower you to structure, document, and uncover hidden dependencies in your enterprise architecture.