The Executive Guide to Application Management Andy Kyte Gartner Symposium/ITxpo 2011 October 16-20, 2011 Walt Disney World Dolphin Orlando, FL Andy Kyte Notes accompany this presentation. Please select Notes Page view. These materials can be reproduced only with written approval from Gartner. Such approvals must be requested via e-mail: vendor.relations@gartner.com. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2011 Gartner, Inc. and/or its affiliates. All rights reserved.

You Need to Know Because … Applications Are Expensive Applications Are Important Applications Rust Applications Can Help You Win! Why business executives should care about business applications. Applications Are Expensive. This isn't news, but it is necessary to understand that applications are getting more expensive. This is somewhat counterintuitive. Executives often believe that applications are becoming cheaper through a combination of Moore's Law and the development of cloud services. Although the price for some commodity applications may come down, the costs associated with large- scale applications are continuing to grow. Applications Are Important. Business applications are the heart and lungs of a business: They pump information through the processes that deliver the business value proposition. Applications Rust. Applications are complex engineering artifacts that decay, because the stack on which they depend gradually becomes unsupported, or the skills necessary to support and maintain them become scarce, or for many other reasons. Business executives need to understand the engineering integrity of the applications on which they depend. Applications Can Help You Win. Whatever your business objectives, it's likely that changing existing applications or acquiring new applications will be part of your steps to success. The more you understand about how to manage applications, the better you are positioned for business success.

You Need to Know Because … For 21st Century Executive Managers, a Firm Grasp of the Principles of Application Management Will Be a Critical Career Capability. Why do business executives need to know anything about managing applications? Applications are tools that manage information and processes. Executives everywhere, from public sector to private sector, from financial services to manufacturing, from retail to shipbuilding – all are making business-critical (and career critical) decisions based on information. All are responsible for process efficiency and effectiveness, compliance with corporate and legislative policies, and tactical and strategic imperatives. All of these critical executive tasks depend on business applications that cost huge sums of money to acquire and develop, cost even more to operate and sustain, and seem to take for ever to change when the external markets or regulators demand modifications in the application value proposition. Given the central role of applications in both the day-to-day operation of a business unit and in the strategic transformation of a business, executives cannot afford to remain ignorant about the key elements of the discipline of application management. Executives are smart people — they are responsible for huge swathes of a business operation. However, many executives lack sufficient understanding of the mechanisms and economics of applications to be able to use their smarts to optimize outcomes. Developing a better understanding of how to participate fully in the management of applications is essential for executive development.

Key Issues 1. What are business applications, and why do business managers need to understand them? 2. How should business executives participate in the process of investing in business applications?

Applications Are a Large, Diverse Family Systems of Innovation Planned Persistence 1–3 Years ~$100,000 Refactor Systems of Differentiation Planned Persistence 8–10 Years $1 million– $10 million Refactor Systems of Record Planned Persistence 20–25 Years $10 million– $100 million+ Telling me that you have an application portfolio is a little like telling me that you have a property portfolio. You could have a couple of shacks in the boondocks, or you could own skyscrapers in major metropolitan areas around the world. Applications come in all shapes and sizes, from small and simple to extremely large and complex. We find it very helpful to break the portfolio into three major categories using a technique that we call Pace Layering At the bottom are the "Systems of Record": large applications that tend to have a very long persistence, which are typically expensive and slow to change but which tend to be highly robust and reliable. Typical "Systems of Record" would be ERP systems, or significant numbers of the application components of SCM or CRM systems, or core banking or policy administration systems. These systems underpin "Systems of Differentiation," which tend to be more focused on a specific business unit or single component business process, but which are integrated with the underlying systems of record. And at the top are "Systems of Innovation," which are rarely freestanding applications: They normally interoperate with lower-level systems. A lot of the investments being made in mobile applications are producing "Systems of Innovation."

Application Sourcing: Not Just Buy Versus Build Buy and Customize Build Buy and Configure Subscribe Business Process Outsourcing Applications provide services that manage data and processes. No one doubts the need for business applications: no one advocates returning to quill pen or multipart stationery, but the need for access to business applications can be satisfied in various ways, each one of which brings a set of costs, benefits and risks. The more sophisticated models for the delivery of business process outsourcing (BPO) effectively shield the enterprise from the technology of the application: The executive task here is to participate in the management of the outsourcing services provider. The "Subscription" model, also known as "software as a service" (SaaS), popularized through application services such as salesforce.com, means that there's little or no capital outlay: the full technology stack is managed by the service provider. "Buy and Configure" is also known as "COTS Vanilla." COTS stands for commercial off the shelf, otherwise known as packaged application, such as ERP or CRM. The "Vanilla" means the basic implementation model, where vendor- supplied and supported configuration options tune the application to enterprise requirements. "Build" involves creating an application by hiring or contracting designers, business analysts, technologists, programmers, etc. to create the application to meet the needs of the business. "Buy and Customize" involves taking a CoTS application, then making changes to the source code, often employing a third party. Each one of these choices can be an appropriate selection in specific circumstances, but it is vital that the business executive gains full understanding of the total lifetime cost and agility provided be each option.

An Application Is Part of a Complex Ecosystem Most businesses live with an accidental architecture to their applications portfolio. Each individual application has been acquired to meet the specific needs of part of the business, often with very little attention being paid to the need to manage the total portfolio in the best possible way. This "silo" approach to application acquisition is destructive of value, because it leads to high fixed costs as the IT department has to maintain skills and licenses for a diverse portfolio of application stacks such as operating systems, databases and languages. The diversity of technologies in these silos also create difficulties in integration and delivery of end-to-end process management and corporate initiatives such as "single view of the customer". This accidental architecture creates to software equivalent of a shanty town, where there is no coherent planning process, no zoning regulations and no common services. The challenge facing businesses is to transition from 20th Century accidental architectures and their application shanty towns toward a more planned environment, with more common services, less complexity and lower cost. Unfortunately, whilst most would agree with this in theory, in practice business executives have a tendency to insist on applications that they believe will best fit their silo, and leave others to deal with the consequences of high complexity, high costs and integration challenges. It takes strong executive leadership to balance the needs of an individual business units with the needs of the business as a whole.

An Application Is an Asset The Industrial Revolution developed accounting standards for fixed assets. Accountants use sophisticated depreciation formulas. Shareholders are protected by a "sinking fund." In the "Information Revolution," accountancy practice is trailing behind asset value delivery. Applications are assets — in many cases, the most-valuable assets an enterprise owns. Shareholders have no mechanisms to value assets — and no "sinking fund." What is an application worth? There are two ways to answer this question. The first concerns the asset value; the second concerns the value delivered by the asset. Today, these questions are almost impossible to answer, because most organizations do not treat applications as assets, and do not measure the contribution made by an application. The failure to provide valuations is partly because most businesses haven't started to value their intangible assets and partly because, historically, IT investments were seen as project-based capital services, not asset acquisition activities. However, even if an enlightened business decides to place a value on an application, it is immediately faced with a complete absence of financial models: There are no generally accepted accounting principles (GAAP/IFRS) standards for valuing application assets. The journey to treating applications as assets is a long one and will require much dialogue between IT and finance. IT managers will need to learn the general principles used by finance managers to identify, tag, value, depreciate and manage assets. Finance managers will need to learn the special characteristics of applications. But eventually, the rapprochement will bring about a fundamental transformation of IT management practices. In particular, by paying attention to the value of the asset — and therefore considering how continuing investment can reverse depreciation — IT management may be able to start to get off the treadmill of the annual budget cycle and move toward a financing cycle more aligned with the assets under management.

An Application Is a Liability The Application The Stack Trained business users Architectural compliance Technology skills Application server Application integration Operating system Data and Information Tools for management Tools for testing … … When you drive a new vehicle out of the showroom, its value plummets and continues to fall throughout the life of the vehicle. If the owner is a careful driver, garages the vehicle every night, keeps it waxed and polished and regularly serviced, the rate of depreciation will be less then if the vehicle is abused. We all understand depreciation at home and in tangible fixed assets in the workplace, but we seem unable to transfer the model to intangible assets, such as IT systems. Application assets have a habit of depreciating even before they go live, and the potential value, usefulness and cost of operation and ownership of the application can be severely impacted by changes in user requirements and in the status of stack components. The key elements of the stack that are most likely to impact the application are in the software infrastructure — everything from the application server and database through to the operating system — and in the skills stack — the people resources needed to develop, support and maintain the application. An application strategy needs to maintain a detailed understanding of the viability of all components in the stack and the future plans for those components.

Example Range of Go-Live Costs as a Percentage of 15-Year TCO 16% 6% High 8% "Design for Life" Objectives 8% 2% Consider a very basic theoretical example: An application costs $1,000,000 to go live. This includes licenses, implementation, training and more. The application costs $110,000 a year for software maintenance. The application costs $140,000 a year to operate. This includes infrastructure, help desk, business continuity management and more. Over a 15-year period, the combined maintenance and operations costs amount to $3,750,000. The lifetime total cost of ownership (TCO) is $4,750,000. The initial cost of the application is just 21% of the lifetime TCO. But no real application looks like this. Where are the enhancements? The projects that add new functionality? Assume that for the first eight years of the application's 15-year life, we spend $170,000 a year for such enhancements, decreasing to $85,000 a year for the last seven years. The 15-year cost of enhancements would be $1,955,000. The lifetime TCO taking account of these enhancements is $6,705,000. The initial cost of the application is now just 15% of the lifetime TCO. Even this simple example fails to take account of the increased cost of operations as the application becomes larger and more complex, of adding business intelligence services, of extending business continuity management requirements, and so on. Low High Application Volatility

This Year's CapEx Drives Next Year's OpEx New Project Project B Maintenance for B New Project Ops Increase for B Project A Maintenance for A Ops Increase for A Budget Base Base Here's the paradox at the heart of application investment. Applications should enhance the productivity and effectiveness of the enterprise, resulting in better business performance. Many applications do achieve these objectives. But the benefits come at a cost — the cost associated with owning, operating and sustaining the application – and, at some point in the future, potentially needing to replace the application. The problem is that all too often there is business approval for the initial investment in the application, but without adequate understanding of the ongoing OPEX effect of the CAPEX investment. The net result is that business and IT managers inhabit a fantasy world where strident demands for new capability are met through investments, while the IT delivery organization is berated for the operational costs in all the subsequent years. What often happens is that the initial investment is not matched by a willingness to continue to spend on the essential ongoing maintenance, resulting in a significant level of IT debt (the value of the deferred liability for maintenance.) As IT debt increases, enterprise risk increases but also the operational costs tend to increase as the application falls below the standard level needed for support. Hard though it may be, it is vital that any new investment in application capability should be accompanied by a clear definition of the likely lifetime cost of ownership. Current Year Next Year

Requirements: It's Not What You Do — It's the Way You Do It Functionality Reliability Usability Efficiency Maintainability Portability Analyzability Changeability Stability Testability Maintainability Applications are complex engineering artifacts. Many applications need to persist in the enterprise for a very long time. They need to be efficient in their use of computer and network resources, they need the correct degree of usability for each of the user populations that will be exposed to them. They need a certain level of reliability and the ability to recover quickly in the event of catastrophic failure. Increasingly applications need to be portable to run in many different environments — for example, on a desktop, but also on a mobile tablet or a smartphone. Above all they need to be easy to modify, since the one thing that we can be sure of is that the external world will change over the life of the application and so the application will need to be adapted to deal with that changed reality. The natural tendency is for business executives to concentrate on "Functional" requirements — the "what the application does" requirements. This would be OK if there were natural champions in the process for the other "Nonfunctional Requirements" — the "how the application does it" requirements — but, in many organizations, this is not the case. So when a business executive is trying to arrive at an holistic understanding of the competing merits of different solutions, it is a good idea to focus on the nonfunctional requirements, because these give you the best idea of what it will be like to own this application for the next 20 years. Reference: IEC 25010 (Was ISO 9126)

Applications Can and Will Change! Birth Infancy Adolescence Maturity Retirement Positive ROI From Investment in This Phase Moderate ROI Likely Negative ROI Modifying the design attributes of an application is generally an expensive and difficult task. If it is to be undertaken, then it is best done when there is a good period of time when the fruits of the changes can be experienced: generally during the first third of the expected life cycle of the application. Eventually, as an application is being prepared for decommissioning, there will be a period when no changes should be contemplated. The investment profile for an application should recognize that the initial project to create the application is the beginning of the investment, not the end. Business executives need to understand the life cycles of the applications on which they depend to know when to invest in improvements and when to accelerate replacement strategies.

Understanding Application Maintenance The Four True Functions of Maintenance The False Function of Maintenance Minor Enhancements a.k.a. "Back Door Development" Corrective Adaptive Preventive Perfective Applications need care and attention. The moment that the initial project is finished, the application starts to decay. After the initial project, the application is transferred to the care and attention of "application maintenance." This term covers the following activities: Corrective Maintenance (a.k.a. bug fixing) — dealing with deviations from the required behavior in functional requirements Adaptive Maintenance — projects dealing with upgrades to the stack, such as operating system, database or the application itself for COTS applications Preventive Maintenance — projects launched to address code that is delivering an unacceptably high error rate Perfective Maintenance — projects to address improvements in nonfunctional requirements, such as usability or performance Note that minor enhancements are really development, although many maintenance teams spend a lot of time working on them.

The Three Critical Application Attributes High Cost Risk Agility Low A business executive has a job to do. That job demands attention to detail in tactics and strategy, product and service delivery, people management, customer management and supplier relationship management (SRM) as well as achieving objectives that pay bonuses, etc. And now, on top of all this, there is a real need to understand how to manage these business applications. Clearly, only so much time can be devoted to this task, so there needs to be a set of simple measures that a busy executive can use to ascertain the status of the application portfolio to know when the applications need some special attention. The three critical measures are: Cost — What is the cost of providing the application services, and how is this cost changing over time? Risk — What are the risks in the business applications and how are these risks being mitigated? Agility — Are the applications sufficiently easy to change to meet changing business and regulatory requirements? 2013 2018 2023

Key Issues 1. What are business applications, and why do business managers need to understand them? 2. How should business executives participate in the process of investing in business applications?

Step Zero: The Application Governance Process Governance of the stakeholders, by the stakeholders, for the stakeholders Demand-Side Stakeholders Supply-Side Stakeholders Enterprise Architecture Named Owner The Applications Governance Process Application overhaul starts and ends with effective application governance structures and processes. The foundational activity for application overhaul is the establishment of application governance teams clustered around key business processes or functions, bringing together the three key stakeholder communities of demand-side stakeholders, supply-side stakeholders and enterprise architecture. These governance teams will need a significant level of engagement from senior managers from IT and the rest of the business, and will take time and patience to establish. Without effective governance, too many applications are "orphan" assets, lacking clear ownership and responsibility for value management. The key to successful governance is to put in place a process that applies "just enough" control and oversight to make effective recommendations and decisions. Assign ownership for the governance processes. Pilot application governance teams for at least two significant application clusters. Roll out an application governance process across the portfolio. Implement a standardized audit process for effectiveness and consistency of application governance teams.

Executive Application Portfolio Management Step 1: Monitor Executive Application Portfolio Management Line Item Costs for Each of Your Applications Expected Future Costs Over 10 Years Utilization — Business Units of Work Utilization Trends — Historic and Predicted Technical Risk Analysis — 10-Year Predicted Gap Analysis — Current and Predicted Market Testing — Internal and External Step 1: Monitor (Executive Application Portfolio Management) As a business executive you need to know that there is a process in place such that important data about your application assets is regularly maintained and published to you, and that you make the time to understand the changing landscape. The seven data elements will give you a comprehensive understanding of the current and predicted state of the key attributes of the applications in your portfolio. One key activity is the maintenance of the market testing data. This involves looking at the IT market in order to understand if there are new value propositions available which could potentially be of interest for a specific application domain. This is particularly important now with the huge investment in cloud services, especially software as a service (SaaS). Vendors are investing in SaaS applications that offer a different approach to solving your application problems. Many of these new application services are immature and many will fail ignominiously. However, those that succeed may well be in a position to offer you the capabilities that you require at some point in the future, and you should maintain a watch on these so as to know whether a switch could be worthwhile.

Step 2: Buy/Sell/Hold Tolerate Invest Technical Integrity Eliminate Migrate Step 2: Buy/Sell/Hold With a complex application portfolio, it is necessary to adopt a number of different application management regimes. The TIME matrix assists IT management teams and business managers in the process of deciding the regime for a specific application: Tolerate applications receive the minimum amount of maintenance and zero enhancements. They should be run at the lowest-possible cost, with close attention paid to changing patterns of usage. Invest applications are the "gold standard." They deliver high business value and they run in a technical environment that is sustainable. These applications should be maintained to the highest standards of documentation and quality assurance, and nurtured for long-term value. Migrate applications represent a risk to the business. They are necessary applications because the business value is high, but they cannot be used indefinitely, because the technical integrity is low. There should be plans in place to move this work to a more-appropriate platform. Eliminate applications should be removed from the portfolio and the work transferred elsewhere. "Elsewhere," in this context, might mean transferring the work to another application that has similar functionality, or maybe going to SaaS or BPO. Business Value

Step 3: Generate Options Option 1: Do Nothing Costs Benefits Risks Option 3: SaaS Costs Benefits Risks Example Always Option 2: Upgrade Costs Benefits Risks Option n: nnnnnnn Costs Benefits Risks Example Example Step 3: Generate Options When you know the current situation and where that would be taking you without intervention, you can decide if that is a satisfactory state of affairs. If it is not (it rarely is), then you need to plan for a better future. The starting point for this planning process is to evaluate a number of alternative options for progress. Whatever route you select, there will be advantages and disadvantages. There is no such thing as the "perfect plan" that costs nothing, delivers fantastic benefits across a broad spectrum and has no risks. Every option has a cost profile, a benefits profile and a risk profile. There is never a "right" plan — there is an optimum plan considering the alternatives. Furthermore, there is no guarantee that any specific option selected by one domain will get funding: executives are frequently competing for a finite capital budget. So it is essential that there is always a "Plan B": which option could we select if our first choice cannot be funded? The default "Plan B" is "carry on as we are": known as the "Do Nothing Scenario." It is always important to document the costs, benefits and risks inherent in the "Do Nothing Scenario" so as to make the point to the investment management team that "no decision" is in fact a decision to select the "Do Nothing Scenario" with all that that implies.

Recommendations Allocate time to regular reviews of your application portfolio Lead the culture change management to eliminate bad acquired habits and develop best practices in application value delivery Challenge your team to develop a strategic approach to your application portfolio Implement "One In, One Out" as a minimum standard when acquiring new applications

Related Gartner Research CFO Advisory: Application Portfolio Management Overview Andy Kyte (G00206748) Guide to Application Essentials, August 2011 Update Bill Swanton (G00214804) The 'Seven Deadly Sins' of Application Governance Matt Hotle (G00210776) Recommendations for Improving Project Prioritization D. Stang, D. Fitzgerald, J. Duggan (G00167598) How to Use Pace Layering to Develop a Modern Application Strategy J. Shepherd, D. Gaughan, Y. Genovese, V. Sribar (G00208964) For more information, stop by Gartner Solution Central or e-mail us at solutioncentral@gartner.com.

The Executive Guide to Application Management Andy Kyte Gartner Symposium/ITxpo 2011 October 16-20, 2011 Walt Disney World Dolphin Orlando, FL Andy Kyte Notes accompany this presentation. Please select Notes Page view. These materials can be reproduced only with written approval from Gartner. Such approvals must be requested via e-mail: vendor.relations@gartner.com. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2011 Gartner, Inc. and/or its affiliates. All rights reserved.