Two-speed IT is a way of categorizing which parts of your infrastructure are likely to change rapidly and which change slowly.
This can be useful as a lens for deciding investment priorities but is likely to be too simplistic to be the basis of a legacy modernization program.
A way of looking at your tech estate as either fast-changing or slow-changing parts.
Two-speed IT was intended to make organizations better equipped to respond to opportunities and threats.
In many cases, the concept of two-speed IT is too simplistic. In the worst cases, it can damage your business.
What is it?
Two-speed IT is simply a way to look at your entire IT estate and establish which parts need to be able to change rapidly and which don’t.
This can be useful if used to prioritize spending: which business capabilities will benefit most from moving fast and being easy to change.
However, instead of being treated as a business capabilities issue, two-speed IT is sometimes applied to different layers of your IT infrastructure: customer-facing front-ends are seen as fast moving; back-end legacy systems as more stable, slow moving. The problem with this approach is that many of the business capabilities you need from your IT infrastructure depend on both front-end and back-end systems. There’s little point in having a slick customer-facing portal that cannot fulfil orders because of back-end integration issues.
What’s in for you?
Using a two-speed lens, you may be able to identify business capabilities that need to move fast to keep pace with a rapidly changing market, as well as other areas where sheer speed is less critical. For instance, your credit card processing system is unlikely to change every three months.
As a result, two-speed IT can be useful when it comes to prioritizing investments.
What are the trade offs?
Some of the early thinking around two-speed IT differentiated between horizontal layers of IT infrastructure. For instance, customer-facing front ends were fast, back-end legacy systems were slow.
Two-speed IT emerged in the mid 2000’s as both an organization and infrastructure approach to delivering increasingly customer-facing applications. However, the two groups were frequently at odds: customer-facing systems, using agile iterative methods, required legacy systems data on a short cycle; legacy systems groups employed slow enhancement and maintenance processes that couldn’t meet the needed time schedules. In retrospect, splitting into two-speed IT didn’t work well.
Two-speed IT is an unusual way of thinking about your infrastructure because it doesn’t take into account business capabilities — those vital activities that will touch all layers of infrastructure. We have seen companies fail by following this type of two-speed thinking: one retailer we know of was able to quickly add new products to its website but unable to process orders because it hadn’t allowed for changes to ‘slow’ back-end systems.
How is it being used?
The rise of agile delivery and the emergence of DevOps has largely overtaken two-speed IT when it comes to thinking about the work that the IT department does. Today, two-speed IT is chiefly used as a prioritization tool.
Would you like to suggest a topic to be decoded?
Just leave your email address and we'll be in touch the moment it's ready.