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 is an Application. 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.
Now let’s look at the key properties of the application we’ll need to drive lifecycle management.
Basic - but very important - are a Name and clear Description. Name should be unique wherever possible, and Description should give the 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 live, on the launch ramp waiting to go 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 data 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.
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 90% 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 Total Direct Cost property is there to capture the total annual run cost of the application. It is calculated by combining the OPEX and CAPEX fields on the application component. 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 journey. You can also read more about the IT Cost Model here.
So Total Direct Cost is there to capture a rough estimated cost with the objective of answering the question “how important is this Application?” It’s to stop you chasing down data for that ‘long tail’ of minor applications that aren’t going to have much influence on your IT planning processes.
We advise you to come up with a simple list of estimated costs at this point in your journey. For example, applications that cost $1,000 a year, applications that cost $10,000 a year, applications that cost $50,000 a year, applications that cost $100,000 a year.
Without some view of cost you may struggle to engage your senior audience; but equally, it’s important to make it very clear at this stage that all costs are estimates. You don’t want to get bogged down in financial reconciliation discussions at this point.
Approved and Review Date are the last two properties and are there to support workflow. Approved is a property that 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.
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 by ensuring data consistency by avoiding duplicating data in your model.
The first reference is the Successor reference between one Application and another. 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 this isn’t always the case. What is the case is that the owner should be the person who recognizes that they have that responsibility.
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?”
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.
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 easily adapt your model to changing requirements. This means you can not only keep your application up-to-date, but keep your application insight continuously relevant as requirements evolve.