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 frameworkThis 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 IdeasOne SizeFits AllAlternativeBusinessModelsCommon IdeasNew IdeasBusiness LeaderApps/ITLeaderCommon 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 IdeasCompetitive ThreatsSystems of InnovationBetter IdeasSystems of DifferentiationUnique ProcessesSystems of RecordGreaterEfficiencyCommon IdeasIn 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 RecordDifferentiationInnovationProcess CharacteristicsStructured, repeatableConfigurable, autonomousDynamic, ad hocData/InformationHighly structured, well managed, mainly internal, auditedInternal and external, some unstructured; more dynamicStructured and unstructured data; heavy reliance on external dataContentStatic/StableBothDynamicChange Control /GovernanceStrict Control and TestingMore StreamlinedAd HocBusiness EngagementFormal Governance ProcessPart of the TeamDoing the WorkTo 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 Horizon7+ years1-2 years2-3 months
9 Systems of Record: Core "Records" and Common Processes Accounts PayableGeneral LedgerBudgetTax, TreasuryEmployee RecordsBenefitsPayrollVendorsRequisition to OrderInventoryHuman ResourcesProcurementFinancialStabilized and Lower TCO: Invest in Differentiation and InnovationProcesses: Common processes — incremental improvementInformation: Core records — very high quality/audit, reportingSystems: Core ERP/SCM/CRM suites or legacy systemsChange Drivers: Long-term shifts, regulatory change, trickle downThis 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 dataOften subject to regulatory control, outside audit or significant legal liabilityCentralized "corporate standard" systemsOften available as a packaged suite (or at least packages) that should be deployed as "plain" as possibleBenefit from tight integration15- to 20-year useful life — funded as a capital assetMost likely to be deployed on-premises, but cloud options are emerging
10 Unstable Foundations Lead to Failure Droid AppFacebook PresenceiPhone AppAnalysis ServiceSentimentRecommendationsEngineProduct Review ServiceSystems of InnovationOpen Innovation Submission BoxR&D and Product Development Systems and ProcessesCustomer ServiceProcesses and SystemsSystems of DifferentiationConfiguratorProductOrderCustomerSystem of RecordUnstableSupplier
11 Systems of Differentiation: Unique Processes and Information Key Question: What are the real business differentiators for your enterprise?Human ResourcesProcesses & Info.Recruit to RetireBenefits / PayrollSelf - ServiceFinanceProcesses & Info.Transactional (AP/AR)General LedgerBudgetingProcurementProcesses & Info.Req to CheckeCommerce (SCM)InventoryProcesses: Unique/differentiating processes, rigorous/detailed, medium pace of changeInformation: Analytics and forecasting — often combining system of record data and other dataSystems: Best-of-breed, SaaS, sometimes modules of a suiteChange Drivers: Successful innovations, commoditization, competitive pressuresThis 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 sourcesHeavy focus on collaboration inside and outside the enterpriseMay be selected, managed and funded as a line-of-business budget itemHave shorter life spans and are subject to more frequent redesignTend 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 packagesWell-suited to cloud deployment
12 Systems of Innovation: New Processes and Information WebSocialMobileMultichannelProcesses: Emerging processes, experiments/proofs of concept, often fairly manual/basic processes, process "lite"Information: Increasingly external, advanced analytics/models, scenario planningSystems: Experimentation "sandbox":Portals, content management & collaboration"Lite" Application Development — mashups, Web, social, mobileQR codesChange Drivers: New ideas, innovationSystems 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 responseFunded and developed by business users or third parties, with some IT helpOften designed to support a multienterprise business activityVery short life cycles and light governance modelsHighly collaborative, extensive use of unstructured dataTypically NOT application packages, but a combination of custom development, file sharing (spreadsheets, data files, graphics, audio, video), Web/portals and collaborationLikely 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 FinanceAssess TCO for the option: calculations and assumptions should be transparentSource of cost data and assumptions should be documentedCOA should be developed to show and continually account for cost componentsAgilityAgility characteristics for deployment options need to be compared to the requiremenst for the software systemMay be difficult to ascertain unless you have been measuring over timeThe ability to adapt the application easily over time must be a crucial design constraintControlSoftware needs to be managed at many levels (data, security, change (code) control), requires management timeMore dynamic and involved governance to deliver appropriate controlTechnologyNeed 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 architectureIdentify the impact of a specific deployment decision on current and planned enterprise architectures.
15 Interaction Between the Layers Requires "Connective Tissue" System of InnovationCommon Elements of Connective TissueMaster Data ManagementProcess and Data IntegrationBusiness Service RepositoryIntegrated Composition TechnologyCommon Security ArchitectureIntegrated Monitoring and ManagementExternal ConnectivitySystem of DifferentiationVS.System of RecordTo 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 layersProcess and data integration — to facilitate the flow of data between applicationsBusiness 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 technologiesCommon security architecture — a common architecture for managing identities, access to systems and security of critical dataIntegrated 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 RecordSystem of DifferentiationSystem of InnovationProcess ChangeStrict Change ControlExperimentationArchitectureTraditionalAlternate PlatformsInvestment PoolDepartmentalCapital ProcessFundingAgile PracticesIncremental & IterativeWaterfallDevelopment PracticesDoing the WorkPart of the teamFormal ProcessBusiness EngagementMany 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 Horizon7+ years1-2 years2-3 months
17 Establish Realistic Process and Data Integrity Requirements Ambiguous,and HighlyFlexibleModest ExpectationsProcess IntegrityData IntegrityFacebook CampaignProspect Web VisitSystem of InnovationScenarioModelsSocialDatabaseBudgeting,Planning,ForecastingDirectMarketingDatabaseSales InteractionQuotationOrder EntrySystem of DifferentiationShippingInvoicingCash ReceiptSystem of RecordAudit andComplianceReporting,ReconciliationWell- Understood, Tightly ControlledAs 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 CharacteristicRecordImprove execution10 to 20 yearsUnderstood and stableHigh75% technical25% businessIntegrated packaged application suiteInfrequentOn-premises cloud emergingCapital assetDifferentiationBetter design3 to 5 yearsUnderstood and dynamicModerate50% technical50% businessBest of breedMore frequent; configurability is keyOn-premises or SaaSCapital or expenseInnovationStrategic FocusNew idea6 months to 3 yearsAmbiguous and dynamicLimitedCustom, orchestrated, open innovationVery frequent; "throwaway" customizationAny, but typically on-premisesExpense25% technical75% businessLife SpanPace of ChangeProcess ViabilityData IntegritySupport RequirementsSourcingTechnical DeploymentBeyond 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 CLMMDM of Supplier DataSystems of InnovationSupply Base ManagementSupplier E-invoicingSpend AnalysisProcurement Network — South AmericaE-CatalogContingent Workforce ManagementStrategic SourcingProcurement Network — Western EuropeSystems of DifferentiationProcurement Network — North AmericaE-Procurement — ERP #1AP Invoice AutomationXE-Procurement — ERP #1Systems of RecordPurchasing — ERP #3Purchasing — ERP #2Purchasing — ERP #X
20 Example: Pace Layered Applications Large Enterprise in 2016 Global P2P NetworkMDM of Purchased Part DataService ProcurementSystems of InnovationSupply Base ManagementRegional Procurement Network(s)CLMSystems of DifferentiationSpend AnalysisStrategic SourcingContingent Workforce ManagementMDM of Supplier DataE-Procurement With E-CatalogPurchasing — ERP #1Systems of RecordPurchasing — ERP #3Purchasing — 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 supportSelection criteria ● Data managementArchitectural standards ● Deployment modelEstablish 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 TurnoverOrganizational AutonomyFunding ProcessGovernance (ownership, change control)Treating Integration As a Separate IssueExcessive Customization...Trying to replicate old systems and processesTrying to add unique capabilities needed by agencyDefine 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 FirstFigure out how to keep it for life of projectMake sure political appointees and civil service have been convinced it is importantAgree on standard processesSegregate COTS and unique capabilitiesBuild 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