|
There is a gap developing between the business users of enterprise applications and the IT professionals charged with providing these applications. The business leaders are looking for modern, easy-to-use applications that can be quickly deployed to solve a specific problem or respond to a market opportunity. Meanwhile, the IT organization is typically working toward a strategic goal of standardizing on a limited set of comprehensive application suites in order to minimize integration issues, maximize security and reduce IT costs. These competing goals often lead to strategic misalignment.
Business users often complain that, no matter what they ask for, IT tells them either that they have to use the functionality in the existing application portfolio or that 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 an unacceptable answer.
Organizations must establish a new strategy for business applications that responds to the desire of the business to use technology to establish sustainable 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 such a strategy is listening carefully to the way businesspeople describe their visions for particular parts of the business. Very often, these will fall into three categories of ideas:
To build an application portfolio that supports these categories of business ideas and the inevitability of business changes, Gartner developed a methodology called a Pace-Layered Application Strategy. In 2011, we developed a body of research to guide organizations in developing their own Pace-Layered Application Strategies. The following research provides starting points for understanding foundational concepts:
In addition to the foundational research, there are three major categories of Pace-Layered Application Strategy research: segmenting applications into pace layers, connective technologies and governance.
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:
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.

Source: Gartner (January 2012)
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:
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 "Systems of Record: You Can't Innovate on an Unstable Foundation" and "Use Systems of Innovation to Respond Rapidly to Urgent Business Needs."
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 "Using Pace Layers to Boost the Business Value From Your SAP ERP Investment" and "Use Pace Layering as a Best Practice for Real-Time, Operational Intelligence Architecture."
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 "Introducing Process Integrity: Critical to Business Applications, SOA Compositions and Processes" ). 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 "Balance Process Agility and Process Integrity Choices Along the Application Continuum" ). 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 "Connecting Technology for a Pace-Layered Application Strategy" ). 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:

Source: Gartner (January 2012)
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 "Gartner's Pace-Layered Application Strategy: Governance and Change Management" ).
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:
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:
These attributes only appear at the highest levels of maturity, so many organizations will need to focus on upgrading their application organization and processes. "ITScore Overview for Application Organizations" contains an assessment tool and recommendations on how to advance to higher levels.
This is part of two in-depth collections of research. See the collections:
|
| Resource Id: 1890915 |