On Your Mark: Understanding the Different Paces

To achieve differing system objectives, you need differing behaviors, and for that, you need to follow differing methods. In order to successfully evolve your systems, you must plan for and apply change to each according to its function, needs, and required timeline. By following these suggested time frames, you can make up for slow change in record systems – constantly and quickly enhancing your top layer without comprising the integrity of your bottom layer.

Speed of change: The higher the system is in the pace layered hierarchy, the faster you can adapt it. For example, systems on the innovation layer can – and should – evolve quite rapidly while ERP systems on the bottom, record layer need more time and can’t be modified as frequently.

Planning horizon: Along with the appropriate speeds of change, architecture layers require varying lead times before implementing those changes. While adaptations on the record layer must be planned at least 5 years ahead, differentiation systems need only a couple of years planning, and innovation systems can be modified in a matter of only a few months.

Governance and process: All changes to record systems must be strictly controlled and tested to monitor their impact on critical administrative procedures. On the other hand, innovation systems should be much more flexible to allow rapid change, enabling your company to tap into rapid, ad-hoc changes as the need arises. In the middle, differentiation layer systems can be changed more freely than the record layer but are more streamlined than those on the innovation layer.

API design: As APIs’ objectives differ from one architecture layer to the other, so should their design. Typically, systems of record have very generic APIs, like those holding employee information, where in the innovation layer, the APIs are much more detailed and optimized for specific functionality. Consider the complete spectrum of integration when you develop your API landscape. Make sure that APIs are not only stable and secure but also can be easily monitored to identify top performers and bottlenecks.

One great example of pace layered architecture’s effectiveness can be seen in financial institutions and their business development. Many banks and insurance providers are very innovative on the customer side of business, with applications that offer convenient online payments, user-friendly interfaces, and streamlined cross-application integration for a better user experience. But hiding under those fancy mobile apps lies dinosaur legacy technology.

The only way to avoid being dragged down by a monolith monster is through steady governance on the slow-moving, record layer and rapid innovative on the top, application layer. Regardless of the industry, for any organization working with a lot of legacy, pace layered architecture is the only way to remain competitive.