Gartner has been a proponent of
Bimodal IT for almost 5 years. IBM and every other API management vendor have been touting Two-speed IT or Multi-speed Integration or other names for the idea that companies can benefit from APIs enabling a faster time to market for business offerings. However, I recently read articles by very reputable authors stating that businesses should
not try to create a two speed IT. So, is two-speed IT something to strive for or to be avoided?
[caption id="attachment_10988" align="aligncenter" width="356"]
Image by
techexpert on Pixabay[/caption]
Setting the context
[caption id="attachment_10989" align="alignright" width="169"]
Image by
ArtsyBee on Pixabay[/caption]
The issue that has caused the most change in IT over decades is the difference between the desired time that a business wants to do something - i.e. now, and the time that IT is able to deliver it – typically much later. Massive pendulum swings between centralized and decentralized IT patterns are the result of this disconnect. Client server in the 1990s was a reaction to the lack of speed to deliver from central IT. The server proliferation and maintenance issues this caused resulted in a pull back into central IT, etc. The pendulum has swung back and forth several times.
Since the 1960s (maybe earlier) we have been trying to speed up how fast IT can deliver by raising the level at which developers work. From hardwired programming of computers, to operating systems, to 3GL programming, on to middleware (e.g. databases), application servers, SOA, BPM, and much more, these are all attempts to raise the level at which developers can work so that IT can deliver solutions faster.
APIs and Microservices as technology constructs are a different take on addressing this need for speed. APIs encapsulate a core system capability and make it available in a self-service, secure, controlled manner to a target audience. This allows the audience to consume the asset without requiring changes to central IT and progress at their own pace. The proposal is for a distributed development model where not all IT offerings are developed by central IT. APIs are the gears between the core systems and the consumers that let them move at different rates. Microservices (more on this below) are a mechanism to add business logic outside of the core systems to try new innovative ideas.
Before I state the case against two-speed IT, let me be clear that I am on the other side - a proponent of two-speed IT. So, I encourage you to read elsewhere for the full messaging delivered by those against it (in addition to what I say here). I have always believed that those on one side of an argument do not always fairly and completely describe the position on the other side. But, I will do my best.
Why Avoid Two-Speed IT
[caption id="attachment_10990" align="alignright" width="122"]
Image by
OpenClipart-Vectors on Pixabay[/caption]
Anti-two-speeders will state that two-speed IT is giving up on central IT, or that there should not be a slow speed IT and a fast speed IT. We need to continue to enhance central IT and improve its speed. There are also statements about organizational conflict between the central IT “slow” team and the “fast” team that this bifurcation will cause.
These are all very good points and if any of this were true or become true, then I would agree with the nay-sayers.
The case for Two-Speed IT
Consider the following:
- Would you want to make IT changes in your core systems to support new attempts at innovation, test the market, and then remove the changes if the innovation is not successful?
- Would you allow changes into your core production systems without executing regression tests to ensure core systems remain highly available?
- Do you have enough central IT resources to deliver everything the business is asking for in the next 2 to 3 months?
- Do you believe the rate of change is increasing or decreasing?
[caption id="attachment_10991" align="alignright" width="133"]
Image by
OpenClipart-Vectors on Pixabay[/caption]
For the companies I meet, I believe the answer to the first three questions is “no” and that the rate of change is accelerating. What do you think?
I am not a proponent of slow speed IT, nor do I believe that there should be two separate IT organizations that could create conflict. As we have done for decades we need to continue to accelerate the rate of change in central IT. But my view is that this is not enough to close the gap on development backlog and in fact it will get worse because of the increasing rate of change. Two-speed IT is a recognition that the change required by the business cannot be handled within a central IT organization alone. I recently wrote about this in “
Digital Transformation Requires Integration Modernization” and “
Integration Modernization Requires Good Parenting”. We need a mechanism to innovate and support Digital Business transformation that does not require changes to core IT systems simply to test an idea (see “
Using APIs and Microservices as a Fast, Low-Cost and Low-Risk Innovation Engine”).
Let me be clear, there is no good speed or bad speed organization. There is the correct rate of change for various aspects of delivery. Changing core systems that are running the business requires more deliberate change control than trying a new innovative offering in a test scenario. We need a method that allows this differentiation. Forcing core system changes too fast is a problem. Forcing innovation to move too slowly is also a problem.
[caption id="attachment_10992" align="alignleft" width="196"]
Image by
geralt on Pixabay[/caption]
Writing this, I pictured two debate teams going at the topic. Like most issues today, if going into the discussion you strongly believed one side had the correct answer, then you probably still believe this to be the case. But, also like most issues today, the discussion is nuanced and the desired outcomes on both sides are closer than they might seem. So, whether you choose to be a proponent or nay-sayer of two speed IT, the goal of delivering offerings to market faster is something both sides have in common.
To understand more about IBM’s thoughts on Digital Business and the API Economy visit the IBM
API Economy website. IBM API Connect is IBM’s complete foundation to Create, Secure, Manage, Test, and Monitor APIs. You can find more information about IBM API Connect at the
API Connect website. And you can also experience a
trial version of API Connect.
If you have questions, please let me know. Connect with me through comments here or via twitter
@Arglick to continue the discussion.