Getting control of your infrastructure portfolio can be a major effort. There are multiple goals and priorities that drive the detail needed in an infrastructure landscape. Some organizations have IT Operations with their own infrastructure management tools, importing information to link it with the rest of the enterprise architecture. Other organizations are at a different stage of their journey and are looking for basic management capabilities in addition to linking with other enterprise architecture information. Although Ardoq offers solutions for both of these audiences, not all recommendations may apply equally in every situation. We offer a recommended starting point for your metamodel, which you can customize based on the information and insights that you want to develop.

This simple Infrastructure metamodel will give you the data you need to provide some basic management capabilities, plus the ability to link infrastructure information with other enterprise architecture information. This generates insights and enables decisions. It also provides a great foundation for future infrastructure initiatives like application hosting, application modernization, and cloud migration.

Server Component Type

The core concept is a Server, a server is just a computer without a screen. A server, as Ardoq sees it, is a unit of computing dedicated to managing network resources. Servers may be specialized by a function depending on their hardware configuration or by the software products on them. Servers may be virtual or physical but ultimately, a physical server underlies any configuration.

Ardoq’s concept of server component type can similarly be compared to the ArchiMate concept of a Device.

It’s difficult to model everything. This model covers the majority of our customer situations, but your context may be different. Having a single component represent an entire infrastructure landscape might be too simplistic, depending on your organization. Ardoq offers robust modeling flexibility, allowing modifications to the model to account for greater complexity.

Node Component Type

Ardoq defines the concept of the node component type as an abstracted object for grouping logical, computational, or physical resources that host, manipulate, or interact with other computational or physical resources. Similar definitions can be found in standards like ArchiMate. The node component is used in a hierarchical structure with resource components acting as children components. For example, the node below “SAP Reporting Cluster” represents a collection of servers that are implemented for similar purposes:

Location Component Type

The location component type (part of the location workspace) is used to represent where the infrastructure component is located. If these are physical assets, they will be located somewhere and oftentimes there is cost and consumption with that location. It is important to understand where these assets are located to efficiently manage them.

The organizational unit component type decomposes into business units, departments, sub-organizations, committees, teams, and groups to enable the creation of organizational hierarchies. This can often take the form of both structural (hierarchical) and functional entities within an organization which can all be documented by utilizing the Organizational Unit component.

Now let’s look at the key properties of the server we’ll need to drive lifecycle management.

Basic but very important are a Name and a clear Description. Name should be unique wherever possible, and the Description gives others some idea of what the server does or what it supports.

Now we need to capture those Lifecycle properties we’ll use as the basis for managing our infrastructure.

Lifecycle Phase determines the status of the server. Here are the lifecycle phase values and how they apply to the server component type. Implementing for when the server has been acquired but not fully installed. Live for when it is installed and running. Mainstream for when the server is running and being utilized. Phasing Out for when a server is no longer in use but is kept for historical reasons, and Retired for when the asset is completely decommissioned. This value should be populated from your source of record. E.g. Status or State if you are integrating with ServiceNow

This property alone enables you to answer the simple but important question “how many active servers do we have?”

A more refined view of lifecycle comes from filling dates in the Live data range field, where the first date is the date on which the server went (or will go) into production or use, and the second date, is the date on which it was (or will be) retired, or its use discontinued.

Having these dates is critical in enabling IT planners to see when changes in their server landscape will happen. For example, when server counts or costs will change, knowing when things will happen is a key element of controlling your servers.

By now, you may be looking at these dates and wonder how you’re going to populate them. It might be possible to discover when a server was introduced with a bit of digging.

For servers that you cannot determine the dates of, our advice is to use default Live Start and Live End dates at an appropriate point in the past/future (for example, Live Start = 01.01.2010, Live End = 31.12.2040). You can change those defaults once you know more. We recommend this because these date field values are needed to populate various visuals within Ardoq.

The Total Direct Cost property is there to capture the total annual run cost or the CAPEX associated with the server. It is calculated by combining the OPEX and CAPEX fields on the server component. At this point in your journey, it’s a very simple number, but this cost concept will be expanded in more detail in the IT Cost Management journey. You can also read more about the IT Cost Model here.

Without some view of cost, you may struggle to engage your senior audience. That being said, it is equally important to make it very clear at this stage that all costs are estimates. This avoids getting bogged down in financial reconciliation discussions at this point.

Approved and Review Date are the last two properties that can be brought in from your source of record. We don’t recommend trying to populate these values if they don’t already exist.

They are there to support governance workflow. Approved is a property that means the server has been reviewed and approved for inclusion on your lists by an owner.

You have the option to filter by this property in your views and dashboards to exclude any servers that haven’t been through a ‘quality check’ process. As you open your server lists up for contribution, you’ll get a certain number of servers that are duplicates, parts of other servers, or not servers at all. That Approved property is the key to giving your stakeholders confidence in your data quality.

Review Date is an optional property that enables you to prompt when an action or decision is required for a specific server. You can populate this property with a specific date, or alternatively use the scheduling function in the Broadcasts module to trigger server data refreshes or time-based alerts.

Let’s use this time to dig deeper into the details around the infrastructure. It is recommended that most server details come from your source of record/CMDB. There potentially could be hundreds or thousands of servers, and collecting this information at an individual server level via survey could be extremely time-consuming and is therefore not recommended.

Server Hosting - This field is used to capture how this server is hosted. Some servers are physical, while others might be virtual. The default options are; Physical, VM, Container. This is useful because you can segment your infrastructure landscape between virtual and physical servers and compare it to things like cost, risk, or utilization.

Server Type - This field is used to capture what type of server this component is. The default options are; Application Server, API Server, Database Server, Mail Server, File Server, Web Server, FTP Server, Proxy Server. It is often useful to categorize costs or incidents per server type.

Network Zone - This field is used to capture and understand where the server is located. The field by default has three options; Internal, Public, DMZ. This can be useful when mapping incidents or security policy compliance.

Hardware Details

CPUs and CPU Utilization (Peak), Memory and Memory Utilization (Peak), Storage and Storage Utilization are all optional server properties that can be pulled in from your source of record to help you understand how your infrastructure is being used, where demand is, and where there are opportunities for cost savings. While this type of information can be captured and used to create dashboards and heatmaps and perform analysis around cost, quality is not critical at this point, so don’t worry if these values remain empty. You can also change or delete these fields based on your needs.

The other key points of data capture are done by connecting references between each server and other components. References ensure data quality by ensuring data consistency by avoiding duplicating data in your model.

The first reference is the Located reference between one server and a location. For example, Server A is Located in the Oslo Data Center.

Mapping these references is important when trying to analyze where you have a managed infrastructure footprint and site utilization. This also helps when allocating site costs if you have cost information available.

Next, we have a reference type between the Server and the Organizational Unit component type. This reference represents departmental responsibilities towards the server. Owns represents the person/department with formal responsibility for the server. Typically, this will be the manager or team who is responsible for building or provisioning the server, but this isn’t always the case. The owner should be the department/team that recognizes that they have that responsibility.

Lastly, we have the Deploys to reference type that goes between the server component type. This reference type is used to reflect the relationship that exists between virtual machines and the physical hardware assets that they are deployed on. Mapping these references is important in understanding how physical hardware refresh cycles could impact applications that are running on VMs.

💬 We're always happy to help. Feel free to reach out to us via the in-app chat if you have any follow-up questions to this article.

A list of changes made to the article are listed below:

March 25, 2022