What is good and/or bad about Accenture's Multi-speed IT approach to DevOps?

Question

Accenture are talking a lot about their "Multi-speed IT" approach.

It appears in their strategy consulting here:

• https://www.accenture.com/us-en/insight-calibrating-multi-speed-it

and on blog posts in their DevOps blog:

• https://www.accenture.com/us-en/blogs/blogs-support-multispeed-it-with-devops-agile
• https://www.accenture.com/us-en/blogs/blogs-emily-arnautovic-devops-change

As well as in many other places that deal with various aspects of a technology organisation.

Their own "head of DevOps" is talking about how Multi-speed is a bad practice https://www.youtube.com/watch?v=yGcXLwsnDgg

Does this idea of "Multi-speed IT" has merit and can be used for continuous improvement in-line with DevOps? Or does it go against some of the common DevOps practices?

Answer 1

There are reasons different parts of the environment might change at different frequencies. One example might be a calendaring service, most large organizations have one, they provide information about the current day, if it is a holiday etc. The calendaring service does not need to change frequently because it provides a stable function. This calendaring service may be used by many different kinds of apps that also move at different speeds.

Multi speed exists because you need to deal with making changes that deliver value. Many people indicate multi speed is to deal with the font end system of engagements and the systems of record. Yes, generally user facing systems change more often because of the desire to update for the end users and experiment with different ways of presenting data to get the best value. However, the systems of record may need to be changed as fast, in order to satisfy a new business requirement.

If all parts of the application are built using a pipeline with appropriate automated testing, and deployment, and their are ways to test independently but also test together, then any part can move as needed. It is similar to the gears thought that the different parts move but need to be integrated such they you know they work together as they are deployed.

Answer 2

Based on this

The smaller gear moves much faster than the larger one, but where the two gears interlock they remain aligned to not stop the motion.

and this quote

The whole idea of the 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 make sure you have in place the right components for each application, 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 better remove those variables introduced through manual steps by having these processes completely automated.

from this post one could say that the multi-speed IT approach could be aligned with DevOps as it is aware about multiple departments and processes in an organization and that these do not need to align in terms of velocity as long as these get less dependent. For example, multiple DevOps teams could create a different amount of features every sprint without thwarting each other as long as the components are versionized, backward compatible and well documented.