0. Gartner’s Pace-Layered Application Strategy
Accelerating Innovation by Adopting a Pace-Layered Application Strategy
Gartner’s Pace-Layered Application Strategy
Michael Guay
APAC Symposium/ITxpo 2011
November 14-17, 2011
Gold Coast Convention & Exhibition Centre Queensland, Australia
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 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.

1. Gartner delivers the technology-related insight necessary for our clients to make the right decisions every day.

2. Pace Layering: A New Beginning
Business strategy and market conditions change faster than IT systems can adapt.
In 2010, Gartner introduced the pace-layered application strategy framework
This presentation will review the concept and provide guidance on adoption, governance and change management.

3. Pace Layering: Key Issues
What are the key aspects of a pace-layered application strategy?
How should application leaders implement a pace-layered application strategy without creating chaos?
How can you use a pace-layered strategy to help your organization drive sustainable differentiation and increased innovation?

4. Why Is a New Application Strategy Needed?
The Conversation Between Business and IT Leaders Is Not Working!
Better Ideas
One Size
Fits All
Alternative
Business
Models
Common Ideas
New Ideas
Business Leader
Apps/IT
Leader
Common ideas: Generally, best practices are shared across many types of companies in many industries. Finance and payroll are common examples. You may differentiate by finding ways to execute better in these areas. The standard answer for many organizations in this area is, "Use packaged applications." As business leaders ask what the technology solution is for common ideas, the standard answer from the application leader is, "Use our core system."
The core system is usually a package application suite, but it may be a portfolio of best-of-breed solutions that have been integrated by IT or a legacy homegrown system.
Business leaders will often come to IT (application leaders) with an idea of how to differentiate the organization from competitors. These ideas may require process/information changes or new processes and information. The net result is that the business leader wants to do this differently from others. But the answer from IT (application leader) is often the same: "Use the core system."
Business leaders will occasionally come to IT with a totally new idea. They are not exactly sure how to execute but know that technology could be a huge differentiator and that the idea could have a big impact on business outcomes. Unfortunately, IT (application leaders) often responds with the same answer as for common ideas and better ideas: "Use the core system."
As a result, IT has built a "jail of its own making," where the answer to all business problems is, "Use the core system." But business problems often have different requirements for enabling better outcomes. It's time for application leaders to adjust.
Improved Processes

5. The Pace-Layered Application Concept
Most organizations have a heterogeneous portfolio of business applications.
The applications range from mainframe to iPad, data center to cloud, and critical to casual.
The business processes they support may change every few years or every few days.
No single strategy or governance model can be appropriate for all applications.
The problem is only getting worse…

6. A Pace-Layered View of Applications
New Ideas
Competitive Threats
Systems of Innovation
Better Ideas
Systems of Differentiation
Unique Processes
Systems of Record
Greater
Efficiency
Common Ideas
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. A Public Sector Pace Layered View of Systems
“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
“I know what I want, but my needs are unique and there are no packages.”
© 2011 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates.
“I know what I want and it doesn’t have to be unique.”
*Also referred to as “Uniqueness”
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.

8. Characteristics of Layers
Record
Differentiation
Innovation
Process Characteristics
Structured, repeatable
Configurable, autonomous
Dynamic, ad hoc
Data/Information
Highly structured, well managed, mainly internal, audited
Internal and external, some unstructured; more dynamic
Structured and unstructured data; heavy reliance on external data
Content
Static/Stable
Both
Dynamic
Change Control /
Governance
Strict Control and Testing
More Streamlined
Ad Hoc
Business Engagement
Formal Governance Process
Part of the Team
Doing the Work
To help with the classification of applications across the layers, we have defined a set of characteristics to help provide an additional level of depth. They are:
Process characteristics — Look at the business processes being automated by the application and ask some key questions: How quickly do they need to change? How much control or oversight needs to be wrapped around those processes? Who should be responsible for adapting the applications when processes need to change? What other applications would be affected if we adjusted these business processes?
Data/Information — The type of data used by the application is also a defining characteristic of the different layers. Key data- related questions to ask include: Does this application fall under financial reporting or other regulatory requirements? Is the data highly structured or unstructured? Internal or external? Are the data types well defined or more amorphous?
Content — Beyond the data in the application, the content and presentation of the application will be different by layer: Is the user interface static or dynamic? Does the application take advantage of external services to provide dynamic content?
Analytics — The way data is analyzed in the application is also a defining characteristic: Is the focus of analysis on historical reporting or forward-looking trends/forecasts? Are the reports well defined and consistent or do the application consumers need the ability to do predictive modeling or scenario analysis?
Security — The security of the application is also an important consideration and differences across the layers aren't distinguished by high or low security. High security might be a requirement for all layers. Key questions include: How centrally controlled is the user population for the application? What is the sensitivity level for the data in the application? Does the application fall under regulatory span of control? Does it involve participants from multiple organizations?
Collaboration — The level of collaboration capability in the application is also a distinguishing characteristic: Is the application used for completing individual tasks or managing workflows that require a lot of user interaction? Does the application span organizational boundaries?
Planning Horizon
7+ years
1-2 years
2-3 months

9. Systems of Record: Core "Records" and Common Processes
Accounts Payable
General Ledger
Budget
Tax, Treasury
Employee Records
Benefits
Payroll
Vendors
Requisition to Order
Inventory
Human Resources
Procurement
Financial
Stabilized and Lower TCO: Invest in Differentiation and Innovation
Processes: Common processes — incremental improvement
Information: Core records — very high quality/audit, reporting
Systems: Core ERP/SCM/CRM suites or legacy systems
Change Drivers: Long-term shifts, regulatory change, trickle down
This is the most established application area, The large suite vendors have tried to lump every imaginable application into the suite and convince buyers to treat them all as systems of record. The reality is that, although this fits certain transactional processes and back-office activities, it is not a good model for many other areas that may be industry- or company-specific, or would benefit from a much more flexible and "loosely coupled" approach.
In many cases, this is the area of applications that is most stable, and companies should be working to shift IT investment away from this layer.
System of record attributes:
Support fundamental, core transactional processes: the desire is to do these better than competitors, NOT to do them differently from competitors — this is about "run the business"
Manage critical master data
Often subject to regulatory control, outside audit or significant legal liability
Centralized "corporate standard" systems
Often available as a packaged suite (or at least packages) that should be deployed as "plain" as possible
Benefit from tight integration
15- to 20-year useful life — funded as a capital asset
Most likely to be deployed on-premises, but cloud options are emerging

10. Unstable Foundations Lead to Failure
Droid App
Facebook Presence
iPhone App
Analysis Service
Sentiment
Recommendations
Engine
Product Review Service
Systems of Innovation
Open Innovation Submission Box
R&D and Product Development Systems and Processes
Customer Service
Processes and Systems
Systems of Differentiation
Configurator
Product
Order
Customer
System of Record
Unstable
Supplier

11. Systems of Differentiation: Unique Processes and Information
Key Question: What are the real business differentiators for your enterprise?
Human Resources
Processes & Info.
Recruit to Retire
Benefits / Payroll
Self - Service
Finance
Processes & Info.
Transactional (AP/AR)
General Ledger
Budgeting
Procurement
Processes & Info.
Req to Check
eCommerce (SCM)
Inventory
Processes: Unique/differentiating processes, rigorous/detailed, medium pace of change
Information: Analytics and forecasting — often combining system of record data and other data
Systems: Best-of-breed, SaaS, sometimes modules of a suite
Change Drivers: Successful innovations, commoditization, competitive pressures
This application layer may be transactional, management or analytical in nature. In industries like banking or insurance, these may be applications that are company-specific, because they are part of the product or service that the organization delivers. In many cases, these will be outward-facing applications that support the interaction with customers, constituents, suppliers or regulators. We are seeing many of these applications shift to cloud-based deployments because of the funding model, deployment speed and desire for more rapid enhancement cycles. This is the category where many of the best-of-breed packaged applications belong. They need to coexist with the big packaged suites, share data and extend processes, but they also tend to have more of a departmental focus and specialized functionality. In some cases, they may be considered a more tactical purchase with a different investment perspective and life cycle expectation.
Systems of differentiation attributes:
Support processes (and related data) that you may want to do differently from others to "differentiate" — this is generally about "grow the business"
Leverage data from systems of record, but also capture, maintain and use data from other sources
Heavy focus on collaboration inside and outside the enterprise
May be selected, managed and funded as a line-of-business budget item
Have shorter life spans and are subject to more frequent redesign
Tend to be configured — the key is not to cross the line between configuration and customization. In some cases, these are custom-developed applications that need to have the rigor and disciplined life cycle expected from application packages
Well-suited to cloud deployment

12. Systems of Innovation: New Processes and Information
Web
Social
Mobile
Multichannel
Processes: Emerging processes, experiments/proofs of concept, often fairly manual/basic processes, process "lite"
Information: Increasingly external, advanced analytics/models, scenario planning
Systems: Experimentation "sandbox":
Portals, content management & collaboration
"Lite" Application Development — mashups, Web, social, mobile
QR codes
Change Drivers: New ideas, innovation
Systems of innovation recognize that technology has become more pervasive and accessible, and that the nature of business interactions has changed. End users and departments want and expect to be able to use technology on an ad hoc basis to address sudden business needs and opportunities. They are accustomed to using a variety of Internet-based tools and mobile devices to interact with co-workers, customers, prospects, partners and the collective. They need some enablement from IT, some access to corporate data, and some guidelines to avoid doing harm. However, in most cases they are happy to do it themselves. Constraining the business to use only the systems of record is impractical and often leads to "skunkworks" projects that are invisible and dangerous. These are often the source of critical business innovations, and, by virtue of being user- or department- driven, they can be much more responsive than the typical IT application project. Attributes of systems of innovation:
Created on an ad hoc basis to support an opportunity, knowing that many of the new ideas will not succeed — this is generally about "transform the business"
Tactical projects intended to support rapid innovation and market response
Funded and developed by business users or third parties, with some IT help
Often designed to support a multienterprise business activity
Very short life cycles and light governance models
Highly collaborative, extensive use of unstructured data
Typically NOT application packages, but a combination of custom development, file sharing (spreadsheets, data files, graphics, audio, video), Web/portals and collaboration
Likely leveraging cloud capabilities and new devices (e.g., iPhone, Droid, iPad and others)
Like systems of differentiation, systems of innovation need to appropriately extract/put back data from both systems of record and differentiation

13. Pace Layering: Key Issues
What are the key aspects of a pace-layered application strategy?
How should application leaders implement a pace-layered application strategy without creating chaos?
What should public sector organizations be aware of when implementing a pace-layered application strategy?

14. Use FACT to Determine Optimal Deployment Choices
Finance
Assess TCO for the option: calculations and assumptions should be transparent
Source of cost data and assumptions should be documented
COA should be developed to show and continually account for cost components
Agility
Agility characteristics for deployment options need to be compared to the requiremenst for the software system
May be difficult to ascertain unless you have been measuring over time
The ability to adapt the application easily over time must be a crucial design constraint
Control
Software needs to be managed at many levels (data, security, change (code) control), requires management time
More dynamic and involved governance to deliver appropriate control
Technology
Need to assess the operational load impact of a specific deployment option (Ex: SaaS solution may create significant additional loading on external network connectivity, on premise may place more burden on existing servers)
Determine “connective tissue” products and architecture
Identify the impact of a specific deployment decision on current and planned enterprise architectures.

15. Interaction Between the Layers Requires "Connective Tissue"
System of Innovation
Common Elements of Connective Tissue
Master Data Management
Process and Data Integration
Business Service Repository
Integrated Composition Technology
Common Security Architecture
Integrated Monitoring and Management
External Connectivity
System of Differentiation
VS.
System of Record
To help manage the interoperability of processes and data across the layers, organizations will need to adopt "connective tissue" or the enabling technologies that help tie applications together. We believe that there are a number of common elements of connective tissue that organizations will need:
Master data management — to help ensure that key elements of master data are synchronized across the layers
Process and data integration — to facilitate the flow of data between applications
Business service repository — a container to store and manage the life cycle of services (semantics, information flow and rules of utilization)
Integrated composition technology — a consistent mechanism for composing applications, taking advantage of new visualization and social technologies
Common security architecture — a common architecture for managing identities, access to systems and security of critical data
Integrated monitoring and management — the ability to monitor the health of applications, track and respond to events and manage the deployment of applications

16. Governance Differences Between the Layers
System of Record
System of Differentiation
System of Innovation
Process Change
Strict Change Control
Experimentation
Architecture
Traditional
Alternate Platforms
Investment Pool
Departmental
Capital Process
Funding
Agile Practices
Incremental & Iterative
Waterfall
Development Practices
Doing the Work
Part of the team
Formal Process
Business Engagement
Many different design/selection goals are in place when considering applications. Certain applications are focused on delivering maximum efficiency or compliance with policy or regulation. Other applications are designed for flexibility and speed. When looking at how the layers map to these competing forces, the systems of record are targeted at efficiency and compliance, while the systems of innovation are more focused on flexibility and speed. Based on your business strategy, your application portfolio will map across this graphic differently. Given that most packaged applications are designed to consistently implement best- practice processes, a higher number of packaged applications will fit into the system of record category. Most companies will find that many of their custom-developed offerings will fit into the other two categories — where a packaged offering didn't support the ability to differentiate or innovate. A key take-away is that your application layering strategy should be driven by your business requirements and how each application contributes value to your organization, and not by a vendor-defined packaging scheme. Business efficiency and agility have been enemies. The perception of process automation success has been tightly tied to efficiency: maximum production with minimum inputs. This has resulted in applications that embrace functional detail and methodologies aimed at capturing requirements and translating them into code, or composites, with a best point-in- time fit. This may maximize output, but output at a point in time does not equal shareholder value. Sustained efficiency over time is needed. Agility — the ability to shed inertia when change is required — is put at risk by the new architectures of services and composites. Moving process definitions out of code, and even out of applications, makes for more fluid, malleable software. Visualizing and orchestrating business processes are more comprehendible to business than connecting services. Blurring design, development, execution and change into a cycle of continuous improvement expands agility. Establishing a business process platform based on architecture, services, tools and methodology creates a possibility of achieving efficiency without the loss of agility. This becomes a requirement when business conditions demand more rapid business process innovation.
Action Item: Users should carefully evaluate new applications and development environments for their ability to sustain process innovation in continuous cycles.
Planning Horizon
7+ years
1-2 years
2-3 months

17. Establish Realistic Process and Data Integrity Requirements
Ambiguous,
and Highly
Flexible
Modest Expectations
Process Integrity
Data Integrity
Facebook Campaign
Prospect Web Visit
System of Innovation
Scenario
Models
Social
Database
Budgeting,
Planning,
Forecasting
Direct
Marketing
Database
Sales Interaction
Quotation
Order Entry
System of Differentiation
Shipping
Invoicing
Cash Receipt
System of Record
Audit and
Compliance
Reporting,
Reconciliation
Well- Understood, Tightly Controlled
As we described on a previous slide, the process and data integrity requirements will be different at each layer. Given the highly structured and often regulated nature of systems of record, the process and data integrity requirements are very high and well-understood. As you move up the layers, organizations need to embrace the fact that processes will be less controlled and more flexible and the data quality may not need to be as high. The key take-away is for organizations to define the appropriate requirements for them at each level. Another consideration is that many differentiated or innovation systems will rely on data from the system of record, so those systems need to adapt accordingly.
High Integrity

18. Recommendations for Layers
Characteristic
Record
Improve execution
10 to 20 years
Understood and stable
High
75% technical
25% business
Integrated packaged application suite
Infrequent
On-premises cloud emerging
Capital asset
Differentiation
Better design
3 to 5 years
Understood and dynamic
Moderate
50% technical
50% business
Best of breed
More frequent; configurability is key
On-premises or SaaS
Capital or expense
Innovation
Strategic Focus
New idea
6 months to 3 years
Ambiguous and dynamic
Limited
Custom, orchestrated, open innovation
Very frequent; "throwaway" customization
Any, but typically on-premises
Expense
25% technical
75% business
Life Span
Pace of Change
Process Viability
Data Integrity
Support Requirements
Sourcing
Technical Deployment
Beyond the characteristics of the layers defined on a previous slide, we provide some recommendations to further help the classification process. These should be used as a guideline for how to define the different layers, what the support requirements should be, the deployment model, and the investment strategy. These recommendations should evolve into a set of architectural guidelines that will help create a governance structure for ongoing investment and management of the application portfolio.
Investment

19. Example: Pace Layered Applications Large Enterprise in 2012
CLM
MDM of Supplier Data
Systems of Innovation
Supply Base Management
Supplier E-invoicing
Spend Analysis
Procurement Network — South America
E-Catalog
Contingent Workforce Management
Strategic Sourcing
Procurement Network — Western Europe
Systems of Differentiation
Procurement Network — North America
E-Procurement — ERP #1
AP Invoice Automation X
E-Procurement — ERP #1
Systems of Record
Purchasing — ERP #3
Purchasing — ERP #2
Purchasing — ERP #X

20. Example: Pace Layered Applications Large Enterprise in 2016
Global P2P Network
MDM of Purchased Part Data
Service Procurement
Systems of Innovation
Supply Base Management
Regional Procurement Network(s)
CLM
Systems of Differentiation
Spend Analysis
Strategic Sourcing
Contingent Workforce Management
MDM of Supplier Data
E-Procurement With E-Catalog
Purchasing — ERP #1
Systems of Record
Purchasing — ERP #3
Purchasing — Shared Service

21. How to Build a Pace-Layered Strategy
Create a panel of business users and IT application experts.
Decompose existing suites into individual applications.
Associate each application with the business process it supports.
Analyze the characteristics of each application and process.
Use the pace-layered application characteristics as a starting point to assign the application to a layer.
Adapt your application governance model to fit the objectives and needs of the three layers.
Establish a set of connective technologies to facilitate the interoperability of the application within and between layers.
Build awareness of pace layers throughout the organization.
Encourage users to think about applications and processes based on their probable rate of change.

22. Pace Layering: Key Issues
What are the key aspects of a pace-layered application strategy?
How should application leaders implement a pace-layered application strategy without creating chaos?
How can you use a pace-layered strategy to help your organization drive sustainable differentiation and increased innovation?

23. How Can Pace Layers Enable Differentiation?
Provide a process to consider individual business activities rather than application categories.
Create a framework to support the coexistence of integrated suites and “best-of-class” apps.
Establish a governance process that allows departments to specify, justify and even purchase their own applications.
Encourage a dialogue between business and IT leaders about which activities are (or should be) truly differentiating.
Introduce the idea that differentiating applications change at a faster pace.

24. How Can Pace Layers Encourage Innovation?
Create a category of "Innovation Applications" with a budget and governance process.
Establish a development environment with tools and resources to make innovative apps. faster and easier to develop.
Use the pace layers model to shift some funding from systems of record apps. to Innovation apps.
Develop "connective tissue" that allows innovation apps. to access master data and call Web services without compromising data integrity or security.

25. Pace Layer Recommendations
Move away from a monolithic application strategy, and categorize current and planned applications by layer.
Develop a differentiated strategy for each layer:
Budgeting ● Maintenance and support
Selection criteria ● Data management
Architectural standards ● Deployment model
Establish standards for connective tissue across the layers: governance, integration and integrity.
Conduct regular pace layer reviews with the business to consider recategorizing applications.
Overhaul — rationalize, standardize, simplify, modernize — applications from the bottom layer up.
Drive "new idea"-style innovations from the top layer down by providing a system of innovation.

26. Pace Layer Recommendations
Placeholder for text (substitute your own text; delete when not used)
Use service-oriented architecture (SOA) concepts as the connective tissue between layers.
Deploy systems of record at the lowest total cost of ownership (TCO) to the business.
Do not intrusively customize purchased applications.
Deploy built or composite applications for systems of differentiation.
Subheading Placeholder (substitute your own text; for example, Key Issue) in 12-point Arial Bold.
Notes go here in 12-point Times.
The text alignment should be flush left (not justified).
SPAs, Action Items and other important information in the Notes section should be italicized.
The Notes section of the first slide should summarize the whats and whys — what the presentation is about, what the Aha concept is and why someone should bother attending the presentation. If the presentation is really a tutorial, state so here. This should be the only reason not to have the Aha slide.

27. Top Public Sector Risk Issues
Organization and Project Leadership Turnover
Organizational Autonomy
Funding Process
Governance (ownership, change control)
Treating Integration As a Separate Issue
Excessive Customization...
Trying to replicate old systems and processes
Trying to add unique capabilities needed by agency
Define the integration points – where and what kind of integration will be needed (e.g. simple extract and ‘put back’)
Navy put in Oracle. They got stuck when the Supply Area was putting in ISS. The solutions had overlapping responsibilities. No one thought about that in advance.
Don’t treat integration as a separate issue. You WILL have it. Not all integration points will be cooperative.

28. Public Sector Specific Recommendations
Secure Political Support for Transformation First
Figure out how to keep it for life of project
Make sure political appointees and civil service have been convinced it is important
Agree on standard processes
Segregate COTS and unique capabilities
Build benefits realization process tied to incentives

29. Related Gartner Research
Application Deployment Options Through the Pace Layer Lens Matthew Hotle, Andy Kyte (G )
Gartner's Application Pace Layer Model: Governance and Change Management Bill Swanton (G )
Connecting Technology for a Pace-Layered Application Strategy Dennis Gaughan (G )
What Can Gartner's Pace Layered Application Strategy Do for an Enterprise's Business? Alex Drobik Jim Shepherd (G )
ERP Strategy: Why You Need One, and Key Considerations for Defining One Nigel Rayner, Jeff Woods (G )
For more information, stop by Gartner Solution Central or us at