Aug 25th, 2008 |
You cannot manage what you do not measure. This seems to be a recurring theme here, and that is really what APM and PPM are all about. How many applications does your organization have? Who uses them? How much money is spent on maintenance, development, and operational support? What programming languages are they written in? How are the applications related to each other? What parts and pieces constitute each application? For many organizations, these are surprisingly difficult questions to answer. But they shouldn’t be, and they don’t have to be. Basic asset management principles are easy to employ to help manage the application portfolio. An application registry forms the basis for effective application portfolio management.
The concept of asset management is not new. Thousands of years ago, shepherds watched over their herds of sheep. They constantly surveyed the landscape for threats and enemies. They knew how much food and water the herd needed, and made sure they were getting enough. They watched for births and deaths, and looked after the health of each sheep in the herd. They had an understanding of the overall state, count, and wellbeing of the herd. And, of course, they kept all of this information in a database, or at least they would have if they could.
The application registry is a modern-day equivalent to the shepherd’s database. Organizations who have adopted ITIL will refer to this registry as a configuration management database, or CMDB. The registry keeps essential information on all of the IT assets within an organization, including hardware and infrastructure details, software configuration and interdependencies, budget data, quality data, a detailed technology profile, transaction volumes, service level agreements, etc… It is the central and authoritative source of information about these assets.
This is very difficult to pull off. The fact is that different parts of the organization are responsible for each of these areas. Each of these groups manages their own area, but in most organizations there is a lack of higher-level coordination between these activities. Each group has their own view of the world, which is not necessarily in agreement with the views of the other groups. Thus, each group may have a different list of applications, with different names, gaps, and conflicts with the other groups. These lists can even track information at different levels of granularity, which make the problem even more difficult to resolve. And, in the end, each group is the owner of their own information. It is a real challenge to build a holistic view of the enterprise.
The solution is to create a federated view of these diverse registries. This is notably different from a central, single master registry. To help build a holistic, enterprise view of the application portfolio, you need a way to link these separate registries and resolve data quality issues. First, establish a central authoritative master list of applications and have all stakeholders rally around this list. This means that all groups must agree to use the names and ids from master list. Each group must respect the boundaries of information ownership, and avoid duplicating data for which another group is responsible. Establish links between these information sources to create a real-time, federated view of the application portfolio.
The application registry is the key integrating and unifying force used to create a federated application portfolio view. It is very important to establish clear governance processes around maintaining the application registry, and to include the registry in internal processes impacting the application portfolio. This includes the budget planning cycle, PMO activities, software development, release management, incident and problem management, application lifecycle planning, etc…. This will make sure that the registry is as accurate and up to date as possible.
Next: Communication is a Key to Success
