Here is the second part of my review of the ITIL “Gold” volume on Application Management. (First part.)
This part is concerned with the architectural implications for tools, processes, and data structures implied by this volume.
The application portfolio, as depicted in this volume, is itself an information system, database-based, which stores attributes about applications that are enterprise assets. Its purpose is to “fully realise the benefits of their IT investments.”
On the question “what is an application,” the volume defines it as “the software program(s) that perform those specific functions that directly support the execution of business functions, processes, and/or procedures. Applications, along with data and infrastructure components, such as hardware, the operating system, and middleware, make up the technology components of IT systems that in turn are part of an IT service.”
The reader is encouraged to examine this article from my “Fundamentals of Integration Metadata” series for technical background on precisely defining the concept of application. Note that distinguishing between application, data, infrastructure, and middleware may be easier said than done…
A further key point is that “application portfolio management is an information system and as such requires the same level of application development discipline and IT Service Management support as any other business- or mission-critical system”
Application portfolio process
The volume states that “Before implementing an application portfolio it is important to have mature Configuration Management, Release Management and software Configuration Management processes. There are few benefits to be gained from managing the IT investments from a business point of view if the assets themselves are not managed at an IT level.”
I actually disagree with this. Most configuration management implementations are challenged by the question of “how granular should we go?”; mastering the tricky, consensus concept of application (again, see this article) is an important step towards a managed IT environment and can be done independently of full-blown configuration management.
Even immature shops have a need for an application portfolio, and managing one at a high level may be a good way to start making the case for configuration and change management – it starts to build a common understanding among those running IT that may previously have been lacking.
Applications as such are large concepts; they may consist of hundreds or thousands of software components, servers, and the like. As a key structuring mechanism for working enterprise IT relationships, they tend not to be volatile; the data warehouse concept of a slowly changing dimension is comparable.
So how does one maintain the data in an application portfolio? Saying that something is an “application” is a significant commitment, analogous to adding a new account to the general ledger. Support and management implications flow from this, and therefore the creation of new applications must be carefully considered. Even major development initiatives may be doing nothing more than creating a subsystem.
Once the application has been confirmed as such, it should be assigned a unique, terse identifier that should be used for naming all assets related to the application. Note that this implies the creation of the application record at the beginning of the software development lifecycle; using a formal change process as a control point may not work well here, depending on how the concept of change is managed in your enterprise.
Do not underestimate the value of this identifier. Used properly, it is a powerful means for ensuring traceability of your technical environment to its business purpose. But controlling it and keeping it aligned with the application portfolio is key.
One logical area for controlling the portfolio would be an enterprise architecture capability; other organizations may choose IT line managers. A combination of the two might be optimal, as a sort of check and balance.
For further updates to the data, the ITIL approach would of course be through change and configuration management, but the process of handover from project to support (break/fix) organization may actually be a solid alternative, as (in my experience) such handovers tend to be a little less high-pressure than scheduled production changes. In any case, some gatekeepers for determining what is and is not an application are essential.
Data structures
Here reproduced in full are the application attibutes the volume calls for:
• Application name
• Application identifier
• Application description
• Business functions performed
• IT services supported Geographies supported
• Business criticality
• SLA hyperlink Business owner
• Executive sponsor
• IT operations owner
• IT development owner
• Support contacts
• Database technologies
• Dependent applications
• Systems architecture User interfaces
• Network topology
• Application technologies
• New development cost
• Annual Operational Costs
• Annual support cost
• Annual maintenance costs
• Outsourced functions
• Outsource partners
• Production metrics
• OLA hyperlink
• Support metrics
This is the meat of what I want to talk about.
First, the volume incorrectly implies that all are “attributes” of an application; “attribute” has a very specific meaning in data management and where there is actually implication of another entity it’s not an appropriate use. A car may have an attribute of “color,” but where it has been driven is not an attribute – this would be another entity, perhaps called “location.”
Here are some groupings:
Application name
Application identifier
Application description
Business functions performed
IT services supported Business criticality
OLA hyperlink
SLA hyperlink
This first group of attributes is core to the application’s identity. A sound, well-written business description is essential, but I would tend to include the “business functions performed” in that description, and not break it out as a separate attribute. On the other hand, if there is a master list of the functions the business performs (i.e. a functional decomposition) then the Application entity might actually have a many-to-many with the Function entity. Similarly, if “IT Service” is its own entity, then there is probably a many to many between it and the application. I would love to hear from anyone who has a perspective on whether Services and Applications are essentially identical, or if one is inherently more or less granular. (I usually hear that Services are less granular than Applications, but have not seen any research or theory justifying this. See here for further discussion.)
Business Criticality is probably a type code; typically it would be stored in a reference table. The key process challenge here would be getting the business to agree to the criticality ranking; without some means of assessing the costs of a given criticality level, the business will typically say that everything is “supercritical.”
Business owner
Executive sponsor
IT operations owner
IT development owner
Support contacts
Geographies supported
These “attributes” are more contextual, having to do with the organizational entities (persons or groups) who have an interest in the application. These kind of data requirements are often handled with a generalized structure by an information modeler, because often the client will come back and request yet another role (“Can you add ‘business key user’?” for example.) A typical data structure might look like:
Note that the use of abstractions like “Party” can be controversial among data analysts; there are many ways, general and specific, to solve this problem.
Database technologies
Application technologies
Dependent applications
Network topology
Systems architecture
User interfaces
This next list of “attributes” really starts to pose the comprehensive, ERP for IT challenge implicit in the Application Management volume. Clearly, “network topology” is in NO way an “attribute” of anything – a network topology is itself a complex data structure. Ditto for “systems architecture.” Again, an “attribute” is something granular, that can be stored in a single text or number field – how does one reduce an “architecture” to this?
As one attempts to implement the above requirements, the distinction between “systems architecture” and “dependent applications” may also appear arbitrary. In documenting a systems architecture one usually has to identify dependent applications. Similarly, distinguishing between “application technologies” and “dependent applications” is unclear. If an application is dependent on LDAP – is that a usage of an “application technology” or is the application a “dependent application” on LDAP? Precision is vital here, and the requirements as posed in this volume need further analysis before one could construct a system supporting them.
A widely-used method for documenting architectures is the establishment of a simple dependency on the system concept:
The above data structure says that any system may use any other system, and that a system or systems may be owned by (only one) other. This uses/owns distinction is pervasive in the ERP for IT problem area. Note that “owns” is a tree (one to many) while “uses” is a network (many to many). These are complex structures to manage and make sense of; see this article for further discussion.
The interested reader is also referred to the area of architectural description languages. Much current practice is based on the concept of “port” and “connection,” deriving from component-based architectures. See the UML 2 or EDOC specs for further information.
Generally, solving this set of requirements will require architectural modeling tools, an IT area that has minimal integration/understanding historically with IT Service Management.
New development cost
Annual Operational Costs
Annual support cost
Annual maintenance costs
Production metrics
Support metrics
Outsourced functions
Outsource partners
This last set of requirements completes our journey into the full ERP for IT challenge. The cost data implied will need to come from project management and general ledger systems and IT Service Management systems. One challenge, poorly managed in most large enterprises, is the alignment of the systems inventory with the financial accounts supporting IT. It’s a classic dimensional data problem, where the systems inventory becomes a primary dimension – and as any data warehousing expert can attest, data that is not aligned along common dimensions is “disparate” and cannot be effectively analyzed. Getting started on this problem is one reason I advocate the initiation of a formal application portfolio in any shop, no matter the maturity.
Again, data items such as “Annual maintenance costs” are problematic “attributes.” At best, they are “denormalized” or “derived” data which means that they may be the output of aggregate operators such as SUM or COUNT run against voluminous source tables of cost detail. “Production metrics” and “Support metrics” are woefully imprecise; there are dozens of possible numbers that could be published, again mostly derived data.
Substantial analysis of the source systems and building of complex interfaces would be necessary to populate the application portfolio system with much of this data, and as I have argued elsewhere, internal IT data tends to be among the most troublesome to move about. Industry standards are badly needed, fragmented, and (as of this 6/2004 writing) mired in seemingly intractable political conflicts.
Conclusion
Some final thoughts: There is much from the software engineering literature that this volume would have benefited by including. For example, some indication of an application system’s complexity (e.g. cyclomatic complexity and related metrics) would be very useful information.
The emerging discipline of quantitative IT portfolio management would have much to offer as well; supporting this from an application portfolio system would require complete metrics on project schedules and budgets.
However, the volume remains an important contribution; highly recommended.
