Modeling: IT Components / Hosting

📘

Important Information

This page is a modeling guideline for Meta Model v3. Updated guidelines for Meta Model v4 is available in the documentation.

1.) The entry-level approach

Especially in the first few weeks, we recommend beginning with a simple approach:
• Use tag groups to model IT components, e.g. create a tag group “Application Hosting” and assign values such as “On-Prem” / “SaaS” / “PaaS” / “IaaS”.
• Assign colours in relation to your IT strategy, e.g. if you have the paradigm to go "cloud-first", color “On-Prem” red.
• The "Application Hosting" view of the Application Landscape and the Application Matrix reports will provide you with an immediate overview.
• Filter the Application Roadmap report by tag group, e.g. to show all lifecycles with “On-Prem” applications in case you want to decommission them.
• Assign the tags to your Application Fact Sheets manually or via the .xls upload.

The following screenshot shows an example of leveraging the entry-level approach:

2.) The pragmatic approach

There are some important questions that the entry-level approach does not answer, e.g.:

1. What kind of hosting services do I have?
2. Who is responsible?
3. What kind of services do I want to keep, what do I want to decommission, and how?
4. Which costs and SLAs are assigned to hosting services?

If you want to make sure this information is included, use the pragmatic approach:

• Create IT components of the sub-type “service” and assign them to your applications.
• Group the IT components by summarising those with shared responsibilities and lifecycles, e.g.:
  • Application hosting, On-Prem, SLA: Gold
  • Application hosting, On-Prem, SLA: Silver
  • Application hosting, On-Prem, SLA: Bronze
  • Application hosting, SaaS, e.g. LeanIX, SAP Signavio
  • Application hosting, PaaS, e.g. force.com, ServiceNow
  • Application hosting, IaaS, e.g. Amazon EC2, Microsoft Azure
• Try to keep the number of IT Components at this stage as low as possible, e.g. summarise all on-premise hosting services into only a few IT Components to keep the maintenance effort low.
• Assign a responsible, a support lifecycle, a value of a tag group (e.g. “Strategic” / “Tolerate” / “Eliminate”), and a technology stack to each IT Component.
• Create IT components manually or using the .xls import.

This will allow you to retrieve the following insights:

• Assess your IT Component landscape to determine the degree of cloud adoption. For example, IT Components tagged as "Eliminate" are not well suited to the cloud.
• Filter the IT Components by hosting type, e.g. show all Applications hosted on AWS EC2 in the Application Roadmap.
• Conduct a high-level-analysis using the visualizer, e.g. what happens if force.com has a downtime.
• Allocate costs to IT Components and assign them to Applications and Business Capabilities. Using the Business Capability Cost report, this will allow you to analyze the distribution of run costs.
• Even if you use IT Components to model hosting, consider keeping the "Application Hosting" tag group on the Application Fact Sheet. Although redundant, it keeps the hosting prominent, e.g. on the Application Landscape and Matrix reports.

The following screenshot provides an example of using the pragmatic approach:

3.) The full-fledged approach

If you want to look into further details, you need to distinguish between hosting options and introduce IT Components categorized as “Software” and “Hardware”.

📘

Information

The lifecycles of hardware and software IT Components can be obtained and maintained via the reference catalog.

Here are some best practices for on-premise and cloud hosting:
a) On-Premise
Typical questions for on-premise software are:
• Who is responsible for the software development and maintenance?
• Which software versions are used? Do they impose technical risk?
• Which hardware versions are used? Do they impose technical risk?

Typically, an Application is linked to more than one IT Component classified as “Software” or “Hardware”. For example, it may be connected to a database running on one type of hardware and an application server running on another.

Customers typically apply one of two scenarios:
a1) IT-Services: Link the Application Fact Sheet to only one "Service" IT Component, e.g. "Application 1 Hosting & Maintenance". Link Software and Hardware via "required" to this service. Manage the aggregate cost for all IT Components on this one service. This makes it a lot easier for the Application owner since it is still possible to analyze and consolidate the provided services via the Technology Risk and Cost views on the Application Landscape / Matrix reports.
It allows for the mapping of IT Components to a cluster (e.g. SAP Application Hosting and Maintenance) that are not directly related to the Applications but support other IT Components.

Here is an example of applying the full-fledged way:

a2) Directly linked to. Applications: Link the Application Fact Sheet directly to IT Components classified as Software and Hardware. This increases the expressiveness of the Application Fact Sheet but also the amount of work for the Application Owner to collect data initially and keep data quality high.

The following screenshot provides an example of using the full-fledged way:

👍

Best Practice

If in doubt, start with option a1) to simplify the task of the Application Owner. Move only to a2) if it adds concrete value.

b) SaaS:
Since the entire service is provided by one vendor (e.g. LeanIX), managing hosting is the easiest with SaaS solutions. One "Service" IT Component with lifecycles, responsibilities, costs, or SLAs attached is sufficient.

The following screenshot shows an example for using the full-fledged approach for SaaS applications:

c) IaaS and PaaS:
IaaS and PaaS solutions typically require a Provider (e.g. Amazon Web Services, Salesforce) as well as the deployed software. A best-practice set of IT Components for one application includes the following:
• a "Software" IT Component to manage the deployed version (incl. link to the reference catalog, if available),
• a "Service" IT Component linked to an internal or external Provider to manage development & maintenance,
• a "Service" IT Component usually linked to the same Provider to manage hosting.

In contrast to case a), the number of IT Components is generally limited to these three. Furthermore, these questions can typically be answered by an application owner. In these kinds of cases, directly linking Fact Sheets is good practice since it combines expressiveness and maintainability.

The following screenshot shows an example of using the full-fledged approach for IaaS and PaaS Applications:

🚧

Attention

Be careful when using interlinking the three IT Components. This often creates more confusion than value. In many cases, linking Software to Hosting Services via the Application is more than sufficient.

👍

Best Practice

Consider keeping the "Application Hosting" tag group on the Application Fact Sheet or tagging the Hosting Service IT Components similarly. Although redundant, it keeps the hosting prominent.

Q&A

Q: Why use "requires" instead of "parent/child" to create relationships between IT Components?
A: The "requires" relation is evaluated in the Technology Risk view. It also allows you to capture n:m relations which is not possible with parent/child.

Q: For IaaS / PaaS with multiple hosting options (e.g. the same software is provisioned via Azure and via AWS), should different IT Components be used?
A: Only use different Fact Sheets if it adds concrete value. If it is the same software version, it should be one Fact Sheet (as a rule-of-thumb).

Q: Should I model instances of IT Components?
A: Generally, it is good practice to stick to classes (e.g. "Oracle DB 11.2" as Software instead of "Oracle DB 11.2 hosted on AWS instance XYZ"). The effort to maintain instances is much higher. If there is a concrete business case, consider using Configuration, e.g. to create a new Fact Sheet Type "Instance" to keep expressiveness high.