Business today demands the ability to change systems at an ever-increasing speed. However, for many companies, including their systems of record has created a mismatch in development and operations practices between the traditionally dynamic systems of engagement and the traditionally slower systems of record. It takes multi-speed IT for true agility.
The problem many enterprises face isn’t in the ability of the systems of record to move as fast; they can change as fast as any other systems. The problem lies with the tools and processes used for the systems of record. The traditional view — to decrease risk, you must reduce change — has been shown to not necessarily be true. Manual or large changes can cause increased risk, but that risk can actually be reduced through a completely automated deployment process of delivering smaller changes that have gone through automated testing together.
The concept of multi-speed IT is not that some systems are slower and some are inherently faster — it’s that changes need to be made at the speed business requires. If a business change is required in the back end, it should be changeable as fast as any front-end change. The reality is, many back-end systems or systems of record provide a set of APIs that are used by the systems of engagement. These APIs can be more stable than the mobile application you’re providing to the user. Imagine a calendaring service — when was the last time the calendar changed? When did anyone add or remove days from a month? Likewise, this one is very stable. The only changes have to do with new interfaces required, such as providing a new REST-based interface. Other APIs will be much more dynamic based on business needs.
So, how can a large, storied enterprise bring agility to both new and old systems, mainframe and mobile, while reducing risk and fear of bringing down legacy or mission-critical applications?
Understand the applications and systems you have
This requires an ability to scan your code and systems to understand the dependencies and the interrelated nature of the systems. This application understanding allows you to do better testing and understand the deployment requirements.
Test across systems
Test everything together, where new and old applications cross paths, and ensure thorough testing earlier and more often.
Release what you tested together
If you are testing earlier to ensure applications across systems are working together properly, it only makes sense to release those applications together.
Create a singular deployment process for the release
Your deployment process should reflect whatever applications or components need to be released in the proper order to ensure functionality across systems.
Of course, collaboration and a culture shift are key to enabling these actions across teams and systems.
A recent IBM webinar discussed how organizations can incorporate continuous testing and deployment into releases across systems and how multi-speed IT can be a stepping stone for enterprise agility. In addition, I released a new book on DevOps to help organizations understand the challenges and what can be done to help move forward in this transformation.
The first area to address in this transformation is application understanding. To learn more, read the latest blog by Larry Hart, “Advanced GPS for your DevOps journey.”
This article was originally published on DevOps.com.