Microstructures and other Velocity Drivers — Part 4

I’m releasing parts 4 and 5 together, as I feel that I can’t explain the impact of one without the other.

As I say in my Introduction, please be patient and keep an open mind as all will be revealed in the following chapters.

The previous section can be found here: https://medium.com/@paulpogonoski/microstructures-and-other-velocity-drivers-part-1-c0361b766e20

Microstructure Ownership and Responsibility

At this point, I hope that you are beginning to understand why Microstructures is considered the key Velocity Driver. As with everything in Velocity Enablement, Microstructures are not a radical re-engineering of your cloud Architecture, they require no new technology or skills, just an adjustment in thinking re responsibility and ownership.

Microstructures gift a significant amount of agility and velocity to the Dev teams, as well as a significant amount of resources are freed up in the DevOps team for them to take on new challenges (more on this later).

Microstructures also, over time, gift operational and runtime knowledge to the Dev teams. Thus, making the critical Non-Functional aspects of their code transparent, removing the fear, or distrust, that opaqueness brings and much easier to understand and deliver.

There may be those amongst you arguing that the SRE movement does this. I would say that it doesn’t, for the following reasons:

1. Just like with DevOps, the industry did not take time to understand where the term came from and what it meant in that context. Instead it applied its own definition based on its existing prism of the world, thus making SRE’s more like existing positions with existing skill sets. If those organisations that employ SRE’s used them as per the original definition, then It would look similar to the DevOps team I will propose in the DevOps team structure chapter, but
2. SRE’s take the responsibility for reliability away from Developers and assume it themselves, in that centralised, funnel generator, SRE team.
3. If not in a centralised team, SRE’s end up being embedded in the Dev team and becoming the “infra Guy/Girl” of the team. Again, taking the responsibility for reliability away from Developers.

The key point about Microstructures is that the Dev team now becomes responsible for the complete lifecycle of the code they produce, with modern tools and technology making this responsibility much easier and attainable.

Even assuming Dev teams want to take on this additional responsibility, and that they understand and accept that this will allow them to have net more time to activities they currently don’t have time for, how will they attain the skills and knowledge that allows them to do this?

The answer to this question becomes clear in the next chapter. However, in summary The DevOps team(s) will restructure, both to take advantage of the time and resources they have been given back, but also to allow them to advise and mentor the Dev teams so that they will, in combination of the teams taking on formal training on IaC and CasC tools and practices, attain these abilities over a short amount of time.

The addition of new value-added utilities will save them time and effort, and the need to develop and manage Pipelines, IaC, and CasC themselves.

The advice and mentoring received from the DevOps team(s) via their Advisory Service, will considerably shorten any learning time while they “Learn as they Do”.

The support and mentoring received via participating in Paired Support on incidences, will, again, considerably shorten any learning time while they “Learn as they Do”. Especially with respect to problem detection and solving in a high-pressure situation; as well as Root Cause Analysis post incident.

To repeat some salient points in respect to the changes Velocity Enablement requires of Dev and DevOps teams:

• It makes existing teams take on new responsibilities via the redistribution of responsibility based on the Agile Application Lifecycle
• It does not change make-up of the teams wrt to their experience and skills
• It does require the learning of skills that will increase an individual’s value
• It does not abandon the teams to learn those skills by themselves
• It makes teams share the burden of Production support
• It creates a “virtuous circle” of improvement based on lessons learnt from Production incidents, creating increasing MTBF (Mean Time Between Failures) and increasing improving MTTR (Mean Time to Recovery)
• It creates time to be able to apply the lessons learnt into the improved Development practices

Now, please read on in Part 5 to see how the re-modelled DevOps team supports this.