Rubic_Print_Format

252

C h a p t e r

17 Application Portfolio Management1

According to many industry assessments, the typical IT organization spends as much as 80 percent of its human and capital resources maintaining an ever-growing inventory of applications and supporting infrastructure (Serena 2007). Although no one argues with the importance of maintaining applications (after all, they do run the business), everyone is concerned with rebalancing the IT budget allocation to increase the discretionary spend by decreas- ing the maintenance spend, ensuring that the set of applications is well aligned with business needs, and positioning the organization technologically to respond to future initiatives. Collectively, this activity has come to be known as “application portfolio management” (APM).

Formally, APM is the ongoing management process of categorization, assessment, and rationalization of the IT application portfolio. It allows organizations to identify which applications to maintain, invest in, replace, or retire, and it can have signifi- cant impact on the selection of new business applications and the projects required to deliver them. The overall goal of APM is to enable organizations to determine the best approach for IT to meet business demands from both a tactical and strategic perspective through the use of capital and operating funds allocated to building and maintaining applications. APM typically includes an analysis of operating and capital expenses by application, demand analysis (i.e., assessing business demand at the application level to determine its strategic and tactical business drivers), and application portfolio analysis (i.e., the current versus the desired state of the application portfolio in terms of both technology and business value).

Although APM is not a new idea, it may be one whose time has come. There are many espoused benefits of APM, including reduction of the cost and complexity of the applications portfolio, reduction or elimination of redundant functionality, optimization

1 This chapter is based on the authors’ previously published article, McKeen, J. D., and H. A. Smith. “Application Portfolio Management.” Communications of the Association for Information Systems 26, no. 9 (March 2010): 157–70. Reproduced by permission of the Association for Information Systems.

Chapter 17 • Application Portfolio Management 253

of IT assets across different applications and functions, greater alignment with the busi- ness, better business decisions regarding technology, and an effective means of commu- nicating the contribution of IT to the overall organization.

This chapter begins by examining the current status of IT applications in organizations. It then examines the notions of a portfolio perspective as it applies to applications (in contrast to a portfolio of financial assets) and outlines the specific ben- efits of such a perspective. Implementing a successful APM initiative requires three key capabilities—strategy and governance, inventory management, and reporting and rationalization—which are described in detail. The chapter concludes with some key lessons learned by organizations having invested in APM.

The ApplicATions QuAgmire

Born of autonomous business-unit-level decision making and mergers and acquisitions, many IT organizations manage multiple ERP applications, knowl- edge management systems, and BI and reporting tools. All are maintained and periodically upgraded, leading to costly duplication and unnecessary complexity in IT operations. Left unchecked, the demands on the IT organization to simply maintain its existing inventory of applications threatens to consume the capacity to deliver new projects. (Serena 2007)

The proliferation of application systems within organizations is legendary. Built over time to serve an ever-changing set of business requirements, such systems span generations of technologies (e.g., hardware, software, systems, and methodologies), many of which are now obsolete and unsupported by the vendor community, are host to countless “workarounds,” remain poorly documented, depend on the knowledge of a rapidly retiring workforce, and yet continue to support the key operations of the organization. Some (if not many) of these application systems have never been revisited to ascertain their ongoing contribution to the business. Based on decisions made by separate business units, many applications duplicate the functionality of others and are clearly redundant, and others have become unnecessary but have managed to escape detection. Accounts of organizations continuing to pay licensing fees for decommis- sioned software and supporting 27 different payroll systems all attest to the level of disarray that typically exists in large organizations. The full impact of such a quagmire becomes apparent either when virtually the entire IT budget is consumed by mainte- nance and/or when an organization attempts to integrate its suite of applications with those of an acquiring firm—whichever comes first.

Cause and effect are straightforward. The number of applications grows due to the practice of continually adding new applications without eliminating old ones. As it grows, the number of interfaces increases exponentially as does the number of complex and often proprietary enterprise application integration (EAI) solutions to “bridge” these disparate systems. The combined effect is to increase the frequency of (and costs of supporting) redundant systems, data, and capabilities across the orga- nization. As their number and complexity grow, so does the workload and, without expanding IT budgets and headcounts commensurably, so does the portion of the IT

254 Section IV • IT Portfolio Development and Management

budget devoted to maintenance and operations. From a management perspective, organizations are left with shrinking discretionary funds for new IT development and find themselves unable to assess the capability or measure the adequacy and value of current application support structures, track dependencies of business processes on applications, determine where money is being spent, and map IT investments to busi- ness objectives. Thus, in many organizations, the suite of IT applications has become unmanageable.

But while the cause and effect are identifiable, remedies are not easily obtained. The first obstacle is resources:

The practice of continually adding to the IT burden while holding IT budgets and head counts relatively flat is obviously problematic. Yet that’s exactly what many companies have done since the early 2000s. And this practice is one of the reasons why many CIOs feel that they simply don’t have enough resources to meet inter- nal demand for IT. (Gomolski 2004)

A second barrier is that few business managers want to give up any application once it’s installed. In their minds, the agony of change is clearly not worth the rewards. “Some applications are so old that nobody remembers who ordered them” (Gomolski 2004, 29).

The third impediment, and perhaps the most severe, is the fact that IT often lacks the political clout to make business managers engage in an exercise to rationalize appli- cations across the enterprise in order to decommission some applications.

The BenefiTs of A porTfolio perspecTive

A part of the application dilemma is the lack of a portfolio perspective. Historically, organizations have opted to evaluate applications exclusively on their own merits—a practice that can easily promulgate unique systems across any business unit that can justify the expense. One manager claimed that this practice results in “a stream of one- off decisions . . . where each decision is innocent enough but, sooner or later, you are in a mess . . . sort of like walking off a cliff using baby steps.”

In contrast, adopting a “portfolio” perspective means evaluating new and existing applications collectively on an ongoing basis to determine which applications provide value to the business in order to support decisions to replace, retire, or further invest in applications across the enterprise. The portfolio approach is universal in finance and provides a point of comparison. Boivie (2003) presents the following analogy:

Just imagine you bought stock a decade ago for a lot of money, a good invest- ment at the time, but then you did not review its value over the intervening years. Merely sitting on the stock may have been the right thing to do. Then again, you may have missed opportunities to invest more profitably elsewhere if the company was not doing well, or to invest more in the stock if it was prof- itable. Obviously this is not a wise way to handle your investment, but it’s exactly what many companies are doing when it comes to investments in their IT applications!

Chapter 17 • Application Portfolio Management 255

Kramer (2006) concurs that application portfolio management is similar to the approach used by portfolio managers at money management firms where “invest- ment officers continually seek to optimize their portfolios by assessing holdings and selling off assets that no longer are performing.” It is suggested that “the same approach can be used by technology executives, especially when evaluating the applications in their portfolios and deciding which ones to continue funding, which to pull back on, and which to sunset or kill.” One firm highlighted the similarities between investment portfolio management and applications portfolio manage- ment (see Table 17.1) in order to advocate for adopting a portfolio approach for IT applications.

The focus group suggested that the requirement for all new investments (i.e., IT applications) to be evaluated relative to all existing (i.e., past) investments within the portfolio is arguably the critical benefit provided by adopting a portfolio perspective. The group urged caution, however, due to the differences between a portfolio of financial assets (e.g., stocks and bonds) and one of IT applications. With the former, we assume a degree of independence among assets that rarely exists with applications. According to one writer (Anonymous 2008), “while financial plan- ners can sell an underperforming stock, CIOs will likely find it far more difficult to dispose of an unwieldy application.” Applications are rarely stand-alone; business

Table 17.1 Managing IT applications as a Financial Portfolio

Investment Portfolio Management application Portfolio Management

Professional management but the client owns the portfolio.

Professional management but the business owns the portfolio.

Personal financial portfolio balanced across investments in • equities • fixed income • cash

Application portfolio balanced across investments in • new applications • currency (maintenance, enhancements,

upgrades) • retiring/decommissioning

Client directs investment where needed (e.g., 50% equities, 40% fixed, 10% cash).

Business directs investments where needed (e.g., 40% new applications, 30% currency, 30% decommissioning).

Client provides direction on diversity across investments (e.g., investment in one fund would exclude/augment investment in other funds).

Business provides direction on diversity of investment (e.g., investment in one business capability might exclude/augment investment in another).

Client receives quarterly updates on its portfolio health and an annual report.

Business receives quarterly updates on application portfolio health and an annual report.

New investments are evaluated on their impact on the overall portfolio as well as on their own merits.

New applications are evaluated on their impact on the overall portfolio as well as on their own merits.

256 Section IV • IT Portfolio Development and Management

functionality is often delivered by an integrated web of applications that cannot be separated piecemeal. As a result, diversification strategies can be difficult where IT assets are highly interdependent and deliver returns only collectively (Kasargod and Bondugula 2005).

A portfolio perspective forces the linkage between the set of existing applications (i.e., the applications portfolio) and the set of potential applications (i.e., the project port- folio). The linkage is bidirectional—that is, potential applications must be evaluated against existing applications and vice versa. Caruso (2007) differentiates these as follows:

• Application portfolio. The focus of the application portfolio is on the spending for established applications, trying to balance expense against value. These applications may be assessed for their contribution to corporate profitability and also on nonfinan- cial criteria such as stability, usability, and technical obsolescence.

• Project portfolio. Management of the project portfolio focuses on future spending, attempting to balance IT cost-reduction efforts and investments to develop new capabilities with technology and application upgrades.

The focus group suggested that organizations have focused most of their attention on new projects which has, in part, resulted in the applications quagmire previously described. The focus of this chapter is on application portfolio management. It argues that the effectiveness of the project portfolio can be enhanced substantially by managing the application portfolio much more judiciously. This linkage is made explicit later in the chapter.

The benefits to be realized by adopting an applications portfolio perspective are significant. The focus group was polled to solicit the benefits that their organizations had identified. These benefits were then grouped into the three categories, as suggested by Caruso (2007) and are presented in Table 17.2.

The list of benefits is impressive. To put them into perspective, a number of com- ments are in order. First, if the benefits to be realized are this substantial, why haven’t organizations moved more aggressively to enact APM practices? The short answer is that APM has been difficult to fund and, once funded, represents an enormous man- agement challenge. Second, the majority of these are “anticipated” benefits as they have yet to be reaped by focus group firms. Third, APM requires the development of a number of related activities (described in the latter sections of this chapter). Although benefits are realized during individual activities, the most significant benefits are not realized until most, if not all, of these capabilities have been completed. Finally, APM involves a different way of approaching IT investments—a collective view of all IT applications across the enterprise—which has cultural and political ramifications for organizations. The good news is that organizations that are well advanced in APM have realized significant benefits. We highlight one such firm in Table 17.3.

mAking Apm hAppen

Application portfolio management presents a significant management challenge and success requires the commitment of considerable organizational resources. The focus group suggested that APM involves the development of three interrelated capabilities. The first capability is the articulation of a strategy including goals, deliverables, and

Chapter 17 • Application Portfolio Management 257

Table 17.2 a list of aPM benefits

1. Visibility into where money is being spent, which ultimately provides the baseline to measure value creation a. Increasing the ease of determining which legacy applications are to be retired. b. Simplifying the technical environment and lowering operating costs. c. Reducing the number of applications and optimizing spending on application

maintenance. d. Increasing the predictability of measuring service delivery for project selection. e. An enterprise view of all applications allowing for ease of reporting (e.g., How many

applications use Sybase? How many systems support sales reporting?) f. A common view of enterprise technology assets improving reuse and sharing across

the enterprise. g. Clarity over maintenance and support spending. h. Ability to manage and track business controls and regulatory compliance of all

applications.

2. Prioritization of applications across multiple dimensions, including value to the business, urgency, and financial return a. Funding the right application effort by providing quick access to validated information

in support of business cases for investment. b. Providing better project solutions by identifying available capabilities for reuse. c. Providing criteria to drive application rationalization and monitor impacts. d. Providing an “end state” view for all applications, which helps direct roadmaps and

enables progress reporting. e. Expediting prioritization discussions and executive decision making. f. Driving IT refurbishment initiatives.

3. A mechanism to ensure that applications map directly to business objectives a. Aligning business and IT efforts with business processes by providing (1) clarity of the

application landscape, leading to synergies across different business units, and the pur- suit of a global systems architecture; and (2) insight into gaps or redundancies in the current portfolio, thereby enhancing the ability to manage risk effectively and efficiently.

b. Enabling productive discussion with senior management regarding IT’s contribution to business value.

c. Identifying the strategic and high business value applications, thereby allowing the redirection of some of the funding previously used for nonstrategic applications.

d. Enabling easy and effectively analysis of impacts to applications from changing business conditions.

e. Improving the focus and direction of investments. f. Developing a vehicle to drive the technical portfolio to the “right” mix, based on strategy,

architecture, TCO, and internal skill sets. g. Prioritizing efforts and focus for IT delivery—ensuring the right skills are in place to

support business requirements.

a set of governance procedures to guide the management of the application portfolio. Next is the creation of an applications inventory to monitor key attributes of existing applications. The third capability involves building an analysis and reporting capability in order to rationalize the applications portfolio according to the strategy established.

258 Section IV • IT Portfolio Development and Management

These capabilities (depicted in Figure 17.1), although distinct, are closely interrelated and work synergistically.2 To deliver value with APM, organizations must establish all three capabilities. Experience suggests that organizations typically start by inventory- ing applications and work from the middle out to refine their APM strategy (and how it is governed) as well as to establish efforts to rationalize their applications portfolio. As such, APM represents a process of continual refinement. Fortunately, experience also suggests that there are real benefits to be reaped from the successful development of each capability. These capabilities are described in detail next.

capability 1: strategy and governance

There are many different reasons to adopt application portfolio management. At one firm, the complexity of the IT application portfolio had increased to the point of becoming unmanageable. The firm viewed APM as the means to gain some measure of control over a burgeoning collection of disjointed IT applications. Another firm had set an architectural direction and established an IT roadmap and viewed APM as a way

Table 17.3 an aPM Case Study

Vision

• Reverse the rising tide of application maintenance costs. • Fund strategic development efforts from reduced support and maintenance costs. • Align IT with business goals.

Challenge

• Assess current portfolio of applications. • Establish targets, savings strategies, and supporting plans. • Data currency and accuracy.

Solution

• Identify redundant or obsolete applications and set end-of-year targets for retiring a committed percentage of the total.

• Classify applications by their strategic value and shift maintenance support focus to highly strategic applications.

• Rank applications with a quality score; applications failing to meet a baseline are selected for preventive maintenance, code simplification, and maintainability.

• Migrate an increasing share of maintenance work to lower-case geographies.

Value

• Cut applications by 70%. • Establish rigorous priorities—SLAs now vary based on objective business criteria. • Reengineered applications—defects down 58% and maintenance costs down 20%. • Relocated work—significant maintenance is now performed in countries with costs

60–70% lower than previously.

2 The focus group did not see APM as a “stage” model where organizations advance through a prescribed set of stages. Instead they identified three highly interrelated “capabilities” that organizations need to establish in order to advance their application portfolio management.

Chapter 17 • Application Portfolio Management 259

to “put some teeth” into the enforcement of these policies. At a third firm, the man- ager of a strategic business unit was frustrated over escalating annual IT costs and the “pile of applications” that seemed to have “little connection to actual business services.” A simple poll of the focus group, however, suggested that APM tended to be an IT-led initiative as opposed to a business initiative—a fact that has implications for launching and funding APM.

To get an APM initiative underway, it is necessary to build a business case. How this is done depends on the firm’s strategy. According to one manager, “[I]f APM is positioned as inventory management, you’ll never get the business to pay for it.” In his organization, APM was promoted as a cost-reduction initiative focused on the elimination of unused (or underused) applications, unnecessary software licenses, duplicated data, and redun- dant applications. The business case included an aggressive schedule of declining IT costs to the business. In another organization, the APM initiative is supported internally by the IT organization and driven largely by the enterprise architecture group. In fact, the business is unaware of its APM program. In a third organization, APM was couched within the overall strategy of transforming the business. The argument was that APM could “reduce ongoing support costs for existing applications in order to re-direct that IT spend into business transformation.” The business case included metrics and a quar- terly reporting structure to ensure that savings targets were obtained. The conclusion reached by the focus group was that each organization is unique and, given the wide variety of potential APM benefits, the best strategy is to attach APM to a broader enter- prise goal. They felt that if APM is attempted solely within the IT organization without business backing, it is less likely to produce the full range of benefits.

The strategy selected to launch APM has direct ramifications for the information collected about each application (i.e., the second capability—inventory management) as well as what information is reported and tracked by senior management (i.e., the third capability—reporting and rationalization). In the next section of this chapter, we present a comprehensive set of information that could be collected for IT applications within the portfolio. Organizations, depending on their APM strategy, may focus on a subset of this information and develop a reporting and rationalization capability built on this information.

APM strategy and governance are linked; if strategy is the destination, then governance is the map. According to one manager, governance is “a set of policies,

Strategy and Governance

Inventory Management

Reporting and Rationalization

figure 17.1 Key APM Capabilities

260 Section IV • IT Portfolio Development and Management

procedures, and rules that guide decisions and define decision rights in an organization.” Application portfolio governance answers three questions:

1. What decisions need to be made? This addresses the types and/or categories of decisions often referred to as decision domains. It also links the decisions with the processes that are needed to manage the application portfolio.

2. Who should make these decisions? This addresses the roles and accountabili- ties for decision makers (e.g., who provides input, who approves and has final authority). This links the decisions to be made (the “what”) with the decision makers (the “who”).

3. How are these decisions made? This addresses the structures and processes for decision making (e.g., the architecture review board). This links the decisions to be made (the “what”) with the people/roles (the “who”) involved in decision making with the timelines and mechanisms for making those decisions (the “how”).

On an ongoing basis, organizations introduce new applications and (infrequently) retire old applications. The key difference with APM is that these applications are managed holistically across the enterprise on a much more formalized and less piecemeal basis. The goal is to discover synergies as well as duplication, alternative (and less costly) methods for providing business services, and rebalancing (or rationalizing) the portfolio of applica- tions with regard to age, capability, and/or technical health. This represents a significant organizational change that impacts governance procedures directly. According to one IT manager, “no longer can business units acquire an IT application that duplicates existing functionality without scrutiny by the APM police.” With the adoption of APM governance procedures, such actions become visible at high levels within the organization.

How new governance procedures are actually implemented varies by organiza- tion. However, the focus group suggested that effective APM governance must be both freestanding (in order to have visibility and impact) as well as closely integrated within the framework of existing governance mechanisms (in order to effect the status quo). As an example, the IT project selection committee must consider the impact of prospec- tive IT projects on the existing portfolio of enterprise applications if the organization is to achieve its APM rationalization goals regarding architecture and/or functionality. That is, the APM governance processes must leverage existing organizational gover- nance processes, including architectural reviews, exception process handling, IT delivery processes, strategic planning and annual budgeting, and technology reinvestment and renewal. One manager shared his enterprise IT governance framework to demonstrate where and how APM was situated within other established processes (see Figure 17.2).

Effective governance starts with ownership, which entails responsibilities and accountabilities. At a tactical level, each IT application should have an owner. This indi- vidual is held responsible for the ultimate disposition of the application—that is, when it is enhanced, refurbished, or decommissioned. The sense of the focus group was that the application owner should be a business manager—except for internal IT applications. Each application should have a business owner, and it is common to also appoint a cus- todian whose key duty is to keep the information current. Given the technical nature of the application information (see Appendix A), the custodian is typically an IT employee, perhaps an account manager or someone within the enterprise architecture group.

With stewardship (i.e., owner and custodian) assigned for major applications, the next level of governance is the portfolio level. A management committee comprised

Chapter 17 • Application Portfolio Management 261

of application owners, senior enterprise architects, and IT planners/strategists should meet regularly, perhaps quarterly, to make decisions regarding the disposition of applications within the overall portfolio. This committee would report to the senior exec- utive on portfolio activities, performance toward goal achievement, and establishment of linkages to fiscal planning and strategy. In very large organizations, an additional committee of portfolio owners might also be required.

Effective governance is critical for overcoming a number of problems common during the initial phases of APM. Some of the challenges experienced by the focus group included the following:

• Application owners are accountable to execute the process, but no one has defined who (or what body) is accountable for the process itself or what governance practices should be applied to make it happen.

• Managing applications requires additional maturity for defining a roadmap for the portfolio. Without this, some applications are well planned while the overall portfo- lio is not.

• The classification criteria for applications are in flux and lack an executive process for validating the ratings.

• Application assessments are not taken seriously by executive owners (“Everything is critical”), which erodes the credibility of the process and the overall value of the exercise of managing applications as a portfolio.

• Business managers lack awareness and accountability. • There is difficulty from the “supply” side—for example, there is reluctance to take

ownership of the data to ensure its integrity, quality, and timeliness. • Demand-side aggression pushes for more and more application attributes.

Enterprise Business Objectives

Enterprise Strategy

IT Plan (policies, principles, road map)

Critical Success Factors

KPIs and Balanced Scorecard

Mandatory Projects

IT Investment Opportunities

Application Transformation Project Proposals

Approved New Projects

New/Modified Applications

Investment Portfolio

Management

Project Portfolio

Management

Application Portfolio

Management

figure 17.2 Positioning APM within an Enterprise IT Governance Framework

262 Section IV • IT Portfolio Development and Management

The focus group felt that each of these problems requires effective governance procedures. But like all organizational initiatives, changes to existing routines and methods take time to mature.

capability 2: inventory management

Before building an inventory of applications, organizations first need to know what applications they are going to inventory. One firm started by defining an applica- tion as a computer program or set of computer instructions that allows end users to accomplish one of more specific business tasks and is able to operate independently of other applications. An application can also be a distinct data store used by multiple other applications. Examples include commercial off-the-shelf packages, applications written in Excel that perform specific business functions, custom-developed computer software programs, a data warehouse and/or the reporting applications accessing it, and/or modules, services, or components, either purchased or custom built to perform a specific business function. This definition excludes system software or platform software (e.g., operating systems, device drivers, or diagnostic tools), programming software, and user-written macros and scripts.

What is most important is that organizations identify which specific applications will be included in the portfolio to be actively managed. One firm excluded all applica- tions not explicitly managed by IT (e.g., Excel spreadsheets developed by managers for analytical purposes), another focused only on “major” applications according to size, and a third firm only included “business-critical” applications. This decision has direct implications for the size of the APM effort. The organization that limited its portfolio to business-critical applications reduced the portfolio to 180 applications from 1,200—a significant reduction in the amount of effort required. The organization’s decision to limit (and therefore focus) its application portfolio depends on the strategy outlined in the first step.

With inclusion criteria established, organizations must then identify what specific information about applications will need to be captured. A list of possible information items gathered from the members of the focus group is presented in Appendix A. These items are categorized according to the following five headings:

• General application information is the information used to explicitly and clearly identify an application, distinct from all other applications, and provide a basic under- standing of its functionality.

• Application categorization is the information providing criteria used to group applications for comparison and portfolio management purposes (e.g., business capability provided, life cycle status).

• Technical condition provides the overall rating of the technical quality of the appli- cation, including various elements of risk (e.g., development language, operating system, architecture).

• Business value provides an overall rating of the value of the application to the busi- ness (e.g., business criticality, user base, effectiveness).

• Support cost captures the order of magnitude of the overall cost of an application after deployment. It includes maintenance and support costs (including upgrades) but not the initial purchase, development, or deployment costs.

Chapter 17 • Application Portfolio Management 263

The focus group could not overstate the importance and criticality of selecting the information to be maintained as part of the application inventory as this information dictates the types of analyses that can be performed after the fact (as outlined in the next section). Once selected, the task of capturing application information and keeping it current is a monumental effort. Without clear ownership of the information and assigned respon- sibilities for a custodial function, attempts at application portfolio management typically falter. One of the key motivations for establishing a strict information regime is the delivery of demonstrable benefits from the exercise. These are discussed in the next section.

capability 3: reporting and rationalization

With an application inventory established, a set of standard parameter-driven reports can be produced to monitor the status of all existing applications so management can read- ily ascertain the health of any specific application or the overall health of the port folio of applications. One firm has a collection of standard reports that analyze the number of applications and their costs, how business capabilities are supported and where duplica- tion exists, breakdowns of annual application costs, application life-cycle patterns, and reuse options for future projects. One widely adopted report compares applications on the basis of business value, technical condition, and cost (see Figure 17.3). As depicted, this chart helps organizations rationalize their IT application portfolio by tracking appli- cations over time as they become less important to the business and/or lose technical currency. One organization found that eliminating those applications in the bottom left of the quadrant—which provide limited business benefit, often at a significant cost—can be a “combination of quick hits and longer-term initiatives.” Even managers reluctant to retire a business application can be convinced with evidence of the full-support costs.

Once the application inventory is assembled, the number of ways to “slice and dice” the information is unlimited and the value obtained is commensurate. One

Reassess

Business Value

T e c h

n ic

a l C

o n

d it

io n

Size represents cost

HighLow

H ig

h L o w

Retire Replace

Renew

figure 17.3 Application Portfolio Highlighting Business Value, Technical Condition, and Cost

264 Section IV • IT Portfolio Development and Management

manager claimed that for the first time her organization is able to answer questions such as “How many applications use Sybase?” and “How many systems support sales reporting”? The provision of ad hoc reporting capability is a quick way to discover the number of current licenses with a specific vendor and/or to assess the costs of providing specific business services. Ultimately, organizations need to know their true costs of doing business in order to explore options for providing different customer services. The information produced by analyzing the IT application portfolio takes organizations a huge step closer to this level of understanding and optimization.

The information needs supported by an application inventory vary by stake- holder. The IT organization wants to map business functionality against applications; the risk, audit, and security teams are most interested in regulatory compliance and a risk management perspective; and business teams are interested in understanding the costs and business value of the applications they use. Even within IT, different groups (e.g.,  solutions delivery, information security, production support, executive management, business continuity, regulatory compliance, infrastructure, architecture, and planning) have information needs that are unique from the application portfolio. For this reason, most firms mandate a single application portfolio capable of support- ing many different views at different levels as well as a composite view of the entire portfolio. One manager explained this by claiming that although different views of the portfolio satisfy individual groups within her organization, the “consolidated view ultimately demonstrates the effectiveness of monitoring and tracking business perfor- mance of the assets across the entire IT application portfolio.”

key lessons leArned

The following represent some of the lessons learned based on the collective experience of the members of the focus group:

• Balance demand and supply. Managers tend to push for the inclusion of more and different application attributes as well as more reports of infinite variety (the  “demand” side) while balking at assuming ownership of this data in order to ensure its integrity, quality, and timeliness (the “supply” side). When launching an APM initiative, clear governance procedures should be established to govern regular enhancements and releases for APM reporting.

• Look for quick wins. Gaining awareness and acceptance of an APM initiative can be an uphill struggle. This effort is aided greatly by capturing a number of “quick wins” early on. For example, organizations should look carefully at the possibility of decommissioning applications as a ready source of immediate and visible wins that impact the bottom line directly. Reuse provides midterm wins, and rationaliza- tion provides longer-term wins.

• Capture data at key life stages. It is a mistake to wait to capture data when applications are already in production. Data should be captured at multiple stages—when the application is first approved, when in testing, when promoted to production, during significant modifications, and when retired. As soon as data are captured and made available, the organization can benefit. For example, know- ing the attributes of applications under development can be valuable for planning/ budgeting purposes and ultimately enables better project solutions.

Chapter 17 • Application Portfolio Management 265

• Tie APM to TCO initiatives together. If a total cost of ownership (TCO) initiative is underway, ensure that the APM is closely tied to the TCO initiative. Much of the information captured as part of the APM initiative will support the TCO initiative— and vice versa. Knowing this relationship in advance will ensure that the data are captured to facilitate both purposes. The long-term savings can be significant.

• Provide an application “end-state” view. It is important to provide current infor- mation about applications, but it is equally important to provide an end-state view indicating the application’s future trajectory. This facilitates a planned and orderly evolution toward retirement for applications as well as key information for busi- ness planning (e.g., roadmaps, gap reporting, and progress reporting).

• Communicate APM benefits. Gaining awareness and acceptance of an APM initiative is a constant struggle. Organizations must seek opportunities to commu- nicate why this initiative is underway, what results have been realized, and what the next stages to be accomplished are. Effective communication is even more important in situations where the APM initiative is being driven internally by the IT organization.

This chapter provides guidance to those investigating APM and/or planning to launch an APM initiative. Application portfo- lio management promises significant benefits to adopting organizations. Obtaining those benefits, however, requires the development of three mutually reinforcing capabilities. The first capability is the development an APM strategy buttressed with governance procedures, the second is the creation of an application inventory, and the third is a

reporting capability built to align the appli- cation portfolio with the established strategy. Each of these capabilities provides stand- alone benefits, but together they enable an organization to optimize its IT application assets, reduce the cost and complexity of its portfolio, reduce or eliminate redundant functionality, facilitate better business deci- sions regarding technology, and effectively communicate the  contribution of IT to the overall organization.

Conclusion

Anonymous. “Maximizing IT Investment.” Wall Street & Technology, April 2008.

Boivie, C. A. “Taking Stock of Your Portfolio: Do You Have a Good Idea of the Value of Your IT Applications, Both Old and New?” CIO Canada 11, no. 10 (October 2003).

Caruso, D. “Application Portfolio Management: A Necessity for Future IT.” Manufacturing Business Technology 25, no. 10 (October 2007): 48.

Gomolski, B. “Cleaning House.” Computerworld 38, no. 51 (December 2004).

Kasargod, D., and Bondugula, K. “Application Portfolio Management.” Infosys (April 2005): 1–8. Originally published in www.gtnews.com.

Kramer, L. “CIO Challenge: Application Portfolio Management.” Wall Street & Technology, May 2006.

Serena Software Inc. “Application Portfolio Management (APM): Solving the Challenges of APM with Serena® Mariner®,” 2007. www.serena. com/docs/repository/products/mariner/ datasheet-apm-mariner.pdf (accessed March 12, 2011).

References