HomeDocumentationProduct UpdatesProduct Roadmap
Request DemoWebsite

IT Component

Suggest Edits

šŸ“˜

These modeling guidelines are for the Meta Model v4. For Meta Model v3 guidelines, see Modeling: IT Components / Hosting.

Definition

IT Components represent the technology (software and hardware) or services an organizationā€™s applications depend on, and they can provide information on both, development and operations.

Description

IT Components are powerful for getting crucial insights for obsolescence risk management, operating costs, and managing other risks such as provider/location/outage management. In addition, you need IT Components to drive, e.g., your organizationā€™s cloud strategy.

IT Components are building blocks of Applications that run, maintain, and change Applications. They donā€™t directly support Business Capabilities. They are offered by Providers and grouped into Tech Categories for standardization.

Overview of all relations to/from Application:

IT Component Fact Sheet subtypes

IT Components have six different Fact Sheet subtypes in LeanIX:

  • Hardware: Hardware refers to the physical components of a computer system or any IT device. It includes tangible, touchable parts you can see and interact with (e.g., servers, mainframe computers, storage devices).
    Examples: IBM z15, HP ProLiant DL560, Dell EMC PowerEdge R750, NetApp AFF A900.
  • IaaS: IaaS (Infrastructure as a Service) refers to virtualized computing resources provided over the internet.
    Examples: Amazon Web Services (AWS) EC2, Microsoft Azure Virtual Machines.
  • PaaS: PaaS (Platform as a Service) refers to cloud platforms for developers to build and deploy applications.
    Examples: Google App Engine, Heroku, Salesforce (PaaS)
  • SaaS: SaaS (Software as a Service) refers to software applications accessed over the internet on a subscription basis.
    Examples: Salesforce B2B Commerce, Atlassian Confluence, LeanIX
  • Service: Services refer to the provisioning of services related to IT components (usually provided by a 3rd party). These are so-called managed IT services used to implement or run an application, which is not cloud services, software, or hardware. It involves activities like management, maintenance, or support.
    Examples: Maintenance/Support Service, IT Transformation Services, Public Cloud Transformation Service, Hosting Service, Analytics Service (e.g., Accenture managing Application Support, Nordcloud managing AWS Hosting).
  • Software: Software refers to commercial or open-source software products that your application relies on, e.g., Operating Systems or Programming Languages.
    Examples: Microsoft .NET Framework 4.8

IT Component Examples: Chrome, Microsoft .NET Framework 4.8, Windows Server 2022

šŸ“˜

For a step-by-step guide to create the Fact Sheet subtype, see Create Fact Sheet Subtype.

Guidelines and Best Practices

  • Firstly, for the initial LeanIX Application Portfolio Assessment, you donā€™t necessarily need IT Components when you start working with LeanIX.
  • Model IT Components if you, e.g., want to manage your providers (there is no direct link between Application and Provider, IT Components need to be modeled to establish a relation to Providers) or if you require information on the hosting location of your applications.
  • Model IT Components if you require this information for a specific use case/ company strategy, e.g., cloud migration assessment (see example below).
  • Import VSM Tech Stack as IT Components if you want to manage the Technologies used in your self-built Applications (e.g. Frameworks, Programming Languages, Runtime Environments, and Infrastructure)
  • Use the SaaS Catalog to automate the creation of IT Component and Provider Fact Sheet subtypes for SaaS services (modeled as Application in LeanIX as described here). Even if you are a SaaS-based organization, there might be use cases in the future where you need it; having them in the inventory doesnā€™t cost any harm and doesnā€™t add more effort (However, if you are 100% sure that you want to keep your inventory lean, you can deactivate the automated creation of IT Components and Providers in the SaaS Catalog).
  • Describe cloud components first using the SaaS, IaaS, and PaaS Fact Sheet subtypes. Note that SaaS here relates to the hosting type of the Application.
  • We recommend grouping IT Components into Tech Categories to provide context to stakeholders unfamiliar with the product or service. The TBM Taxonomy can be used for that, as this is an established industry standard maintained by a renowned community (.
  • IT Components can also be imported via Excel (CMDB data export). This is only recommended in the case of a limited number of IT Components. An import via the out-of-the-box integration with ServiceNow is also possible. To use the ServiceNow integration, you will need LeanIX Technology Risk and Compliance in addition to LeanIX Application Portfolio Management.
  • Make sure in this process to normalize the IT Components to a high level before importing them to LeanIX. By normalizing your IT Components, we mean standardizing the names of IT Components and also aggregating them to more meaningful items, e.g., aggregating all versions of a Software to one major level version - which for any strategic planning is usually good enough. Currently, this step needs to be done manually, e.g., if you use a CMDB (Configuration Management Database), normalization of the versions and names is required ā€“ a service that LeanIX does not offer at the moment.
  • We recommend keeping the number of IT Components low at the start of your LeanIX journey. While it might be tempting to import everything - and possibly people in your organization suggesting that - you will have to maintain a lot more data and blow up any reports on IT Components.
  • In general, you use IT Components to model technology, not explicit instances of items. E.g., patch-level versions of software do not add any value to your EA work and strategic discussions with your stakeholders.
  • If you need to model instances because they add value (decide if you get business insights from that modeling or not), you will model those typically as an IT Component. Some scenarios where this might be relevant are:
    • Varying hosting options (e.g., the same software is provisioned via Azure and via AWS).
    • Two business units host applications on various instances.
    • Instances for different purposes (test, production).
    • If it is the same version, it should be one Fact Sheet (as a rule of thumb).
    • When using the ServiceNow integration and there is a value in mapping ā€œApplication Servicesā€ from ServiceNow to LeanIX, we recommend mapping them to the optional Deployment Fact Sheets (a subtype of Application).
  • If you want to model costs in LeanIX, this can be done on the Application Fact Sheet in LeanIX, on the relation between the Application and IT Component (see this documentation for more information on Cost Management).

Antipatterns

This section addresses antipatterns involving ineffective or counterproductive ways of modeling IT Components in LeanIX.

  • Donā€™t introduce too fine-granular versions of IT Components (e.g., patch level of software).
  • Donā€™t confuse SaaS as a Fact Sheet subtype under the IT Component with SaaS as an Application. Generally, SaaS (the software that end users interact with) is modeled as an Application. The IT Component Fact Sheet only describes the hosting aspect of that service.
  • Donā€™t import all instances of deployments.
  • Donā€™t import all technologies before linking them to Applications. Only import technologies that you really need.
  • Donā€™t confuse Service with SaaS or Microservice Fact Sheet subtype.
  • If you use the Lifecycle Catalog (LeanIX Technology Risk and Compliance product is required), donā€™t aim for 100% coverage of having all items linked to the Lifecycle Catalog; start off with your most important IT Components by filtering on the IT Components of critical and important applications.

Applicable Use Cases

Obsolescence Risk Management: The IT Component Fact Sheet comes into play and makes the most sense if your organization needs to manage risks and get visibility of the technology that your enterprise architecture relies on. There are also compliance-related scenarios in which it will be relevant to understand and track who provides your technology and where it is hosted.

Insights from IT Component Fact Sheet

Modeling the IT Component (along with the Provider) Fact Sheet will allow seeing costs broken down by providers (Provider Cost Report) and getting an overview of which IT components and applications are used by user groups and their location on a world map (using the World Map Report). Check out more in this Reports documentation.

Further Resources

Updated about 1 month ago