As the Enterprise Architect responsible for key IS applications, it generally comes down to me to guide and enable teams engaged in reviewing application portfolios. In my technology consulting days in the past, I had engaged in several “Application portfolio review” exercises for clients across industry domains. In all these exercises, there is a common thread: high cost of such “application portfolio” data gathering exercise - in other words, a nice high-value billable engagement for consultants – that can add up in the context of large transformational programs, where understanding of “as is” landscape is a must have.
At the very basic level, the problem comes down to maintaining a verifiable, well maintained inventory of applications. Of course, for many uses, a simple “list” alone is not sufficient. Most of us who have been in the industry realize that for an application list to be useful, it has to inform a cross section of stakeholders looking for varied perspectives. Just a small subset:
The gap – and perhaps opportunity – is when it comes to data about the business functional and capabilities enabled applications. These are generally defined in the product documentation (in case of COTS products) or in the functional specifications and design documents and need to be manually updated in the CMDBs. Even assuming an initial mapping of such data is accurate, the data generally degrades over time as the applications transform, functionality is added and technical and functional ownership changes. Updating such changes in the CMDB is both expensive and resource intensive, as it is generally a manual process.
Unless managed with strong executive support, governance, and ongoing funding, the reliability of such data in the CMDB may degrade over time. Such lack of reliability may also weaken stakeholder confidence in the CMDB as the “single source of application information,” causing groups, divisions and transformational programs to begin managing their own lists in wikis, spreadsheets and other smaller ‘databases.’
In a way this is a classic example of being penny wise and pound foolish: by avoiding the cost of updating and maintaining CMDBs, the organization may end up spending a lot more in individual “application portfolio review” and “data gathering” exercises.
Notes:
(Repost from LinkedIn Pulse)
At the very basic level, the problem comes down to maintaining a verifiable, well maintained inventory of applications. Of course, for many uses, a simple “list” alone is not sufficient. Most of us who have been in the industry realize that for an application list to be useful, it has to inform a cross section of stakeholders looking for varied perspectives. Just a small subset:
- Enterprise Architects: Seek data on applications, application components, data and interfaces between them, and more importantly the business capabilities and functions enabled by such applications. Such inputs are also building blocks for “Roadmaps” that inform the implementation of business strategies and are also used in scenario planning and defining business cases.
- IS Architects and Others: Large technology transformation programs generally require an “impact assessment” to understand, and catalog the impact of changes in the existing application landscape. Typical questions include: How many applications in the landscape? How many applications supporting xyz process, who and how are the applications managed?
- IS Executives and leadership teams: Generally interested in support cost, technologies adopted and other dimensions that can inform TCO of application portfolios, including strategic use of software licenses, vendor negotiations and optimizing the use of infrastructure across the portfolios (Cloud strategies come to mind but delving deeper on the topic in this article will digress us)
- Operational and support teams: Managing the workflow of functional and technical changes and enhancements and propagating them through the application development life cycle.
- Vendor and strategic suppliers: Access to application portfolios can help them proactively suggest optimization or leveraging new product and solution capacities.
- Other uses: Include SoX compliance, responding to regulatory and audit requirements etc.
“a repository that acts as a data warehouse for information technology (IT) organizations. Its contents are intended to hold a collection of IT assets that are commonly referred to as configuration items (CI), as well as descriptive relationships between such assets. When populated, the repository becomes a means of understanding how critical assets such as information systems are composed, what their upstream sources or dependencies are, and what their downstream targets are.”A well-defined and managed CMDB tool may help an organization manage IT assets, including applications and infrastructure supporting them. Many tools also enable “auto discovery” of elements. An entire industry and consulting sub-segment of IT management focused on ITIL and IT operations has sprung up around configuring, supporting and managing CMDBs.
The gap – and perhaps opportunity – is when it comes to data about the business functional and capabilities enabled applications. These are generally defined in the product documentation (in case of COTS products) or in the functional specifications and design documents and need to be manually updated in the CMDBs. Even assuming an initial mapping of such data is accurate, the data generally degrades over time as the applications transform, functionality is added and technical and functional ownership changes. Updating such changes in the CMDB is both expensive and resource intensive, as it is generally a manual process.
Unless managed with strong executive support, governance, and ongoing funding, the reliability of such data in the CMDB may degrade over time. Such lack of reliability may also weaken stakeholder confidence in the CMDB as the “single source of application information,” causing groups, divisions and transformational programs to begin managing their own lists in wikis, spreadsheets and other smaller ‘databases.’
In a way this is a classic example of being penny wise and pound foolish: by avoiding the cost of updating and maintaining CMDBs, the organization may end up spending a lot more in individual “application portfolio review” and “data gathering” exercises.
Notes:
- These observations are based on review of CMDBs and application portfolio “lists” at large organizations spanning geographies and lines of businesses. Smaller organizations with smaller IT footprint and limited number of applications may not have the same issues
- Many organizations have their own definitions of applications and technology platforms. (Wikipedia) Hence, I have refrained from defining “Applications” in this writeup.
(Repost from LinkedIn Pulse)
No comments:
Post a Comment