A lot of organizations talk about multi-speed IT these days, so I thought I’d share my thoughts on this. I think the concept has been around for quite some time but now there is a nice label associated with the idea.
Let’s start by looking at why multi-speed IT is important. The idea is best illustrated by a picture of two interlocking gears of different sizes. The smaller gear moves much faster than the larger one, but at the point where the two gears interlock, they remain aligned to allow continuous motion.
But what does this mean in real life? Think about a banking app on your mobile. Your bank might update the app on a weekly basis with new functionality like reporting and/or an improved user interface. That is a reasonable fast release cycle. However, the mainframe system that sits in the background and provides the mobile app with your account balance and transaction details does not have to change at the same speed. In fact, it might only have to provide a new service for the mobile app once every quarter. The changes between these two systems need to align when new functionality is rolled out but it doesn’t mean both systems need to release at the same speed. In general, the customer-facing systems are the fast applications (also known as Systems of Engagement; the smaller, faster gear in the above illustration) while the Systems of Record or backend systems are the slower ones (the larger gear). The release cycles should take both into consideration.
So, how do you get ready for the multi-speed IT delivery model?
Release Strategy (Agile) – Identify functionality that requires changes in multiple systems and ones that can be done in isolation. If you follow an Agile approach, you can align every n-th release for introducing functionality that is aligned for both types of systems while the releases in between can deliver isolated changes for the fast moving applications.
Application Architecture – Use versioned interface agreements so that you can decouple the gears (read applications) temporarily. This means you can release a new version of a back-end system or a front-end system without impacting current functionality of the other. Once the other system catches up, new functionality becomes available across the system. This allows you to keep to your individual release schedule, which in turn means delivery is a lot less complex and interdependent. In the picture I used above, think of this as the clutch that temporarily disengages the gears.
Technical Practices and Tools (DevOps) – If the application architecture decoupling is the clutch, then the technical practices and tools are the grease. This is where DevOps comes into the picture. The whole idea of multi-speed IT is to make the delivery of functionality less interdependent. On the flip side, you need to spend more effort on getting the right practices and tools in place to support this. For example, you want to make sure that you can quickly test the different interface versions with automated testing; you need to have good version control to ensure you have the right components for each application in place; you also want to make sure you can manage your codeline very well through abstractions and branching where required. And the basics of configuration management, packaging and deployment will become even more important as you want to reduce the number of variables you have to deal with in your environments. You would do well to remove the variables introduced through manual steps by completely automating these processes.
Testing strategies – Given that you are now dealing with multiple versions of components existing in the environment at the same time, you have to rethink your testing strategies. The rules of combinatorics make it very clear that it only takes a few different variables before it becomes unmanageable to test all permutations. So we need to think about different testing strategies that focus on valid permutations and risk profiles. After all, functionality that is not yet live requires less testing than the ones that will go live next.
The above points cover the technical aspects but, to get there, you will also have to solve some of the organizational challenges. Let me just highlight three of them here:
Delivery partners – It will be important to choose your partners wisely. Perhaps it helps to think of your partner ecosystem in three categories: Innovators (the ones who work with you in innovative spaces and with new technologies), Workhorses (the ones who support your core business applications that continue to change) and Commodities (the ones who run legacy applications that don’t require much new functionality and attention). It should be clear that you need to treat them differently in regards to contracts and incentives.
Application Portfolio Management partners – Of course, to find the right partner you first need to understand what your needs are. Look across your application portfolio and determine where your applications sit across the following dimensions: importance to business, exposure to customers, frequency of change and volume of change. Based on this you can find the right partner to optimize the outcome for each application.
Governance – In a multi-speed IT world, you will need flexible governance. The “one size fits all” approach will not be good enough here. You will need light-weight system-driven governance for your high-speed applications and you can probably afford a more PowerPoint/Excel driven manual governance for your slower changing applications. If you can run status reports of live systems (like Jira, RTC or TFS) for your fast applications, you are another step closer to mastering the multi-speed IT world.