principleMinor
What is good and/or bad about Accenture's Multi-speed IT approach to DevOps?
Viewed 0 times
multiwhatapproachbadaboutgoodandaccenturespeeddevops
Problem
Accenture are talking a lot about their "Multi-speed IT" approach.
It appears in their strategy consulting here:
and on blog posts in their DevOps blog:
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?
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?
Solution
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.
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.
Context
StackExchange DevOps Q#1411, answer score: 4
Revisions (0)
No revisions yet.