Accelerating Innovation by Adopting a Pace-Layered Application Strategy

Segmenting Applications Into Pace Layers

In looking at how other industries deal with the problem of variable rates of change in complex systems, we came across the concept of pace layers as 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 to change, and be able to accommodate the needs of various owners and occupants. His technique was to identify a series of layers, ranging 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, like 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 very different paces of change, but they must be designed to work together for the building to 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 a better ROI, without sacrificing integration, integrity and/or governance.

Many companies have a single strategy for selecting, deploying and managing applications. They may have had methodologies for classifying applications by value or technological viability, but they do not recognize that applications are fundamentally different based on how they are used by the organization. Similar to the concepts in building architecture, Gartner has defined three application categories, or "layers," to distinguish application types and help organizations develop more-appropriate strategies for each:

• Systems of record

• Systems of differentiation

• Systems of innovation

These layers correspond to the notion of business leaders having common ideas, different ideas and new ideas (see Figure 1). The same application may be classified differently in one company than in another, based on its usage and relationship to the 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.

One of the keys to using pace layering is to take a more granular approach to thinking about applications. We are accustomed to using common, three-letter acronym application categories (such as ERP, CRM, human capital management [HCM] and supply chain management [SCM]); however, when classifying applications in pace layers, they must be broken down into individual processes or functions. For example, let's look at financial accounting, order entry and collaborative demand planning, which are often part of a single ERP package, but are separate application modules that belong in three different layers in the Pace-Layered Application Strategy:

• Financial accounting is highly standardized, and is nearly always a system of record.

• Order entry often has a number of unique characteristics based on the company's products, channels and pricing, and would frequently be considered a system of differentiation.

• Collaborative demand planning is a relatively new application that is constantly evolving as companies look for new ways to use the Internet, smart devices and social networks to interact with customers and sense or shape demand. It is a perfect example of a system of innovation.

This approach should also be used to classify individually packaged or custom-developed applications. It is important to determine whether they support a common requirement, a unique business methodology or an innovative new business process. This allows the organization to apply the appropriate governance, funding and data models, based on the characteristics of each application.

To assist in segmenting applications into pace layers, we have published and

In the following research, we applied the Pace-Layered Application Strategy to common organizational domains and business processes:

We have also applied the Pace-Layered Application Strategy to common areas of interest for our clients in and

Connective Technologies: Ensuring Process and Data Integrity Between Layers

As organizations look to pace layers to help their application portfolios evolve from the rigid nature of current monolithic application strategy, it will be important to establish process and data integrity requirements within and between each layer (see ). Many organizations have used the single integrated suite as a means to ensure process and data integrity. Unfortunately, this is often the root cause of many organizations' inability to adapt their IT architecture to meet changing business requirements.

The pace-layered approach acknowledges that process and data integrity requirements will be different within each layer, and defines a set of architectural standards at each level to accelerate an organization's ability to adapt (see ). Given the highly structured and often regulated nature of systems of record, the process and data integrity requirements are very high and well-understood. In moving up the layers, organizations need to embrace the fact that processes will be less controlled and more flexible, and that the nature of data quality will change. Another consideration is that many differentiated or innovation systems will rely on data from the system of record, or that new applications may require the integration of processes and/or data across the three layers.

Similar to the concept of pace layering in architecture, the layers must also be designed to work together to support the inevitable integration of processes and data in business. To help manage the interoperability and integration of processes and data across the layers, organizations will need to use connective technologies (see ). Connective technologies are enabling tools that help tie applications together, and provide a means for organizations to extend the value of their current applications, or to create new capabilities on top of the existing portfolio. Organizations will need several common elements of connective technology (see Figure 2). These enabling technologies will form the common underpinnings of the application architecture; as such, all new application investments should be assessed in light of how they provide or interoperate with the connective tissue in your organization:

• 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 among applications.

• Service-oriented architecture (SOA) governance — a container to store and manage the life cycle of services, such as semantics, information flow and rules of utilization (see and ).

• Business process management suites (BPMSs)— supporting rapid changes to the business process, BPMSs are an ideal technology for developing systems of differentiation and innovation, or building flexible systems of record (see ).

• Composition technology — a consistent mechanism for composing applications, and for taking advantage of new visualization and social technologies.

• Identity and access management architecture — a common architecture for managing identities, access to systems and security of critical data.

• Business intelligence (BI)/analytics — to support a new range of information-driven systems of differentiation and innovation, and to ensure the effective use of system-of-record data (see ).

Developing a Governance Strategy for a Pace-Layered Application Strategy

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 — rather, there must be a true partnership that includes respect.

Organizations are usually quite familiar with the governance needs of systems of record. Current application management processes are often designed to manage these core operational and administrative systems. A good governance model will ensure that the application organization keeps systems of record applications running smoothly and supporting day-to-day business operations. Because systems of record are regulated or foundational to running an organization, changes will be carefully controlled to ensure that processes perform well within legal and compliance boundaries. Stakeholders are often actively involved in the governance of these applications. Governance of systems of differentiation and systems of innovation may differ depending on the business processes they support. These differences may show up in change management processes, architecture and platforms, funding models, development methodologies, business participation, and the length of the planning horizon for the application (see ).

Another key aspect of governance is the determination of which processes are truly sustainable business differentiators. Many parts of the organization may feel that their activity is "different" and requires a unique application. If the IT department and the business cannot agree, there should be a mechanism for senior management to be the final arbiter of differentiation and uniqueness.

Developing such 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 are not working very well or at all. Management teams should take lessons from the successful governance structures, and begin to replicate the 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 somehow 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 another, 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 IT, 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 the organization pay the same type of maintenance fees as for the core ERP application? In cases where the business functions purchase 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 may impact 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 regarding 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 they 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.

Additional governance research that can be applied to the Pace-Layered Application Strategy includes:

Beyond application portfolio management, pace layering will require a high degree of maturity in many other application management disciplines, including project portfolio management, management of architecture, software processes and vendor management. Gartner's ITScore for application maturity model includes two key concepts that are important to a successful pace-layering strategy:

• Differentiated processes that are appropriate for the size and scope of the endeavor

• Business and application organizations collaborating on innovations, ideation and experimentation

These attributes only appear at the highest levels of maturity, so many organizations will need to focus on upgrading their application organization and processes. contains an assessment tool and recommendations on how to advance to higher levels.