IT applications contribute to the support of business processes, or other applications, thanks to the execution of IT software. Directly or indirectly, IT applications have one main purpose: supporting the business in the most efficient way. They can be considered as an asset of the enterprise.
Either custom developed or packaged, IT applications represent a cost: licenses, maintenance, customization, development, running fees, etc.
In a large organization, due to reorganization, acquisitions or lack of coordination, it is hard to keep track of which business processes are supported by which applications.
An inventory of IT applications, united with process descriptions, is the necessary foundation to answer the following questions with fact-grounded confidence:
- What are the applications that support the most critical processes, and which require attention and investment?
- Are there applications that are unused (or barely used) for which recurring fees occur?
- Is it possible to reduce costs by using one application instead of many for the same business purpose?
- By virtue of the dependencies between applications, is business continuity at risk if there is an IT failure?
Information quality is key
An outdated list of applications (or many disparate sources of information about IT applications) cannot be used as a solid reference; no business decisions can be taken on that basis. That’s why a central inventory of applications needs to be maintained.
Moreover, to allow the level of analysis required to answer business-related questions, it is necessary to link the applications to business processes representations; a repository is required.
An applications repository reaches an optimal level of quality when all necessary information is collected, signed-off, and kept up-to-date.
There are two types of information that need to be recorded:
These store the properties of applications: unique enterprise-wide Identifier, name, description, responsibilities, support responsibilities, and assessment of criticality, which can be in the form of a tiered classification, current operational status, indication of update strategy, number of users, etc.
Using a repository that integrates a database allows the relationships between applications and other representations to be documented. Relations allow impact-analysis queries between applications and the software products they use, the vendor providing them, the main functionalities they support and, eventually, the processes they support.
It is recommended that a quality-assurance mechanism be put in to assess the calibre of application documentation for completeness of required attributes (semantic quality) and existence of relationships (syntactic quality). It should also include an assessment of the validity of the recorded information.
A pass score can be established to determine which applications descriptions are ready for sign-off and promotion to the library.
Building the applications architecture is a process.
Building an application’s inventory is a process that transforms a heterogeneous, redundant and uncontrolled list of applications into a controlled catalogue placed under the responsibility of the subject matters experts.
To reach the level of information quality required for trustworthy reference and reporting, it is necessary to ensure that each application is identified, documented, and signed-off by the persons in charge of them within the enterprise.
Application inventory – constituted by the applications, their attributes, and relations to other objects – is structured content stored in a database. Yet, it is important to make sure that initial unstructured, incomplete, or approximate content may be taken into account as an initial input.
During discovery phases, a modelling tool that allows collaboration and sharing of application architecture views can be used. Eventually, created application architecture views constitute the graphical communication of the application inventory content stored in the database.
Once it has been signed-off, an application is ready to be placed under architecture control. It is promoted to a library. The library contains validated content and is presented strictly according to conventions. The content of the library is the trusted reference.
Write access to the library is strictly controlled to prevent accidental or uncontrolled modification of the application’s library.
It is important to stay focused on business needs. When possible, adopt an agile approach to allow rapid implementation and rapid adjustments to the specific needs of users and stakeholders. Try to address immediate needs as much as possible (like the production of reports to illustrate dependencies between applications supporting a specific process).
Allow a smooth and progressive adoption of the application inventory building process (it’s a group-learning exercise). Keep it easy. Develop simple conventions, and create a project space where creativity is allowed and mistakes have no consequences. When collecting input from subject matter experts, privilege ‘focus on content’ instead of ‘focus on layout’ or presentation. When possible, make the most of available collaborative software that allows easy screen sharing and cooperation across the enterprise.
Enforce reference material
The application inventory must become referential, communicated, understood and used across the enterprise. It can then be used with confidence for business analysis, planning, and the design of future solutions.
To allow comparison and optimisation, when possible, describe applications by mapping relations to readily available enterprise-wide reference material, like a common application domains model.
Unite with business processes
Applications support business processes: it’s a good way to track an application’s fitness for business purpose.