0. 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

1. 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.

2. You Need a Survival Strategy
Your Application Strategy for
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.

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.wikipedia 4

5. Plan the Portfolio – Not Just Projects5

6. 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.

7. Fishing License System
An Example: Fishbook
Fishbook
Fishing License System
Permits System
System of Innovation
System of Differentiation
System 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 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.

9. 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

10. 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

11. 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.

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

13. 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.

14. 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

15. 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

16. 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

17. 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

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

19. Reduce Technical Debt With Every Project
Project success today
On time
On budget
On specification
On value (rare)
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.

20. 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

21. You Need a Survival Strategy
Your Application Strategy for
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.

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 )