Application Hosting is an essential building block of Application Lifecycle Management (ALM) and is crucial to understanding your overall IT landscape.

After you have completed the step of documenting Application Hosting in Ardoq, you can increase your IT landscape's overall quality and efficiency by utilizing the Application Lifecycle Management use case.

The Application Hosting (AH) metamodel illustrates how organizations can document the relationship between applications and infrastructure components. Application Hosting aids in providing visibility, clearly showing the dependencies between applications and their connected on-premise and cloud infrastructure. Ultimately, it improves the overall management of enterprise complexity and enables efficient change planning.

Application Hosting assists organizations in answering the following questions:

Additionally, Application Hosting is a foundational element of Application Portfolio Management (APM) and Application Lifecycle Management (ALM).

There are many combinations of SW application types and associated hosting infrastructure. Servers, virtual machines, containers, application containers, middleware, multi-tenant SaaS, cloud-native apps and infrastructure, cloud-native PaaS components, IaaS, etc.

This version of the Application Hosting Use Case Guide sets the scope to the most common types of application hosting. The scope consists of traditional on-premise hosting and public and private cloud Infrastructure-as-a-Service (IaaS) techniques.

Subsequent versions of the guide will offer more explicit guidance on modeling Platform-as-a-Service (PaaS) and cloud-native application hosting scenarios. A limited scope allows us to test and evaluate our criteria within that scope, allow faster publication of the guide, and have feedback for subsequent iterations.

Our rationale for the hosting metamodel is to handle the broadest set of hosting scenarios possible with the minimum number of metamodeling concepts. Learn more about this principle in our Principles of Creating a great Enterprise Architecture Metamodel.

Metamodel concepts need to be abstract in order to handle such a wide range of situations. The broader range makes the metamodel applicable in more situations, however, it also may take more time to initially understand. Having more specific metamodel concepts for each hosting scenario improves initial readability but requires more costly maintenance. According to our principles, this is an acceptable trade-off. Other generic approaches in the industry also accept this trade-off, such as Terraform configuration language for modeling generic hosting infrastructure-as-code. Indeed, the Terraform language significantly inspired our metamodel.

Gaining control of Application Hosting can be a major effort, we strongly advise starting with a small number of essential properties and leveraging application owners to provide data. This way you can avoid going through an extensive data capture process.

Ardoq recommends modeling Application Hosting as explicit connections between applications and either technology services or servers as seen below.

In the case of Application Hosting, there are several offerings when it comes to private and public cloud service providers. To keep the data sets clear and delineated, Ardoq recommends that each provider’s data set be captured in their own workspace as seen below.

This section will walk through the different component types, fields, and reference types that make up the metamodel for Application Hosting.

At the heart of Application Hosting is the Application Component. As covered in greater detail in the Application Lifecycle Management Metamodel article, an application is the configuration of lower-level software or technology to provide specific business capability or technology capability, perform a defined task or analyze specific information.

All applications should have a Name, and that name should be unique wherever possible. Having an accurate Description is also very valuable as it should give others some idea of what the application does.

Now we need to capture relevant hosting properties that we can use to understand the composition of our applications.

Hosting Type allows application owners to capture how an application is delivered to the enterprise. Determining whether an application is hosted on-premise, in the cloud, desktop delivered via SaaS, or hybrid enables future rationalization discussions. It also allows IT leaders to view the percentage of applications hosted on-premise, in the cloud, or hybrid, which can assist when discussing risk associated with critical applications.

In mapping out your infrastructure, the physical location is an important consideration to aid in consolidation, cost management, and risk management.

Servers that are deployed in-house or at third-party data centers and are managed by your organization are considered to be on-premise infrastructure.

The services provided by public cloud vendors such as Amazon AWS or Microsoft Azure are categorized as a technical service component, including storage, compute, and related cloud-based infrastructure. Technology services are a realization of an underlying product (Technology product) from a respective cloud vendor.

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

Ardoq thinks of a server as just a computer without a screen. As Ardoq defines a Server as a physical or logical processing unit that supports an Application, Application Module, Technology Service, or other Server components. Ardoq’s concept of server component type can similarly be compared to the ArchiMate concept of a device.

Additional Server Component Metadata

In the IT lifecycle management use case, we collect some additional metadata fields on the server component.

Server Hosting

This field is used to capture how this server is hosted. Some servers are physical, while others might be virtual. 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. Application Hosting focuses on showing the relationship between virtual and or physical infrastructure and applications. While physical infrastructure will be easily documented as physical. Virtual infrastructure (Technology Service components) can share the same field but will be captured as VMs, Containers, or other types of virtual infrastructure.

Server Type

This field should reflect the high-level function the server fulfills in the overall infrastructure. This would typically be an application server, database, web, etc.

Network Zone

This field is a high-level designation to reflect whether a server is internal-facing, public-facing, or hosted in a DMZ. This field shows where an individual server is located relative to the rest of the infrastructure. To capture the specific network segment, subnet, security, or administrative zone you should create a reference to the relative Network Zone component.

Deployment Environment

The Deployment Environment is captured on the server to illustrate what environment the application is deployed on the infrastructure. In the example below, the application is supported by several servers and one deployment is a test environment while others are production.

This is essential to ensure we understand the context of where the component operates. It can be used to determine the operational risk, the criticality of the service, and provide visibility of individual parallel environments.

In the What is an Application? Modeling Complex Business Systems article we cover some of the key differences between a Technology Product and a Technology Service. A Technology Product is an item of software, hardware or firmware available for deployment. This is a catalog entry, not a deployed running instance. A Technology Service is the component we use to represent a specific instance of technology that you use to host your applications.

Additionally, the services provided by public cloud vendors such as Amazon AWS or Microsoft Azure, are categorized as a technical service component. This would include storage, compute, and related cloud-based infrastructure as well as things like your organization's own VMs, containers, platforms, and other technologies. As mentioned, technology services are an instance of an underlying technology product.

Technology Service represents a component that provides technology support or hosting services for an Application, Application Module, Server or other Technology Service components. Examples include deployed instances of database management systems, virtual machine platforms for operating systems or applications, RPA and workflow platforms, data warehouses, BI and reporting platforms. If the component would be recognized by business users as a business system in its own right, it may alternatively be represented with an Application component. The example below illustrates that the Payroll Application VM is a technology service instance of the cloud infrastructure service AWS EC2.

A Technology Product is an item of software, hardware or firmware available for deployment. This is a catalog entry, not a deployed running instance. It has Deploys To reference links to deployed running instances. It allows version, licensing, vulnerability, lifecycle, vendor, and manufacturer information to be held once rather than replicated with each deployed instance. The catalog is typically organized in a hierarchy of Folders with leaf nodes as Technology Product components to represent specific versions, releases and builds. Composite Technology Product components may be defined representing standard “builds or stacks” containing multiple Deploys To references from other Technology Product components (e.g. a standard database server combining hardware, operating system and database management system Technology Product components). In the case of Application Hosting, this would be Cloud Infrastructure Compute and Storage capabilities.

It’s important to emphasize that the technology product component type represents the master copy or make/model of an item of technology and not its deployed instances modeled as technology services. So this component type is used to build a master list of products, versions, and even-dot version or patch-level information for any commercial item of software or makes and models of firmware or devices.

Person

Organizational Unit

Location

Location can also reference an associated hosting region for a public cloud vendor. Vendors like Amazon AWS, Microsoft Azure, and Google Cloud will host resources in data centers globally. Using Location to delineate the hosting region will be helpful when documenting your applications. These public cloud vendor locations can be found as a stand-alone dataset loaded into Ardoq by asking for support.

The other key points of data capture are made by connecting references between each application and the various components that represent how it is hosted. References ensure data quality and consistency by avoiding duplicating data in your model.

Is Supported By reference type represents that the operation of one component is a requirement, or precondition, for the operation of another. Utilization of the supported by reference limits the number of reference possibilities. It creates a singular relationship between the two components where the operational state of one component is directly impacted by another.

Deploys To reference type represents that a component implements the logical requirements, behaviors, or characteristics defined by another component. This is where we see a technology product being deployed to an instance of cloud storage.

Is Located At reference between one server and a location. For example, Server A is located in the Oslo Data Center. In the case of cloud infrastructure, we map the service to the region or availability zone it operates in. Mapping these references is important when analyzing where you have a managed infrastructure footprint and site utilization.

Lastly, we have a reference type between the server and the department component type. This reference represents departmental responsibilities towards the server.

Owns reference type represents the person and/or department with formal responsibility for the application or infrastructure. For example, in the context of Application Hosting, the person who has decision rights and responsibility for the specific application might also be responsible for the underlying infrastructure. Or it could be 2 different people, one responsible for the application and another person or team responsible for building or provisioning the infrastructure.

In many organizations, it’s common to have different subtypes of ownership—for example, a technical owner and a business owner. Generally, we don’t start with these in our best practice for a couple of reasons.

Firstly, when you’re starting with Application Portfolio Management, it can be hard to find any owner at all, and once you have them, it’s best to keep accountabilities clear.

Secondly, the business owner is often the owner of something else that uses the application - for example, a business process or business product—modeling them directly against the application risks creating confusing accountabilities later down the line.

This may be more simplistic in other organizations with either a business or technical owner responsible for the application through the associated infrastructure. Ardoq can be configured to model ownership however you like. But like all modeling decisions, there’s a tradeoff to be made.

What if you want to add more data points to your Application Hosting data capture?

The beauty of Ardoq is its flexibility. For example, adding new fields can be done by an administrator in seconds - see this article for information on adding fields.

An administrator can also easily create a new component and reference types, although we suggest you plan this process carefully: Over-complex metamodels can be hard to navigate and query.

Before you extend your metamodel, ask yourself:

With those considerations, you can quickly adapt your model to changing requirements. You can keep your critical data up-to-date and maintain your insights, keeping it continuously relevant as requirements evolve.

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 about this article.