How to Develop a Pace-Layered Application Strategy

IT organizations' application strategies often aren't dynamic enough to handle changes in technology, the complexities of business demands and industry-specific requirements. Application leaders can use Gartner's Pace-Layered Application Strategy to differentiate the business and drive innovation.

• Application strategies are not dynamic enough to handle changes in technology, the complex nature of business demands and the unique needs of specific industries.
• IT organizations find it difficult to use application strategies to help the enterprise reach its goals.
• Applications are the most valuable asset of an IT organization. When poorly managed, they hinder the performance of day-to-day business activities, prevent the solving of business problems, and limit the ability to compete and innovate.

• Eliminate uncomfortable business conversations by helping the organization understand how technology will be used to differentiate the business and drive innovation.
• Build your understanding of Gartner's Pace-Layered Application Strategy and how it segments business applications by the activities performed, the problems they address, their rate of change and the distinctiveness of the business capabilities they embed.
• Create a layered application strategy that recognizes that the business requires several types of applications with different governance, sourcing, funding, data/process integrity, software development and deployment models.

Since its launch in December 2010, Gartner's Pace-Layered Application Strategy has continued to inform our research in many areas, and it has been widely used by clients worldwide. During this time, the concept has evolved significantly, based on feedback from our clients and contributions from several research communities within Gartner. This research adds new insights gained through client practice and provides a step-by-step process that illustrates how to use the pace-layers model to develop an application strategy.

Year after year, survey after survey, two things in IT and business seem to remain the same:

• Organizations use more and more technology to gather and make accessible more and more information.
• This technology and information fail to meet the expectations or even the basic needs of the business users.

This gap is not an anomaly resulting from chaotic times, when enterprises may behave sporadically or inconsistently. It is a significant and persistent misalignment between the needs of the business users for enterprise applications and the applications selected to meet these needs.

Business managers and users are looking for modern, easy-to-use applications that can be quickly deployed to solve specific problems. Leadership teams are looking for ways to mitigate risks or take advantage of market opportunities. Meanwhile, the IT organization is typically working toward a strategic goal of standardizing on a limited set of comprehensive application suites to minimize integration issues, maximize security and reduce IT costs. If these perspectives are not aligned, then they won't help the organization achieve its goals.

Business users often complain that, no matter what they ask for, IT tells them they have to use the functionality in the existing application portfolio, or they have to wait until the current multiyear rollout is finished before the problem can be addressed. In today's dynamic business climate, with constantly changing business models and users who are fully aware of the power of technology, this is simply unacceptable.

Organizations must establish a strategy for business applications that responds to the desire of the business to use technology to achieve sustained differentiation and drive innovative new processes, while providing a secure and cost-effective environment to support core business processes. One of the keys to developing this strategy is listening carefully to the way business people describe their vision for particular parts of the business. These often fall into three categories of ideas:

• Common Ideas – Aspects of the business in which leaders are happy to follow commonly accepted ways of doing things that change fairly slowly. Often, this is driven by regulations with which the business leaders must comply. When business leaders want to beat a competitor in this aspect of the business, it is by executing better, rather than by finding a different way to execute.
• Different Ideas – Aspects of the business in which leaders not only want to do things differently from comparable organizations, but also where executing differently provides a significant business advantage. Business leaders want to change approaches to these ideas regularly to help the organization achieve its goals.
• New Ideas – Aspects of the business in which leaders are thinking of an early stage concept, and are not at the point at which they can be specific regarding the details of how things should work. Business leaders want to see a mock-up or a proof of concept (POC), potentially going through several iterations quickly, after which they can specify how they want things to work, or decide that the new concept isn't worth pursuing.

In looking at how other industries deal with the problem of variable rates of change in complex systems, Gartner applies the term "pace layers" to the evolution of applications in an organization to mirror the concept of "shearing layers" developed by Stewart Brand in his book "How Buildings Learn" (1994). He was addressing the challenge of designing a building that would have a long and useful life, be resilient regarding change, and be able to accommodate the needs of various owners and occupants. His technique was to identify a series of layers that range from the building site, which never changes, to the "stuff," such as chairs, lamps and pictures that might move around on a daily or weekly basis. In between are layers such as the building structure, which could last 100 years; the skin or exterior surface, which might be redone every 20 years; and the services, such as plumbing, heating, ventilation and air conditioning (HVAC), or electrical wiring, which are often replaced or updated in seven to 15 years.

These architectural layers have different "paces" of change, but they must be designed to work together so that the building can function effectively. We believe this same idea of pace layers can be used to build a business application strategy that delivers a faster response and better ROI, without sacrificing integration, integrity or governance.

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're used by the organization. Gartner has defined three categories or layers to distinguish the various business capabilities (and its corresponding applications) that a company needs to manage to effectively deliver its business strategy, and help IT organizations develop more-appropriate application strategies:

• Systems of Record – usually found in business capabilities with a clear focus on standardization and/or operational efficiency; these are often subject to regulatory/compliance requirements.
• Systems of Differentiation – typically related to applications that enable unique company processes or industry-specific capabilities; these sustain the company's competitive advantage.
• Systems of Innovation – new applications that are built on an ad hoc basis to address emerging business requirements or opportunities; these involve an experimental environment for testing new ideas and identify the company's next competitive advantage.

These layers (see Figure 1) correspond to the notion of business leaders having common ideas, different ideas and new ideas. The same business capability may be classified differently in one company than another, based on its use and its relationship to that business model. We also expect to see applications move among layers as they mature, or as the business process shifts from experimental to well-established to industry-standard.

Figure 1. Gartner's Pace-Layered Application Strategy

Source: Gartner (November 2013)

We believe the key is to work with the business to understand the pace of change and the degree of uncertainty surrounding specific capabilities, then map that to the application strategy. This will enable the IT organization to apply the appropriate technical concepts, governance and life cycle management to accommodate the various rates of change.

We have advanced the initial elaborations that appeared in our foundational research about pace layers. The original focus of this research was on layering applications, which has changed to emphasize the importance of using business capabilities as a starting point. This shift in perspective has important implications: By avoiding discussions concerning applications in the first place and encouraging team members to think about business capabilities based on their nature, their pace of change and their uniqueness, we are creating the basis to improve communications between IT and the business.

To this extent, we have compiled a comprehensive set of attributes to help our clients segment business capabilities among layers. These sets of attributes are organized in four categories (see Figure 2 and Figure 3).

Figure 2. Pace-Layer Attributes (Part 1)

Source: Gartner (November 2013)

Figure 3. Pace-Layer Attributes (Part 2)

Source: Gartner (November 2013)

Companies struggle to develop an application strategy. In most cases, they do not know exactly what to do, what information to consider or what stakeholders to involve. It may be considered an annual IT planning exercise, executed by a small IT team (or worse, mostly outsourced to a consultant) and published to an internal audience. It is often overly focused on technologies, platforms and tools, and too little on the business needs. And it is often ignored by the business.

An application strategy can be seen as a step-by-step plan for developing the application portfolio, processes and organization to meet the strategic needs of the business, while minimizing the cost of building and maintaining the portfolio. As part of the broader IT strategy, the application strategy must document aspects of the enterprise context (business strategies, capabilities and processes) that affect the application strategy. It must also outline what technical and methodology approaches will be used to deliver applications that meet the business needs and provide the necessary flexibility and agility as the business strategy evolves. As with any other strategic initiative, it should not be seen as a one-time initiative, but as a continuous process, so the assumptions, principles, options and decisions that informed the application strategy evolve and remain valid as business needs change.

Figure 4 illustrates the process Gartner has developed to help IT organizations define an application strategy.

Figure 4. Key Processes in Developing an Application Strategy

Source: Gartner (November 2013)

Gartner's Pace-Layered Application Strategy is a framework that fits into this overall template by providing valuable insights about how to evaluate and segment the business capabilities embedded in the applications portfolio. It helps IT organizations understand the gaps and overlaps in the portfolio, generate options, derive a plan in terms of business capabilities to be delivered to meet changing business goals, and define appropriate approaches for governance, software development methodologies, application sourcing, staffing, funding and so on. A key best practice for implementing a pace-layered strategy (as with many major initiatives) is to start small in one key area to learn the process and then expand from there. The Pace-Layered Application Strategy framework has also strict connections with other Gartner concepts, as outlined in Table 1.

Table 1. Pace Layers' Connections to Other Gartner Concepts

Source: Gartner (November 2013)

Clients' use of the Pace-Layered Application Strategy has reinforced the importance of these connections and evolved into commonly practiced steps for applying it. These connections will become clear as we go through the steps involved in defining a pace-layered strategy:

As part of a leadership team meeting, introduce the pace-layer concept explaining what pace layers are and how they are expected to help the organization achieve its goals. Identify subject-matter experts who can participate in the pace-layering process. Conduct a meeting in which the role of the subject-matter expert for providing process information is clearly defined. After this meeting, announce the start of the pace-layering process throughout the organization, using organizational structure as a guide for the process. Build an awareness of pace layers throughout the organization, and encourage users to think about applications and processes based on their probable rate of change. Gartner has published a template to assist our clients in this endeavor.

Many organizations that are starting their pace-layering process jump right into segmentation, looking to start classifying their applications by layer. This is a useful exercise for familiarizing yourself with the concept; however, as organizations start to do the work, they often find they need more context to help them make the right decisions about which applications should be categorized in which pace layer.

The best starting point to acquire that context comes from the business capability models that many organizations have developed during the past several years. Business capabilities are the ways in which enterprises combine resources, competencies, information, processes and their environment to deliver consistent value to their customers. They are used to describe what the business does, and what it will need to do differently in response to strategic challenges and opportunities (adapted by Gartner from "Managing Information Technology Investments Using a Real-Options Approach," by P. Balasubramanian, N. Kulatilaka and J. Storck, School of Management, Boston University, 24 June 1998).

Leaders in organizations should work collaboratively to map out key business capabilities across the organization and identify those that are critical to the success of the business or mission. These efforts help inform investment decisions and the evolution of the enterprise architecture.

These models make a great starting place for developing a pace-layered strategy. Use capability models as a way to segment applications and map them in the portfolio to key business capabilities. For organizations that have not gone through the process of developing their business capability models, the "Starter Kit: Business Capability Modeling Workshop" guides this process. In this research, we share the results from a workshop with 38 clients that used business capability modeling to represent their business models. These starter kits are designed to inspire and aid organizations by understanding common capabilities by industry.

Segmenting business capabilities requires looking at each layer individually. Understanding the unique characteristics of each layer helps to define which business capabilities should be classified as systems of record, differentiation or innovation. It also helps organizations develop approaches to governing each layer differently to support a more rapid pace of change, where appropriate. To this extent, the pace-layer attributes chart (see Figure 2 and Figure 3) provides a detailed explanation of the characteristics of each layer and should be used as the primary source for this exercise.

The purpose of developing the applications inventory is to match the applications to the corresponding business capabilities they support. First, it's important to clearly define what an application is and to ensure that everyone involved in the process of creating the applications inventory has a common understanding. An application or service is a group of technology competencies that fully or partially support a business process. These competencies can be delivered through a dedicated or shared interface (e.g., when coordinated through a portal). Collectively, the application or competencies implement business logic and rules that transform user or system input into data or activity output. In some cases, applications inform decisions; in others, they automate and optimize business functions, processes, tasks and activities.

An application inventory is a list of all applications in use. It reflects the projects in-flight, and the proposals for new applications that are being considered by the organization. In Step 6, we refer to a toolkit that outlines starter categories for an application inventory as part of a more complete application fitness and value review. Capture this information as early as possible. Populating the inventory is an iterative process, and there will be categories that will need to be customized to your specific organization. Many organizations already have some of this information as part of a Microsoft Excel spreadsheet, a Microsoft SharePoint list or a specialized asset management tool.

Perform this exercise one business capability at a time. For example, list the applications that are used to engage consumers or customers by capturing and analyzing consumer/customer insights. Keep in mind that several platforms used by your business may be composed of application suites; therefore, they may appear on your list more than once. Work first with the applications that touch the greatest number of people/customers or have the most significant potential impact on the business and build out other business capabilities as your organization has defined them (e.g., creating products, delivering products and services, and managing the business).

Most organizations think about their business applications in categories. Originally, those categories tended to align with departments, such as accounts payable, payroll or purchasing. As the packaged software industry developed, the vendors began to create new categories for collections of applications that supported related activities or even industry processes. Today, we tend to use labels such as ERP, CRM, core banking and customer service to describe an application category; however, those are really large sets of applications that support many different business capabilities.

To create a pace-layered strategy, we break these large categories into smaller groups, because the individual applications often have very different characteristics, because they are associated with different business capabilities. Although this activity may seem like a daunting exercise, especially with large application suites, it is important to keep in mind that the objective is conceptual accuracy, rather than architectural precision. The level of granularity need only be what is necessary to analyze and categorize the applications for your organization.

For example, one company might decide that their accounts receivable module can be considered a single application that belongs to the systems-of-record layer, because it perfectly aligns with the common business practices embedded in the application. Another company running the same ERP suite might decide that the billing application should be separated from the rest of the accounts receivable module because it has a highly automated electronic invoicing process that differentiates the capability of managing the business from other organizations in the same industry.

In the case of packaged applications and suites, such as ERP or CRM, the vendors often divided the product into functional modules that represent a mapping to business needs and how they planned to market the offering (e.g., an ERP system that has a human capital management [HCM] module and a finance module). These "solution maps" can be a useful place to start when deconstructing the larger suites, because they generally relate to functional areas or business capabilities. At the same time, it's important to consider the detailed applications within a module, because some applications may have differentiating capabilities for specific industries or sectors.

Homegrown or custom-developed applications can be more difficult to deconstruct. Even if the documentation is limited, the navigation menus and an experienced user can generally help depict the functionalities and reveal the key characteristics.

Compiling the application inventory, breaking it down into an appropriate level of granularity and then assigning the applications to their proper level needs to be a group effort. Ideally, this will be done by a team of application specialists from IT, as well as key users who are familiar with the application set and the objectives of the business. Once the list is created, and the team agrees on the characteristics of the layers, the actual sorting should go quickly. The assignment of most of the applications will be obvious, with only a small number requiring a debate. Even a team with hundreds of different applications should be able to assign them to layers in a few days.

After creating the application inventory, it is important to associate each application with the business capability it supports. In cases where capabilities are defined at lower levels, the applications and business capabilities they support may be the same. However, some applications may be part of a larger, extended business capability. For example, if an organization is taking a new product to market, then this business capability includes product design, which encompasses capabilities associated with engineering, manufacturing, marketing, sales and finance across the organization.

The concepts of differentiation and innovation apply to business capabilities, not software technologies. It may be perfectly possible to write a highly innovative application for general ledger postings, but that would not make financial accounting an innovative capability for most businesses. The same is true for systems of differentiation, where we are referring to business capabilities that differentiate the company – not unusual or unique software engineering.

Knowing the business capabilities with which the applications are associated can be helpful in understanding characteristics such as strategic focus, life span or rate of change, which will determine their proper level. In many cases, companies will also find that there are applications in their portfolios that aren't supporting any business capability, either because they've been superseded, or because the processes embedded in this business capability have changed or have been eliminated.

Once the application inventory is organized in a single location, a review of the fitness and value associated with the applications can provide additional information, which is equally important to the process of categorizing them into pace layers. Through this assessment, we connect the pace-layers exercise to APM by defining the bases upon which application management decisions (e.g., rationalization and modernization) will be made for each layer. To help our clients in the assessment of the fitness and value of the applications inventory, we developed the "Toolkit: Application Fitness and Value Review," which brings together concepts that are essentially interdependent (pace layers and APM). It generates important insights for making key business decisions, helping IT organizations to:

• Create a business capabilities framework that can be used to inform strategic decisions involving the evolution of the applications portfolio.
• Segment business capabilities across layers (i.e., the systems of record, differentiation and innovation).
• Build an applications inventory with basic information needed for portfolio analysis.
• Evaluate applications using objective/measurable attributes based on four dimensions: application value and fit to mission or process, operation risk, technical risk, and cost.
• Apply Gartner's TIME analysis to define whether to tolerate (T), invest (I), migrate (M) or eliminate (E) applications.
• Automatically generate graphics plotting the applications in the Pace-Layered Application Strategy model and in the TIME matrix.

For each layer of the portfolio to be managed effectively, a strong governance structure must unite all stakeholders. The challenge for IT management teams is to develop a culture of governance that encourages consistent and persistent participation. This means that governance cannot be about IT "telling" the business stakeholders what needs to be funded – there must be a true partnership that includes respect.

Another key aspect of governance is the determination of which processes are truly sustainable business differentiators. Many parts of the organization may feel their activities are different and require unique applications. If the IT department and the business cannot agree, there should be a mechanism for senior management to arbitrate differentiation or uniqueness.

Developing governance structures takes time and patience. Typically, IT management teams will have a small number of governance activities that are working reasonably well and a larger number that aren't. Management teams should take lessons from the successful governance structures, and begin to replicate best practices across other assets. One effective strategy is to place managers from the business in the position of chairing pace-layered governance activities. This removes the impression that IT is trying to use governance to achieve its own agenda.

A number of governance considerations must be taken into account when developing a strategy for each layer and the dynamics among layers. Recognize that the approach may differ dramatically from one layer to the other, but that the organization must develop guidelines for each layer across these dimensions:

• Budgeting – What is the source of funding for applications in the layer? The answer will vary by organization, but systems of record will typically be centrally funded by the IT organization, while the other levels may be funded directly out of business-line budgets.
• Maintenance and Support – How will maintenance and support policies differ across each layer? If the innovative application will only be in place for a short period of time, should you pay the same type of maintenance fees as for the core ERP application? In cases where the business functions are purchased directly from a software as a service (SaaS) provider, how will support be managed?
• Selection Criteria – Getting agreement on the selection criteria at each level is important to ensure that there is some consistency in the organization as to what buyers should expect from each type of application. Providing clear guidance from IT can help business buyers ask the right questions and understand some of the key technical differences that affect adoption and usability.
• Stakeholders/Ownership – Given that many of the applications in the differentiation and innovation layers may be purchased, implemented and managed directly by the business, there needs to be a clear understanding across the business and IT on ownership, and who the key stakeholders are.
• Architectural Standards – Developing process and data integrity requirements for each level is key to ensuring that applications can continue to share information, and that applications will fit into the architecture best practices that have been defined.
• Pricing and Deployment Models – Pricing and deployment options will differ at each level, depending on funding sources, skills availability, vendor offerings and business opportunity.

Beyond APM, pace layering will require a high degree of maturity (approximately Level 3 in Gartner's ITScore for Application Organizations) in many other application management disciplines, including project portfolio management, management of architecture, software processes and vendor management. Gartner's ITScore for Application Organizations Maturity Model includes three key concepts important to a successful pace-layered application strategy:

• Differentiated processes that are appropriate for the size and scope of the endeavor
• Business and application organizations collaborating on innovations, ideation and experimentation
• Business engagement that holds the applications organization and business jointly accountable for success

These attributes only appear at the highest levels of maturity, so many organizations will need to focus on improving their application organization and processes.

A major construct of the pace-layering approach is the creation of a logical grouping of applications based on the type of business capabilities they help automate, the pace of change for those applications and their typical life spans. This is not meant to imply that these applications are deployed physically in separate groups. In many cases, there will be strong interoperability requirements among applications across each layer. For example, an application that connects to social networks to capture sentiment about your company's products to identify any potential defects or service issues (a system of innovation) would need to connect to the core customer support or bug-tracking application to ensure that your support organization can quickly identify and mitigate potential issues before your community begins to negatively affect product revenue.

To help manage the interoperability of processes and data across the layers, organizations will need to adopt what we call "connective tissues" (see Note 1). These are the enabling tools that tie applications together and provide a means for organizations to extend the value of their applications, or create new capabilities on top of the existing portfolio. We believe organizations will need several common elements of connective tissues:

• Master Data Management (MDM) – to ensure that key elements of master data are synchronized across the layers
• Process and Data Integration – to facilitate the flow of data among 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 (e.g., service-oriented architecture, agile development practices) for composing applications, and for 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

These enabling technologies will form the common underpinnings of the application architecture. All new application investments should be assessed in light of how they provide or interoperate with the connective tissue in your organization.

IT teams often engage in the Pace-Layered Application Strategy as a solitary effort for a single point in time. The problem with doing this is that it doesn't help the organization manage applications with the intent of meeting regularly changing business needs. To effectively use the Pace-Layered Application Strategy, the performance of the model must be measured. Metrics should include those that measure a change in velocity (the speed with which applications are meeting the changing needs of the organization) and investment by layer.

Include measures that specifically target the unique performance of the different layers. For example, in systems of record, measure the ability of the strategy to reduce complexity and improve efficiency. In systems of differentiation, measure the ability of the model to increase agility and meet enhance business value. For systems of innovation, measure the ability of the strategy to encourage innovation.

Hold the IT team accountable for the results of the Pace-Layered Application Strategy as part of an overall improvement plan; however, don't measure numbers just for the sake of measurement. It is possible that there are current metrics being measured by the organization that can be used in a performance evaluation of the Pace-Layered Application Strategy.

Business leaders are increasingly frustrated with the results of technical "one size fits all" approaches from IT in environments that are often dominated by enterprise suites or old/legacy applications. Technological knowledge is no longer the monopoly of IT organizations. To meet urgent business demands and enable critical new business capabilities, business leaders frequently bypass IT.

Gartner's Pace-Layered Application Strategy provides a framework that enables IT to be responsive to differentiated business needs. It is also a powerful translation device to address the persistent gap between IT and the business, because it provides a common, business-oriented language to define and communicate the application strategy. To truly engage, this conversation must happen in business terms and be in the context of the organization's overall strategy. If IT leaders insist on spouting technology and acronyms, they will be ignored by the business.

CIOs and IT leaders must take action to ensure that IT is not sidelined when developing and deploying a pace-layered strategy. This should provide solutions to a wide range of business needs, thereby raising the relevance of the IT organization as an enabler of business strategy.