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 core concept of APM and more specifically ALM is the Application component. Ardoq defines an Application as follows:

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.

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 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.

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.

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

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.

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.

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.

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

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.

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.

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.

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 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.

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.

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:

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.