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.

Table of Contents


The Application Component Type

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

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. An application represents the automation of human tasks and is designed to be directly used by humans. Applications are distinct from other classes of technology in that they are aligned to the requirements of humans and not to the technical requirements or dependencies of other software.”

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

Ardoq defines Application modules as any sub-component of an application including (but not restricted to) user interfaces, code modules, data storage and even user-defined configurations that involve no code changes. For Example Salesforce and Salesforce Automation.

Application modules might need to be evaluated and maintained like an application. In some situations, application modules may; have their own endpoints that they expose, have unique metadata such as lifecycle or performance, or even have their own cost. Consider what fields are applicable as you create application modules.

Application Group Component Type

An application group represents a family or suite of applications. Since applications may be grouped by multiple user-defined dimensions - for example, the business processes or product they support or the department that owns them - it is important to emphasize that this grouping applies to the packaging, licensing, or deployment of applications as defined by the manufacturer. You can find an example of an application group in the patterns section of this document.

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.

Field

Description

Name

A unique name for the application

Description

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

Field Type

Description

Definition

Live

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

Field Type

Description

Definition

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

Hosting Type

List Field

Classification to determine how an application is being hosted

  • SaaS

  • Cloud

  • On-premise

  • Hybrid

  • 3rd Party

  • Desktop

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

Cost Fields (where applicable)

Field

Field Type

Description

Definition

CAPEX

Number (input)

Capital Expenditure

OPEX

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

Field Type

Description

Approved

Checkbox

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

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.

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.

Owns

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

Is Expert In

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

Consumes

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

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

There are several different situations where you might be wondering how to model your applications. We will cover some common scenarios and our recommendations on how to model them within Ardoq.

Application Platforms

An application platform is a framework of services that application modules rely on for standard operations.

For example, we can purchase and use Salesforce CRM without using Salesforce Service Cloud. However, we cannot use Service Cloud without first having Salesforce CRM. This would make Salesforce Service Cloud dependent on Salesforce to be utilized. We would classify Saleforce CRM as an application platform and Salesforce Service Cloud as an application module

We recommend modeling your applications platforms as application components and any modules be modeled as children underneath the parent application platform.

Services and Microservices

Services and Microservice might look very similar to application modules, they are code and configurations that deliver a part of the functionality of the application. However, services/microservices are different in that they aren’t dependent on the application and can be deployed independently. Because of this distinction we recommend modeling services/microservices as their own application components and following the same modeling principles as the application components.

In our example below Customer Account Lookup is a service that’s independent of Product C Web Portal, and could be used by any number of applications trying to look up customer accounts. The service has its own endpoint that other applications can integrate with.

Application Suites

Sometimes we have situations where we have applications that are independently deployable but loosely coupled together. A great example of this is Microsoft Office and Microsoft Word, Excel and PowerPoint. In this situation, we recommend modeling Office as an Application Group with Word, Excel, and Powerpoint being the applications in the group.

Application Instances and Versions

You may have situations in your organization, where the same software has been purchased and/or installed separately – for example, different business units using different implementations of SharePoint. Our recommendation is to log them separately. This enables you to identify opportunities to consolidate, or at least standardize on a given version.

In terms of naming different instances, a common approach is to add a suffix with the name of the owning department or business unit to distinguish them. For example, SharePoint Legal and SharePoint Finance.

Besides recording the instances, there are also good reasons to record the technology product itself as a separate component type. This can cause confusion, but on the plus side, it enables you to keep a central record of all software versions and their associated properties such as support dates (for example, taken from Technopedia or your Software Asset Management tool) and standards compliance. This avoids duplicating data across multiple instances.

Extending your ALM Metamodel

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.

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.


Version

Date

Author

Rationale

1.0

Jon Scott

First Draft

2.0

09/01/22

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

Did this answer your question?