Some recent developments and experiences in the global and Perth market have me convinced there are two emerging and complimentary DevOps services about to take up greater air-time on your social feeds:
1. Managed Cloud Centres of Excellence and
2. Managed DigitalOps
These services offer the hope of significantly simplifying the road ahead for tech leaders grappling with the challenges of establishing Cloud Centres of Excellence (CCoE) and/or associated DevOp or DigitalOps capabilities.
The first sign was in a recent DevOps meetup where a colleague demonstrated a Landing Zone capability together with a significant IaC template repository, reference pipelines and associated processes he had developed in concert with a European software provider for their global mining client.
This capability wasn’t just delivered. It was delivered and then maintained. Tested each night to ensure the complex elements and underlying client specific assumptions came together perfectly to build a set of archetype environments along automated pipelines. Enhanced as necessary for new archetypes and demands from an ever increasing queue of divisions and regions keen to take advantage of the capability.
Chosen consultants then worked with client teams to help them skill up on this new Cloud and DevOps capability to then use for their own projects.
In effect they were providing the seeds of a Managed Cloud Centre of Excellence. But a CCoE is much more than just a few templates and pipelines. There is significant work internally to do at the business level to ensure this all comes together. So where does my colleague’s role end and that internal one start?
On to a fairly recent development contributing to my belief in these new services… the work done by the Team Topologies duo in defining the various team types and interaction patterns involved in DevOps (and indeed teams at a broader level). This work defines four team types. Three are important to this discussion…
Stream-aligned team: aligned to a flow of work from(usually) a segment of the business domain
Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities and addresses these through facilitation or collaboration.
Platform team: teams that provide a compelling internal product to accelerate delivery by Stream-aligned teams, ideally via an API like interface between the teams and facilitated by enabling teams.
My colleague was in effect providing an API like service that aligned to the platform team above. Additionally. he was also providing the more collaborative enabling team (Managed DigitalOps) at times when his team went out to help their client’s stream teams.
Services designed around platform teams are in my mind a natural fit for managed service models. It’s starting to happen already and will continue to evolve. The enabling teams then become an extension of that service engaged as and when needed, potentially under a more consultant-like model. That’s not how my colleague’s service was defined but I can see how it could grow into this.
And that takes us on to my final instructive experience, a comment regarding retention from a prospective client with whom we’ve been discussing DevOps services for some time.
Rather than a Landing Zone being dumped on him and his internal team by a set of consultants, he was looking for an ongoing service to deliver, maintain and enhance his Landing Zone and associated IaC template capability. Aha. That’s akin to my colleague’s service but under an explicit ongoing arrangement. A managed service model.
He reasoned that in the past he had found “DevOps people hard to find and harder to keep” and so he’d seen internal capabilities crumble due to this lumpy access to talent and didn’t want to see that happen again.
This second observation left me thinking in that – although I believe much of DevOps must be internally driven - I’ve seen plenty of examples of his cited challenges in establishing and maintaining an appropriately skilled internal DevOps capability.
While some have nailed it (for now) it’s not easy keeping these people pinned down for long. The reasons are many and as a DevOps guy I’ve experienced a few myself. What I’d like to deduce from personal experience however is that a nucleus of like minded people working on a variety of DevOps challenges together, will bond and keep these types of people together for longer.
Adding to the retention challenge - the realms of DevOps and Cloud are evolving at pace and keeping up can be difficult and cost ineffective for our clients - leading to substandard solutions. Forces to suggest a specialist managed DigitalOps service might provide a more economical, consistent, and current capability. And a natural source for that enabling set of specialist services is that managed service platform capability already engaged within your organisation.
From the above experiences and my usual dose of regular research, I’m forming an opinion these two new services will soon start to take up a good deal of the heavy lifting for technology leaders, freeing them to spend more time on the more important areas of vision setting, organisational changeand operating models. Operating models which will now be much simpler due to these new managed service offerings.
We have the elements to put these services together for our clients and are considering it. If you think you might be interested then please drop us a line - even if you’re not yet ready to commit and just want to throw around a few ideas.
Every conversation dealing with the DevOps challenges tech leaders face is another chance for us to learn.