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.
Purpose, Scope, and Rationale
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:
How are my applications implemented?
Where are my applications hosted?
What is the on-premise footprint, and which applications do they support?
What is the Infrastructure-as-a-Service footprint, and which applications do they support?
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.
Ardoq’s Approach to Application Hosting
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.
Understanding the Application Hosting Metamodel
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.
Application Component Properties
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.
Logical Infrastructure - Servers, Technology Products and - Services
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 defines a server as just a computer without a screen. As Ardoq sees it, a server is a unit of computing hardware dedicated to managing specific resources (RAM, CPU, Storage, etc.). Ardoq’s concept of server component type can similarly be compared to the ArchiMate concept of a device.
Server Component Properties
Name should be unique wherever possible.
Description should give other individuals some idea of the server's primary role.
Server Type field should reflect the high-level function the server fulfills in the overall infrastructure. This would typically be an application server, database, web, etc.
Server Hosting field is used to classify whether or not a server is physical or virtualized.
Network Zone 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.
Understanding Technology Service and Technology Product
There are many more types of hosting infrastructure beyond physical and virtual servers. Technology product is an abstract concept to represent a class of hosting infrastructure (examples). Technology service represents a specific instance of technology products 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 mentioned, technology services are an instance of an underlying technology product from a respective cloud vendor.
Technology Service Component
Technology Service represents instances of software with hardware to provide a predefined deployable building block for an IT system. When provided by a third party it may be referred to as Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS). The example below illustrates that Payroll Application VM is a technology service instance of the cloud infrastructure service AWS EC2.
Technology Product Component
Technology Product is any commercially-offered class of software, hardware, or firmware which can be deployed to provide one or more business capabilities or used to build an IT system by providing one or more technology capabilities. 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.
People and Location Components
A named individual in the organization. In enterprise modeling, a person is usually represented when they have a defined relationship with one or more other component types - for example, an application and instances of cloud services like AWS, Azure, and GCP.
An 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. (e.g., Finance, Human Resources, DevOps, etc).
A site, point, or area/extent identified by an address or by a set of geographic or geospatial coordinates. Locations situate the organization’s physical resources like departments and servers. They can be modeled at different levels of detail such as continents, countries, states or regions, cities, sites, and even individual rooms.
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.
Application Hosting References
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.
We use the Deployment Environment (Development, UAT, Production, etc.) field on the reference to capture what version of 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.
Is Realized By reference type represents that a component implements the logical requirements, behaviors, or characteristics defined by another component. This is where we see an instance of cloud storage is realized by the respective technology product.
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.
Extending your Application Hosting Metamodel
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:
How will I or others capture this information?
How much effort will it be across the whole application portfolio?
How will I use this information to create actionable insight?
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.