<p>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.   </p>

<p>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.   </p>

<p>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.  </p>

CC BY-SA 4.0
2018-08-10T00:39:25.700Z
2018-08-10T00:39:25.700Z
Rosalind Radcliffe
<p>Based on this</p>

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

<p>and this quote</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>from <a href="https://dzone.com/articles/how-support-multi-speed-it" rel="nofollow noreferrer">this post</a> 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.</p>

CC BY-SA 3.0
2017-10-20T21:07:34.247Z
2017-10-20T21:07:34.247Z
030
<p>Accenture are talking a lot about their "Multi-speed IT" approach.</p>

<p>It appears in their strategy consulting here:</p>

<ul>
<li><a href="https://www.accenture.com/us-en/insight-calibrating-multi-speed-it" rel="nofollow noreferrer">https://www.accenture.com/us-en/insight-calibrating-multi-speed-it</a></li>
</ul>

<p>and on blog posts in their DevOps blog:</p>

<ul>
<li><a href="https://www.accenture.com/us-en/blogs/blogs-support-multispeed-it-with-devops-agile" rel="nofollow noreferrer">https://www.accenture.com/us-en/blogs/blogs-support-multispeed-it-with-devops-agile</a></li>
<li><a href="https://www.accenture.com/us-en/blogs/blogs-emily-arnautovic-devops-change" rel="nofollow noreferrer">https://www.accenture.com/us-en/blogs/blogs-emily-arnautovic-devops-change</a></li>
</ul>

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

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

<p>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?</p>

CC BY-SA 3.0
2017-06-23T13:30:29.387Z
bah; to me, it is manager-appealing jargon and nothing else
ᴳᵁᴵᴰᴼ
CC BY-SA 3.0
2017-06-26T20:30:31.430Z
Check over to here: https://devops.stackexchange.com/questions/1403/what-are-known-useful-and-misleading-memes-in-the-devops-culture and see they're discussing it as a bad meme
Chase
<culture>
What is good and/or bad about Accenture's Multi-speed IT approach to DevOps?
Evgeny Zislis
# What is good and/or bad about Accenture's Multi-speed IT approach to DevOps?

(Asked by: username_0 on 2017-06-23)

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?

**Tags:** culture

> **Comments:**
> **username_1**: bah; to me, it is manager-appealing jargon and nothing else  
> **username_2**: Check over to here: https://devops.stackexchange.com/questions/1403/what-are-known-useful-and-misleading-memes-in-the-devops-culture and see they're discussing it as a bad meme  

---

## 2 answers

### Answer by username_3 on 2018-08-10. Score: 4

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 by username_4 on 2017-10-20. Score: 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](https://dzone.com/articles/how-support-multi-speed-it) 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.


---

