Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-10T00:39:25.700Z
Answers: 2018-08-10T00:39:25.700Z
Answers: Rosalind Radcliffe
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-20T21:07:34.247Z
Answers: 2017-10-20T21:07:34.247Z
Answers: 030
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-06-23T13:30:29.387Z
Comments: bah; to me, it is manager-appealing jargon and nothing else
Comments: ᴳᵁᴵᴰᴼ
Comments: CC BY-SA 3.0
Comments: 2017-06-26T20:30:31.430Z
Comments: 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
Comments: Chase
Tags: <culture>
Title: What is good and/or bad about Accenture's Multi-speed IT approach to DevOps?
UserDisplayName: Evgeny Zislis
ThreadText: # 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.
  
  
  ---
  
  