Today’s business demands the ability to change systems at an ever-increasing speed, but for many companies, including their systems of record have created a mismatch in development and operations practices between the traditionally dynamic systems of engagement and the traditionally slower systems of record.
The problem isn’t in the ability of the systems of record to move as fast; they can change as fast as any other system. The problem lies with the tools and processes used for the systems of record. The traditional view—that to decrease risk you must reduce change—has been shown to be not necessarily true. Manual change or large changes can cause increased risk, but through a completely automated deployment process that includes configuration changes and by delivering smaller changes that have gone through automated testing together, risk actually is reduced.
The concept of multi-speed IT is not that some systems are slower and some are inherently faster, it is that the 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 are providing to the end user. Imagine a calendaring service—when was the last time the calendar changed? When did we add or remove days from a month? So 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 need.
So how does a large, storied enterprise bring agility to systems both old and new, mainframe to mobile, while reducing risk and fear of bringing down legacy or mission-critical applications?
- Test across systems—Test everything together, where applications old and new cross paths, 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 that 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, to enable these actions across teams and systems, collaboration and a shift in culture are key.
Recently we hosted a webinar on how organizations can incorporate continuous testing and deployment into releases across systems and how multi-speed IT can be used as a stepping stone for enterprise agility.
About the Author / Rosalind Radcliffe
Rosalind is a Distinguished Engineer within the IBM Rational organization. She is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture. This includes System z and Power system. In addition she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities. She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM. Connect with Rosalind on LinkedIn / Twitter.
