Enterprise Application Inventory - An Essential Tool
/I was on two projects last year that involved a huge number of application integrations. One of the project was a single-sign-on migration, while the other is a migration plus new enhancement of an identity management system.
Single-Sign-On Migration Project
The single-sign-on migration project was a huge pain. The project team know of only 53 protected applications. Yet when we went onsite to access the current state, we found about 100 protected applications from the application mappings on the reverse proxies, as well as the application access policies on the current single-sign-on application. Puzzled, the team tried to locate the system owners of the ‘new’ applications. Emails were sent out, calls made. Yet, there still remain a significant number of applications without anyone coming out to own them.
Migrations were then planned as three phases against the known applications. After the three phase, the existing reverse protect/single-sign-on agents were then shut down. The plan was to de-commission them.
Then the users complain came in. Some of these applications still had active users. But there was still no owners. Their previous owners might have left the organisation without properly handing them over to new owners. Others might had been forgotten after numerous re-organisations. It was a painful time for everyone as new owners had to be identified for those with active users.
And they had not even began to de-commission the remaining applications that were not in use at all. Perhaps it might even get forgotten after this. Unnecessary virtual machines running utilising unnecessary storage, memory and computing power.
Identity Management System Integration
The identity management system was tedious (for a separate reason). Yet we were fairly clear on the applications that had to be integrated. Each application had an owner, an application tier level (to indicate its importance in the enterprise architecture), the user store location (Active Directory, application database, or an LDAP user directory), and many other useful information. We were able to prioritise on the applications to integrate first, and also how we will integrate them.
After the initial integration, the application inventory was maintained and regularly updated by the project team. Communications were maintained with the application owners, such that when there were application changes that impacted the identity store, the identity management system was informed and updated.
Both integrates huge number of Applications
These were two different projects, yet both involve huge number of application integrations. And in both cases, an application inventory is essential to facilitate a smooth project implementation. And it was clear from experience that without an application inventory, there would be confusion, stress, frustration, and waste within the project and throughout the organisation. Even after the project implementations, the application inventory must be maintained and kept up to date to ensure future smooth operation of these systems.
### Why would anyone not keep an up-to-date Application Inventory? Yet given the known benefits, not every organization is able to produce an application inventory when requested. Why would that be so?
Producing an initial application inventory listing is easy. In fact, in the projects mentioned above, it would be an essential by-product, if not part of the project deliverables. The pain comes from maintaining the inventory. Who should be the owner of this inventory? Even if it is a project deliverable, letting the project system owner take ownership would limit the usage of the inventory to just what the delivered project system needs. If it was a SSO project, it would not be concern with non-SSO applications. It would then form an incomplete picture of the organisation’s application landscape. If it was advertised as the ‘source of truth’, it would cause more harm than help, as non-listed applications would be forgotten much easier as compared to when the organization did not have an application inventory.
And let us assume that the SSO system owner managed the application inventory. An IDM project then came along requesting the application inventory. They find that the list was incomplete for their purpose, and adds information necessary for the IDM project integration. Now, with an updated list, who should be the owner? Ideally, the list should go back to the original owner, who would be the SSO system owner. Yet, it would not be in his interest to keep the list up to date with the non-SSO applications. Even if he were to shoulder the responsibility, he might not be aware of why, and what new applications might need to be in the list. The IDM system owner would be the more suitable person to own the application inventory when it describes information specified to IDM integration.
So, in terms of suitability, we have two different person now who could own the application inventory. Yet left by themselves individually, they could not paint the complete picture. Perhaps we should really end up with multiple owners?
Before we delve into a possible solution, we take a step back and try to understand the potential benefits of maintaining an up-to-date application inventory. For organisations that maintain an application inventory, what benefits do they gain from it?
Benefits of an Application Inventory
For business, it gives them a clear picture of the enterprise application landscape. The enterprise will have a better idea on which applications the IT is spending the money. With that, they are able to achieve a more optimised portfolio management. The enterprise will also know if a new application might replace or consolidate several existing applications, and identify the existing system owners to involve them in functionalities or user migration.
With an inventory, there should be no orphan applications without any owner. This could also force a continuity of the application domain knowledge, as opposed to the potential of knowledge lost. It forces a proper transition plan between owners, especially if they are across departments.
For real orphan applications without owners (no department wants to own it), it brings up the question if the application is truly needed. Perhaps there were no more users, and the application could be safely decommissioned. Decommissioning applications could free up people resource, network resource, cpu resource, and even storage resource for other applications they are truly needed.
In short, for the business, it is all about better spending of the money on IT, through better portfolio management.
For IT, as mentioned earlier, having the application inventory would definitely help in project implementation and support. Knowing who the application owners and support personnels are at the minimal would save the project team time from hunting around and getting the right information from the right people. Project risk would be significantly reduced, resulting in faster delivery time and lower project cost as well.
A possible Application Inventory Implementation
So how should we go about creating an application inventory, and keep it up to date? As we discussed earlier, it might not be entirely feasible to have a single person own the entire application inventory that covers all the possible spectrum of usage. SSO and IDM are just two potential usage, and there could be more. Yet, we feel that it is important that there is a single master source of all applications in the enterprise.
All this would point us to the need to main a lightweight, business information focus Application Inventory at the Enterprise level. This Enterprise level owner will be focused on the business aspect of the applications: what they are used for, any supporting applications or inter-application relationships, the business owners. Other useful information to keep for business might be the capex and opex of the application for portfolio planning purpose. From an IT perspective, support personnel names, downtime schedule would be useful as well.
At the Enterprise Application Inventory level, the entry could be mark if it supports SSO or IDM (or other similar ‘integration mechanism’) as well. This will then allow the owner to direct the more specific details down to the respective domain expert who will own the Application Inventory at that level. Having the right details at the right level would be the better approach, as they would be more aware of the domain information as compared to the owner on the Enterprise level.
Yet, it should be noted that the first point of contact for any application should always be through the Enterprise Application Inventory owner. Applications must be only added/removed on that level, and he would be responsible for informing the Application Inventory owners of the other level, and directing the new application owner to update those Application Inventories on the other level as necessary. The Enterprise Application Inventory would be the master source, containing pointers to the other sub-domains (similar to the concept of DNS). If a new application comes onboard, and require integrations to other applications, but no such information/sub-domain is available, it could suggest a ‘pointer entry’ in the Enterprise Application Inventory. This ‘pointer entry’ would allow it to be notify of any application changes in the future when the application owner notifies the Enterprise Application Inventory owner.
In fact, it is as important to establish this application update process that propagates down from the Enterprise level to the specific domain level on top of the maintaining of the inventories themselves. Without the established process, the multiple inventories would likely go out of sync as quickly as they began. There simply is no one to enforce the consistency, nor any communication protocols that could be used in the enterprise. Having the process and governance in place is critical to keeping the Enterprise Application landscape clean and tidy.
Conclusion
Application Inventory is nothing new. It seems fairly common sense, and extremely beneficial to business. Some organisations might even be doing it, but they might be in silos. Meaning the IDM had their own inventory, and SSO had their own inventory. There is no one to bring them all together, or an established process to manage the updates. Other new projects or business are unable to reap the benefits.
What they need is to bring it together. Set the purpose and business benefits of maintaining an Enterprise Application Inventory. Find a strong Enterprise champion for the cause. Establish the ‘pointer entries’ to the subdomains. Define a governance process.
With this, new projects as well as business would have better visibility into the Enterprise Application landscape, resulting in better IT spending and planning. And you might just no longer need to go through crunch time or frustration for your next project implementation.