Applications 2020: Creating Your Survival Strategy Tutorial: Getting Started With Application Strategy Applications 2020: Creating Your Survival Strategy Ian Finley Application Architecture, Development & Integration Summit May 18-19, 2015 Park Plaza Westminster Bridge London, UK Andy Kyte

You Don’t Need an Application Strategy An application strategy is a process of continuous iteration driven to improve business value by engaging all stakeholders in measuring the current state of your application portfolio and developing options for improvement.

You Need a Survival Strategy Your Application Strategy for 2015-2020 should be a crisis management plan to rescue the enterprise from the shantytown of accidental architecture inherited from 20th century IT culture by creating an organization that will deliver services fit for purpose for a 21st century enterprise.

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 shantytown, 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, while 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.

This image of Australia Square is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. Attribution: Elekhh at en.wikipedia 4

Plan the Portfolio – Not Just Projects 5

Guide Investment with a Pace Layered Strategy New Idea “I don’t know exactly what I want. I need to experiment.” Pace Layered Application Strategy™ Systems of Innovation Systems of Differentiation Systems of Record Better Idea “I know what I want, but it needs to be different from my competitors.” Common Idea “I know what I want and it doesn’t have to be unique.” © 2011 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. In the past, many companies have had a single strategy for selecting, deploying and managing applications. They may have had methodologies for classifying applications by value or technological viability, but they did not recognize that applications are fundamentally different based on how they are used by the organization. Gartner has created three application categories to distinguish these application types and help organizations develop more appropriate strategies for each one. The same application may be classified differently in one company than in another based on its usage and relationship to that business model. We also expect to see applications move between "layers" as they mature or the business process shifts from experimental to understood.

Fishing License System An Example: Fishbook Fishbook Fishing License System Permits System System of Innovation System of Differentiation System of Record

Adjust to New Technologies Tactical Guideline: Focus outward, not inward in adopting cloud computing by segmenting applications into high control versus high productivity solutions. Time to Cloud Systems of Innovation Systems of Differentiation Systems of Record First Last Key Issue: What will cloud projects look like over the next five years? Adoption of cloud computing happens in stages. The types of applications and workloads to be moved can indicate which stage of adoption is most appropriate. One method of evaluating which applications should move first is to use a bull's-eye diagram that segments the applications by characteristics. Those with the most strict control requirements go in the center and will take a relatively long time to become commonplace in the public cloud. These applications are high control applications and have relatively sensitive data or deep integration with other systems. They also could require complex transactions and low latency as part of the reasons why the cloud model might be too early in its maturity to warrant a wholesale movement of these solutions. Those applications with moderate control issues can move in a more timely fashion but still may require some strong consideration as to whether or not the advantages of cloud computing are worth the risks of moving. This type of application will include those focused on corporate processes or work tracking systems. In addition, these may be front office solutions which are customer support as well as help desk and approval tracking. These can move to the cloud with discretion starting now over the next three years. Finally, those applications that are more commoditized or less differentiated can move to the cloud immediately. These include productivity and collaborative applications as well as potentially self-contained activities such as development and test. They are for the most part ready for cloud computing right now and we are seeing good traction in their adoption in the public cloud. Tactical Guideline: Focus outward, not inward. Take advantage of what the cloud does well. Don't just focus on what it does not support effectively today.

Match the Investment to the Need Systems of Innovation Planned Life 3 to 12 months Approximately $100,000 Refactor Systems of Differentiation Planned Life 2 to 5 years $1 million to $10 million Refactor Systems of Record Planned Life 10 or more years $10 million to $100 million or more

Different Ideas Need Different People, Process and Technology Attributes Systems of Record Systems of Differentiation Systems of Innovation Business Processes Integrated, commoditized, stable Highly configurable and customizable Experimental, ambiguous, dynamic, ad hoc Pace of Change Slow, infrequent, incremental (every 6 to 12 months) Moderate, more frequent (every 3 to 6 months) Rapid, very frequent, ad hoc (weekly, sometimes daily) Lifetime 10+ years 2 to 5 years 3 to 12 months Strategic Focus Standardization; operational efficiency Agility/flexibility; competitive differentiation Disruptive thinking; alternative business models Stakeholders/ Ownership High executive engagement; low end-user engagement High LOB executive engagement; moderate end-user engagement Moderate executive engagement; high end-user engagement Funding Capex and opex; annual budget IT budget or departmental Departmental opex; innovation fund

Evaluate the Total Experience of Ownership – Not Just Project Cost Value Value/Business Benefit Project Expense Project Capital Depreciation Upgrade Ops Cost App Maint. … Time Cost Many organizations have become proficient at the basic cost analysis of a solution throughout its life cycle, including the following: Starting with the upfront business case Estimating and managing project capital and expenses Managing ongoing operational and maintenance costs Predicting and timing upgrade expenses Unfortunately, from a value analysis perspective, most organizations rarely move beyond the basic business case created at the beginning of a project. This often results in solutions being kept around well past their useful lives, assuming that the "useful life" of a solution is even defined. This is analogous to investors holding on to investments too long. In the IT world, it is fairly common for solutions to be held around well past negative returns to the point where solutions only get retired when they blow up or drive people crazy. At the very least, the original business case should be dusted off and reviewed a few months after a project goes live. The keys to solving this challenge are to: Master basic enterprise solution financials, such as the relationship between this year's capital and future years' operations and maintenance expenses. Redefine project success to include function retirement, reuse and business value. Agree on the complete set of value, cost and risk attributes worth tracking for an enterprise solution.

The Budget Crisis ... B Project A Maint. Maint. Maint. Base Project C 2010 ... Base Maint. 1991 Maint. Budget 1990 Maint.

Rationalize the Portfolio with TIME Key Issue: What is the process to identify and select critical application strategies? Technical Quality/Condition Business Value Tolerate Invest Eliminate Migrate High Low Poor Great Key Issue: Application Portfolio Management Best Practices Application development organizations can choose from a dizzying array of technological possibilities, e-business demands and old business expectations. Application portfolio management provides a disciplined approach to managing systems that meet old business expectations, but are old technologies with limited possibilities that do not meet e-business demands. Tolerate those systems that still satisfy a significant portion of the business function and are on platforms that deliver high quality of service (if the applications need it). Integrate those involved in business processes that cross stovepipes or where data volume precludes conversion. Migrate those systems that are "burning platforms" or that use declining or irreplaceable skills. Eliminate those that no longer provide significant business value, which requires some agreement on the parameters of business value. The challenge for organizations is to determine the right mix for their companies, in their industries and for their customers.

Generate Options – Not Road Maps 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

Application Portfolio Management (TIME) Meets Systems of Innovation Key Issue: What is the process to identify and select critical application strategies? High Application “Value” or Fit to the Mission, Mandate or Process Need Low Problematic Excellent Tolerate Migrate Invest Eliminate Differentiation (Architecture & Staffing) Cost and Risk Success Failure Innovation

Application “Value” or Fit to the Mission, Mandate or Process Need Application Portfolio Management (TIME) Meets Systems of Differentiation Key Issue: What is the process to identify and select critical application strategies? High Application “Value” or Fit to the Mission, Mandate or Process Need Low Problematic Excellent Tolerate Migrate Invest Eliminate Differentiation Lost Over Time Record Differentiation (Architecture & Staffing) Cost and Risk Too Brittle Differentiation

Application Portfolio Management (TIME) Meets Systems of Record Key Issue: What is the process to identify and select critical application strategies? High Application “Value” or Fit to the Mission, Mandate or Process Need Low Problematic Excellent Tolerate Migrate Invest Eliminate Stabilize & Reduce Spend Record Record (Architecture & Staffing) Cost and Risk Replace System

Link Retirement to Acquisition New Mature Prime Adolescent Young The Theoretical Balanced Portfolio Senile Zombie Mature New Prime Young Adolescent The Typical Portfolio, 2015

Reduce Technical Debt With Every Project Project success today On time On budget On specification On value (rare) 2014 2015 2016 2017 Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Others Retire Sys 1 Retire Sys 2 Retire Sys 3 Success tomorrow Today's metrics + Percentage of functions retired Percentage of functions reused Key Issue: What types of solutions are available to me in 2009? Project success fixates on aspects that are easily measured, such as whether a project is on time and on budget. Ironically, this ignores whether the expected value was delivered. An old adage in home renovation projects says that if people really gets what they want, then they are willing to put up with inconveniences in timing and budgets. Leaders must evolve their expectations of project success to include retirement, reuse and value. Unless projects are measured from a retirement and reuse perspective, there is little chance that either will happen. The key is identifying what must be retired and what is worth reusing. Otherwise, some of the very things that should be eliminated become further embedded in the ecosystem. From a practical standpoint, if targeted retirement and reuse aren't specifically called out in a Gantt chart, it is unlikely they will occur. Action Items: Redefine project success to include targeted retirement and reuse of software. Include the ongoing tracking of value from software throughout the life span of a system.

7 Steps to Managing the Crisis Plan the portfolio – not just projects Guide Investments with a Pace Layered Strategy Evaluate total ownership experience – not just project cost Rationalize the portfolio with TIME Generate options – not roadmaps Link retirement to acquisition Reduce technical debt with every project 20

You Need a Survival Strategy Your Application Strategy for 2015-2020 should be a crisis management plan to rescue the enterprise from the shantytown of accidental architecture inherited from 20th century IT culture by creating an organization that will deliver services fit for purpose for a 21st century enterprise.

Recommended Gartner Research Pace-Layered Application Strategy and IT Organizational Design: How to Structure the Application Team for Success Mary Mesaglio and Matthew Hotle (G00238542) Ten Questions to Test the Quality of Your Application Strategy Bill Swanton (G00222580) Use the Pace-Layered Application Strategy to Understand Your Applications Portfolio Darryl Carlton and others (G00232225) Managing Application Strategy Through Multiple Hype Cycles Andy Kyte (G00231347)