Change is inevitable. Today’s computing environments are constantly in flux from internal and external forces that put demands on the systems and necessitate changes to maintain its value stream. Technology currency is a constant struggle that organizations must navigate. Organizations on the lower end of the capability maturity spectrum find themselves reacting to market or technology demands in a reactive mode which becomes very disruptive to delivering business capabilities to customers and consumers of an application or service.
As organizational maturity increases, the area of technology currency takes on a more proactive role. Teams are tasked with trying to determine when to implement changes to maintain or hopefully increase business benefit while simultaneously minimize technology debt. The challenge quickly becomes understanding when change is needed and at what frequency should the system be reviewed and updated accordingly.
To help with the challenge of establishing frequency schedules for technology, the Gartner Group developed what they described as the Pace-Layered Application Strategy. It is a methodology for categorizing, selecting, managing, and governing changes to applications that will allow them to support business changes, system differentiation, and incorporate innovation.
Initially created in 2012, Gartner developed the pace-layered architecture to provide a recommended framework of when an application or service should be changed. Through their analysis they determined that rate of change is not the same for all types of systems.
Gartner broke the categorization of applications and services into three distinct types:
- Systems of Innovation
- Systems of Differentiation
- Systems of Record
Each of these types of systems or modules have specific characteristics for evolving to remain current or increase value.
Systems of Innovation
Sitting at the top are applications described as innovative. These can be cutting edge technologies that are new to the organization or present an opportunity in a new product area or using new business processes. These are typically customer facing and represent applications or modules where changes are needed in an abbreviated time period as the organization gains more experience or must change quickly based on customer feedback.
Systems of Differentiation
These systems which are represented by the middle tier describe systems or services that are part of a larger suite of applications or built as part of a Software as a Service (SaaS) effort. The applications normally have unique process and capabilities that facilitate supporting the customers. Most mainstream business applications fit within this category. Business processes are known, and changes typically represent evolutionary rather than revolutionary changes to increase or maintain business capabilities.
Systems of Record
At the bottom of the categorization are applications that represent the foundation on which the computing environment is based. Applications in this category manage critical master data and process core transactions. While not a requirement, most applications in this space represent back-end programs. Systems in this space are the backbone of the organization. Changes to this space typically happen slower as the technology is well defined and resilient. Because so many of the application portfolio rely on the availability and consistency of the apps in the System of Record category any changes to the architecture of these represent enterprise changes with long lead times between changes. Assigning applications to one of these categories will provide an appropriate timeframe for when you should expect to make changes to the architecture.
These categories not only work for applications but can be further compartmentalized to modules within a specific application. For example, an application itself may fit in the Systems of Differentiation category based on its place in the value stream but looking within the application itself it could include modules which are foundational and a System of Record for the application itself. Likewise, there could be modules which represent new processing within the system or using new technology which may be innovative meaning those modules should be reviewed more often than other parts of the application.
The granularity of the pace layering can therefore be representative of not just applications but the components or modules of a specific application. Using this categorization will help to develop schedules on architectural review down to specific code sections that should be reviewed and revisited appropriately.
The thinking behind pace layering is not new but with today’s environment where teams are tasked with application modernization it provides yet another data point to determine when it will be appropriate to devote time and resources for updating the architecture of classes of applications.
Given the demands on IT resources to keep an application portfolio current, having methodologies such as pace layering will add yet another signpost on the journey to developing the right review schedule to make necessary changes appropriate to how an application or module is being used.
0 Comments