Application Lifecycle Management Metamodel

Overview of the Application Lifecycle Management metamodel and descriptions and details around component, field and references and patterns.

Kristine Marhilevica avatar
Written by Kristine Marhilevica
Updated over a week ago

Getting control of your application portfolio can be a major effort, so however tempting it may be to identify an extensive data capture requirement, our strong advice is to start with a small number of key data points.

These will give you the data you need to impose some control over your application estate, and a great foundation for future application portfolio management initiatives.


The Application Component Type

The core concept of APM and more specifically ALM is the Application component. Ardoq defines an Application as follows:

“A deployed and running software solution that provides specific business or technology capability, performs a defined task or analyzes specific information. It has meaning for, and its name will be recognized by, its business users. It may be part of (i.e. a child component of) an Application Group (e.g. MS Word as part of MS Office) or a larger Application (e.g. SAP Finance Module as part of SAP).”

Similar definitions can be found in standards like TOGAF and ArchiMate.

Even with those definitions, it can be hard when looking at your long list of candidate software to decide exactly what is and what isn’t an application. Don’t panic - we’ve provided guidance in our What is an Application? article.

Application Module Component Type

An Application Module is defined as a deployed and running software component that has meaning for, and will be recognized by, the team that developed or supports it. It is unlikely to be referenced, by name, by business users, as its role is to support one or more applications that they do recognize. It may be a component (represented as a child component) of an Application or another Application Module, or it may be a standalone component (e.g. A scheduling microservice may be used by multiple applications but it’s not at the level of recognition to be classified as an application itself, so it would be documented as a standalone application module.). Application modules may also help realize business or technical capabilities similar to Applications.

Application Group Component Type

Application Group component types are used to package up a family or suite of applications (e.g. Microsoft Office) that are grouped together to represent their licensing, or deployment together as defined by the manufacturer. If the parent grouping would be recognized by and referred to as a single coherent business system by business users, it should be represented as an Application component instead. Application Group components do not carry the same metadata fields or references as an application.

Application Lifecycle Management Properties

Now let’s look at the key properties of the application we’ll need to drive application lifecycle management (ALM).

Basic, but very important, are a Name and clear Description. Name should be unique wherever possible, and Description should give others some idea of what the application does.




A unique name for the application


A concise description of the nature of what the application does.

Lifecycle Fields

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


Field Type




Date Range

A date range from when an application “went live” to its discontinue date

Lifecycle Phase

List Field

A field used to classify where an application is in its lifecycle

  • Evaluating

  • Implementing

  • Live

  • Mainstream

  • Phasing Out

  • Retired

Lifecycle Phase determines whether the application is "on the launch pad”, waiting to go live, live, or already decommissioned. This property alone enables you to answer the simple but important question “how many applications do we have?”

A more refined view of lifecycle comes from filling dates in the Live date range field, where the first date is the date on which the application 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 important as it enables IT planners to see when changes in their application estate will take place. For example, when application counts or costs will change. Knowing when things will happen is a key element of controlling your applications and your costs.

Now you may be looking at these dates and wondering how you’re going to populate them. It might be possible to discover when an application was introduced with a bit of digging. Knowing when it will be decommissioned or discontinued could be sheer guess work. And anyway, how much value will this provide?

The answer is that for a majority of your applications their Live Start and Live End dates will be “I don’t know”. That’s fine. The value comes from capturing these data points only where you do need them for forward planning.

For example, knowing when your new ERP application is going to be set live, and when the applications it will be replacing will be decommissioned - that’s valuable information. For all the other applications, 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.

Additional Metadata


Field Type



Service Level

List Field

Classification to establish the level of importance that the application has for the organization as a whole (its fix-on-fail priority)

  • Platinum

  • Gold

  • Silver

  • Bronze

Application Type

List Field

Classification to determine how an application was developed and delivered to the organization

  • SaaS

  • COTS

  • Internally Developed

User Base

List Field

Classification to determine how many users are using the application

  • 1

  • 2-50

  • 50-200

  • 200-500

  • 500+

The Application Type field is used to classify how an application was developed and who manages it. Having this information becomes critical when trying to optimize your application portfolio. The field has 3 options; SaaS, COTS, and Internally Developed.

  • SaaS refers simply to the fact that the application was built and is managed wholly by the developer. This indicates that changes cannot be made to the application

  • COTS or Commercial Off the Shelve refers to applications that are developed externally but are installed and managed internally. COTS applications are typically customizable but through professional services or special providers.

  • Internally Developed refers to any application that was developed internally and is managed by your organization. This indicates that the application has a development lifecycle and can be customized.


Field Type



Hosting Type

List Field

Classification to determine how an application is being hosted

  • SaaS

  • Cloud

  • On-premise

  • Hybrid

  • 3rd Party

  • Desktop

The Hosting Type field is used to classify how the application is hosted and managed within your organization. Hosting Type has a few different options because there are many different ways applications can be hosted.

  • SaaS (very similar to the application type) represents that an application is managed wholly by the SaaS developer. This indicates that the SaaS developer controls and manages where the application is hosted, how it is hosted, its availability and uptime, and all of the infrastructure maintenance.

  • Cloud (IaaS/PaaS) represents that infrastructure aspects of the application are deployed in a Cloud environment such as AWS, Azure, GCP, etc. This indicates that infrastructure maintenance and availability are handled by the cloud provider.

  • On-premise represents that the infrastructure aspects of the application are located and managed entirely by your organization.

  • Hybrid represents the infrastructure aspects of the application has some elements that are located and managed by your organization on-premise and some elements are hosted in a cloud/managed environment.

  • 3rd Party represents that the infrastructure aspects of the application are wholly managed and maintained by a 3rd party provider or managed service provider (MSP).

  • Desktop represents an application that runs in a local desktop environment and doesn't have dedicated infrastructure outside of the desktop.

These can easily be adjusted to match your organization or not used if irrelevant.

Cost Fields (where applicable)


Field Type




Number (input)

Capital Expenditure


Number (input)

Operational Expenditure

Total Direct Cost

Calculated Number

The cost is directly tied to the specific component. Eg. license, support & maintenance etc.

The sum of CAPEX+OPEX

At this point in your ALM journey, it’s very unlikely you’ll have accurate application costs (if you do, you’re very lucky!). This cost concept will be expanded in more detail in the IT Cost Management Guide and Metamodel whitepaper here.

Governance Fields


Field Type




Used to indicate whether a component has been reviewed and acknowledged as being accurate and complete

Review Date

Date Field

Used to indicate the date at which a component was reviewed and acknowledged as being accurate and complete

Ownership Accepted


Used to indicate whether a nominated owner has accepted the responsibility of being the application owner. Possible values are Yes or No.

Application Ownership State

Calculated List

Determines the ownership state of the Application by examining whether there is an application owner, whether they have accepted responsibility, and whether application details have been provided and are up to date. Possible values are Unowned, Nominated, Owned or Managed.

Approved and Review Date are the last two properties and are there to support workflow. Approved is a property which means the Application has been reviewed and approved for inclusion on your lists by an expert.

You can optionally filter by this property in your views and dashboards to exclude any applications that haven’t been through a ‘quality check’ process. This is important because as you open your application lists up for contribution, you’ll get a certain number of applications that are duplicates, parts of other applications, or not applications 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 application. You can populate this property with a specific date, or alternatively use the scheduling function in the Broadcasts module to trigger application data refreshes or time-based alerts.

Ownership Accepted is used in the Application Ownership Process to indicate whether a nominated owner has accepted the responsibility of being the application owner. It enables a flexible workflow where a nominated owner can decline ownership and pass on the request to a more suitable nominee.

Application Ownership State is a calculated field that automatically determines whether an application component is in an Unowned, Nominated, Owned or Managed state. It is used to drive the Application Ownership Process, and to report on the ownership state of the application portfolio.

ALM References

The other key points of data capture are done by capturing references between each application and other components. References are used to ensure data quality. They ensure data consistency by avoiding duplicating data in your model.





Has Successor

Represents the replacement of an application by another application.



The first reference is the Has Successor reference between one Application and another. Has Successor says ‘this thing will be replaced by this thing’. For example, Applications A, B and C may all be replaced by Application D. Mapping this reference is especially important where old applications are being decommissioned. In many cases, the business requirement for the application has not gone away, and you need to be able to show what the application(s) will be replaced by. This is the basic function of ALM.

Next, we have two reference types between the Application and the Person component type. These references represent people’s roles or responsibilities towards the application.

To understand more about Ardoq’s best practices for representing people in your architecture, see here.

In this case, we have two different reference types linking people to the Application: Owns and Is Expert In.






Represents that a component has overall responsibility for another component. As an example, Person Owns an Application. Owns connects people or organizational units to applications to assign responsibility and ease the maintainability of data quality.

Person / Organizational Unit


Is Expert In

Represents that a person component has substantial knowledge around a specific component(s).

Person / Organizational Unit



Represents the utilization relationship between an organizational unit and an application.

Organizational Unit


Owns represents the person with formal responsibility for the application. Typically this will be the manager whose team is responsible for building or provisioning the application. But be aware that this isn’t always the case. However, the owner should be the person who recognizes that they have that responsibility for the application.

In many organizations, it’s common to have different sub-types 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 out with ALM it can be hard to find any owner at all, and once you have them it’s best to keep accountabilities clear.

Secondly, because the Business Owner is more often than not actually 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.

But this isn’t to say you shouldn’t go down this route, particularly if you already capture this data. Ardoq can be configured to model ownership however you like. But like all modeling decisions, there’s a tradeoff to be made.

Is Expert In is less contentious. There’s no assumed responsibility here, just a high level of knowledge of the application. The expert is typically the go-to person for questions about the application.

Mapping these people (if you haven’t done it before) can give tremendous value to your whole IT community by answering the simple question “who do I talk to about this?”

Another key aspect of knowing about your application is to understand who is using it. The Consumes reference connects teams, departments and groups (organizational unit components) to the application. This gives a good understanding of who within the organization is using the application and what is the potential impact of change. For more information on how to model organizations check out the Organizational Modeling Guide

Lastly as organizations move more and more to cloud and into more SaaS applications, away from internally deployed and managed applications, it can be challenging to keep track of where these cloud applications are actually located.





Is Located At

Represents the relationship an application component has with a specific location.



The Is Located At reference is used specifically for applications that aren’t hosted internally. Making sure organizations keep track of where in the cloud these applications are located is critical for various data privacy laws and ensuring compliance and reducing risk.

Application Modeling Patterns and Extending your ALM Metamodel

There are several different situations where you might be wondering how to model your Applications. The Application Modeling presentation covers several examples that show how this can be done in Ardoq.

But what if your application landscape doesn’t consist of perfect black box applications but are composites of lots of different technologies and services? What if you want to add more data points to your ALM data capture?

The beauty of Ardoq is its flexibility. Adding new fields can be done by an administrator in seconds - see this article for information on how to add fields.

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

If you need to represent Applications as composites of Modules, Technology Services, Interfaces, and Databases, check out the What is an Application? How to Model Complex Business Systems in Ardoq article for more insight on how to structure and extend your ALM metamodel. Additionally, make sure to read our Seven Principles for Creating a Great Enterprise Architecture Metamodel article to help guide you through adapting the model.

Before you extend your metamodel, ask yourself:

  1. How will I or others capture this information?

  2. How much effort will it be across the whole application portfolio?

  3. How will I use this information to create actionable insight?

With those considerations, you can easily adapt your model to changing requirements. This means you not only keep your application up-to-date, but keep your application insight continuously relevant as requirements evolve.






Jon Scott

First Draft



Jon Scott

Updated metamodel

  • Added application group and application module component types

  • Added location references for SaaS applications

  • Added consumes reference to org units

  • Added application patterns



Jon Scott

  • Updated component definitions

  • Updated Application Patterns

Did this answer your question?