Presentation on theme: "You Don’t Need an Application Strategy"— Presentation transcript:
0 Applications 2020: Creating Your Survival Strategy Tutorial: Getting Started With Application StrategyApplications 2020: Creating Your Survival StrategyIan FinleyApplication Architecture, Development & Integration SummitMay 18-19, 2015Park Plaza Westminster BridgeLondon, UKAndy Kyte
1 You Don’t Need an Application Strategy An application strategy is a processof continuous iterationdriven to improve business valueby engaging all stakeholdersin measuring the current stateof your application portfolioand developing options for improvement.
2 You Need a Survival Strategy Your Application Strategy forshould be a crisis management planto rescue the enterprise fromthe shantytown of accidental architectureinherited from 20th century IT cultureby creating an organizationthat will deliver services fit for purposefor a 21st century enterprise.
3 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.
4 This image of Australia Square is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. Attribution: Elekhh at en.wikipedia4
7 Fishing License System An Example: FishbookFishbookFishing License SystemPermits SystemSystem of InnovationSystem of DifferentiationSystem of Record
8 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 CloudSystems of InnovationSystems of DifferentiationSystems of RecordFirstLastKey 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.
9 Match the Investment to the Need Systems of InnovationPlanned Life 3 to 12 monthsApproximately $100,000RefactorSystems of DifferentiationPlanned Life 2 to 5 years$1 million to$10 millionRefactorSystems of RecordPlanned Life 10 or more years$10 million to $100 million or more
10 Different Ideas Need Different People, Process and Technology AttributesSystems of RecordSystems of DifferentiationSystems of InnovationBusiness ProcessesIntegrated, commoditized, stableHighly configurable and customizableExperimental, ambiguous, dynamic, ad hocPace of ChangeSlow, infrequent, incremental (every 6 to 12 months)Moderate, more frequent (every 3 to 6 months)Rapid, very frequent, ad hoc (weekly, sometimes daily)Lifetime10+ years2 to 5 years3 to 12 monthsStrategic FocusStandardization;operational efficiencyAgility/flexibility;competitive differentiationDisruptive thinking;alternative business modelsStakeholders/OwnershipHigh executive engagement;low end-user engagementHigh LOB executive engagement;moderate end-user engagementModerate executive engagement;high end-user engagementFundingCapex and opex;annual budgetIT budget or departmentalDepartmental opex;innovation fund
11 Evaluate the Total Experience of Ownership – Not Just Project Cost ValueValue/Business BenefitProjectExpenseProject Capital DepreciationUpgradeOps CostApp Maint.…TimeCostMany organizations have become proficient at the basic cost analysis of a solution throughout its life cycle, including the following:Starting with the upfront business caseEstimating and managing project capital and expensesManaging ongoing operational and maintenance costsPredicting and timing upgrade expensesUnfortunately, 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.
12 The Budget Crisis ... B Project A Maint. Maint. Maint. Base Project C 2010...BaseMaint.1991Maint.Budget1990Maint.
13 Rationalize the Portfolio with TIME Key Issue: What is the process to identify and select critical application strategies?Technical Quality/ConditionBusiness ValueTolerateInvestEliminateMigrateHighLowPoorGreatKey Issue: Application Portfolio Management Best PracticesApplication 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.
14 Generate Options – Not Road Maps Option 1: Do NothingCostsBenefitsRisksOption 3: SaaSCostsBenefitsRisksExampleAlwaysOption 2: UpgradeCostsBenefitsRisksOption n: nnnnnnnCostsBenefitsRisksExampleExample
15 Application Portfolio Management (TIME) Meets Systems of Innovation Key Issue: What is the process to identify and select critical application strategies?HighApplication “Value” or Fit to the Mission, Mandate or Process NeedLowProblematicExcellentTolerateMigrateInvestEliminateDifferentiation(Architecture & Staffing)Cost and RiskSuccessFailureInnovation
16 Application “Value” or Fit to the Mission, Mandate or Process Need Application Portfolio Management (TIME) Meets Systems of DifferentiationKey Issue: What is the process to identify and select critical application strategies?HighApplication “Value” or Fit to the Mission, Mandate or Process NeedLowProblematicExcellentTolerateMigrateInvestEliminateDifferentiationLost Over TimeRecordDifferentiation(Architecture & Staffing)Cost and RiskToo BrittleDifferentiation
17 Application Portfolio Management (TIME) Meets Systems of Record Key Issue: What is the process to identify and select critical application strategies?HighApplication “Value” or Fit to the Mission, Mandate or Process NeedLowProblematicExcellentTolerateMigrateInvestEliminateStabilize &Reduce SpendRecordRecord(Architecture & Staffing)Cost and RiskReplaceSystem
18 Link Retirement to Acquisition NewMaturePrimeAdolescentYoungThe Theoretical Balanced PortfolioSenileZombieMatureNewPrimeYoungAdolescentThe Typical Portfolio, 2015
19 Reduce Technical Debt With Every Project Project success todayOn timeOn budgetOn specificationOn value (rare)Phase 1Phase 2Phase 3Phase 4Phase 5OthersRetire Sys 1Retire Sys 2Retire Sys 3Success tomorrowToday's metrics +Percentage of functions retiredPercentage of functions reusedKey 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.
20 7 Steps to Managing the Crisis Plan the portfolio – not just projectsGuide Investments with a Pace Layered StrategyEvaluate total ownership experience – not just project costRationalize the portfolio with TIMEGenerate options – not roadmapsLink retirement to acquisitionReduce technical debt with every project20
21 You Need a Survival Strategy Your Application Strategy forshould be a crisis management planto rescue the enterprise fromthe shantytown of accidental architectureinherited from 20th century IT cultureby creating an organizationthat will deliver services fit for purposefor a 21st century enterprise.
22 Recommended Gartner Research Pace-Layered Application Strategy and IT Organizational Design: How to Structure the Application Team for Success Mary Mesaglio and Matthew Hotle (G )Ten Questions to Test the Quality of Your Application Strategy Bill Swanton (G )Use the Pace-Layered Application Strategy to Understand Your Applications Portfolio Darryl Carlton and others (G )Managing Application Strategy Through Multiple Hype Cycles Andy Kyte (G )