Digitalisation in a Post-Covid19 World (5/6)
Previously in digitalisation...
Welcome to the fifth in the series on Digitalisation and the Digital Maturity Model aimed at helping demystify an often-confusing realm for leaders, by translating technical terms from the argot of engineer-speak to logical constructs that help leaders navigate modern computing concepts.
The first article provided a backdrop as to why digitalisation will accelerate post-Covid19, set out the six aspects of the Digital Maturity Model, and covered the first of these, Cloud Platforms. The second article covered Cloud Native Applications, the third discussed DevOps and Site Reliability Engineering (SRE), and the fourth provided insights into what Agile Delivery means and when to use it. In this, the fifth in the series, we look at the Operating Model. When implementing digitalisation it’s important to understand that old, non-digital, models won’t work without an overhaul.
A conceptual Phoenix
Sometime ago, Gartner came up with the concept of the Bimodal operating model. The idea was that Mode 1 was for the “more predictable and well-understood” whilst Mode 2 was “optimised for areas of uncertainty.” It didn’t take much of a leap to extrapolate this out into an IT operating model. Mode 1 for legacy, known, stable systems, Mode 2 for the more experimental microservices stuff. The theory gained traction and application (in the usage sense of the word). But as time wore on, it attracted a fair amount of criticism. Three main points of contention were raised:
- It was too simple. Many felt distilling the world into two camps glossed over nuance, effectively overfitting either Mode 1 or Mode 2 where it was inappropriate to do so.
- There was no acknowledgement of the overlap between modalities. In essence, where was the synchronisation between the modes and how did one account for it?
- Mode 2 had a baked-in assumption that increased speed meant reduced quality. That these were inversely correlated was rejected out of hand by many in the Agile and Continuous Integration / Continuous Delivery world… And with good reason. It’s an example of a modal scope fallacy (pun intended).
- It told CIOs what they wanted to hear, but not was was necessarily right. Don’t bother fixing your slow and clunky old kit, just concentrate on the sexy stuff. Trebles all round!
So, the question becomes: is it worth picking through the concept and modifying it? What happens if we take Mode 1 and Mode 2 and add to it? A kind of bricolage of concepts.
It turns out that doing this enables us to create a template, or model, for something that complements the digital maturity model well. Take a look at the following diagram:
You don’t see Mode 1 in this model – not because a firm shouldn’t have a Mode 1 model, but because you probably already have that figured out and what we’re looking to do here is provide that which is relevant to the Digital Maturity Model.
Okay, let’s go through the model, keeping in mind that you will want to tweak and add to the above in the context of your firm. This is not a one-size fits all (or, necessarily, anyone). As its creator, Martin Walsh at Think Above Cloud says, it’s simply an exemplar. Okay, we’ve dispensed with the caveats, let’s crack on.
The Key
Functions in green with a yellow outline are those you probably have now, but that need to be revised (enhanced) to fit with the model. Those in yellow with a green border are new functions, at least for this model. For example, you may have Product Teams already, but they won’t be the same type – these will be independent of those (see below).
The below are presented by following the diagram in a clockwise(ish) direction starting at the leftmost side.
Security, Risk, and Compliance
This is where the corporate policy setting takes place. You probably have one, or more, departments or teams covering this, but they will need to be given the tools and information to ensure that policies set for digital services, such as Public Cloud, are not antiquated and unfit for purpose. A great example of this is in the use of Firewalls, a front-line defender of legacy networks. In the Public Cloud, you almost certainly need to move to a Zero Trust security model. On top of that, because a lot of the infrastructure is dematerialised (i.e. code), the risk profiles and security concepts change. However, somethings will stil be the same, such as some of the compliance rules coming from regulators.
Enterprise Architecture
By virtue of moving from legacy to Public Cloud, you now have different architectural considerations. Thus, your Enterprise Architects will need to understand how the new plugs into itself and the old world. The good news is that this isn’t difficult and you can get quite far in a reasonably short period of time, but the training still has to be done.
Domain Architecture
Whilst it’s important for the big picture people to understand how everything fits together, the principles they come up with need to be enforced at the domain architecture level so the domain architects need to be brought up to speed too.
Finance
You’d be forgiven for thinking that finance won’t change much, or at all. But there are two major things to consider when you move to the Public Cloud:
- Software and products move from a licence model to a consumption model
- Agile development is best funded sprint to sprint (or similar), rather than upfront annual budgeting
- Delivery becomes continuous, rather than grouped into expensive and error-prone releases.
In finance speak, we move from Capex to Opex. This can seem counterintuitive because as it implies that you can’t depreciate certain costs against tax, but this isn’t true. There are mechanisms for writing Opex costs against tax (one for another post another time).
There is a fourth consideration too: Cloud services are charged on a consumption model. It’s important, then, to set budgets in agreement with the technology teams and ensure that budget policy is reflected in the rules of the code that operates the resources; what some firms call FinOps.
So, finance models need to be updated and finance professionals need to learn how the new world works.
Executive Function
Here, the term “Function” means not just the C-Suite, but also their direct reports. Indeed, we might want to extend this to Senior Management a layer down – it depends on how flat (or not) the organisation is.
Introducing Cloud and Agile Delivery models, introduces new Organisational logics. These logics compete with existing logics but, because they’re different, the executive’s relationships with them, and understanding of them versus what currently exists, need to be different too. Effectively, we can view the interplay between logics as a microcosm of Wicked Problems (Wicked Problemettes, perhaps). Here’s Keith Grint again:
Once the leadership team grasps the concepts of Public Cloud, experience shows they’re able to engage with the teams positively and make informed decisions. This doesn’t require them to go on long courses – regular communication from project leads, a few initial participative workshops, and a regular infusion of tailored executive coaching normally suffices [shameless plug, StoryPositive can help with all of these].
Portfolio Management
I’m not talking about traditional portfolios of projects. This is a portfolio of products that exist within the digital landscape of the organisation. So, in this sense it’s new and it’s important that the Portfolio Managers are aware of what running a digital portfolio entails. Again, it doesn’t take a lot to get people up and running to a sufficient level. Portfolios in this context refer to a group of one or more Products.
Product Management
In Agile Delivery, it’s common to have Product Managers. These are the people who live and breathe a product and are responsible for nurturing it through its lifecycle. It is their responsibility to continually prioritise the work required to keep the Product up to date. Another way of looking at it is that the Product Manager is the font of all knowledge about a product and the arbiter for all decisions surrounding it. They may do this in conjunction with the Portfolio Manager, but they should be empowered to make unilateral decisions for the most part. To do Product Management well not only requires understanding the product itself, but also the development process and operations management surrounding the product. Thus, it is essential that Product Managers are taught Agile Delivery, Cloud concepts (Cloud Native Apps, the differences and similarities between Cloud Platforms, and effective prioritisations mechanisms) as a minimum.
Agile Ways of Working
We discussed Agile Delivery in part four of this series, though it wasn’t the role of that article to delve into the different substrates of Agile that exist. Neither is that the role of this subsection – there are a lot of different ones out there, on which many books have been written; however, I will just say that the most common centre around SCRUM (in which we most frequently see delivery blocks known as Sprints) and Continuous Delivery (Kanban [the methodology, not the board]).
Clearly, for a team to work in a certain way, it is advantageous to have people be trained in that way. If you don’t, as mentioned in part four, people are likely to start making assumptions and lots of those will be incorrect and, worse, different meaning that you’ll be introducing competing logics into the organisation that don’t need to exist – or, in other words, making a rod for your own back.
The Service Desk
Again, because there are new processes, new ways of working, some interactions with the Service Desk will change. I’d be surprised if you didn’t already have a Service Desk so here it’s a matter of embedding new interactions into existing, and creating some new, processes.
Secure Cloud Ops
This is a Site-Reliability Engineering Function (SRE). If you haven’t already done so, you can read up on SRE in part three: DevOps and Site Reliability Engineering (SRE). In terms of the Operating Model, though, it’s normal for an SRE function to have the power to throw code they feel is not up to scratch back to the appropriate development team. Experience suggests that where this has been done in practice, the incidents of SRE teams doing this are far and few between. This is because the SRE team works collaboratively with the teams that hand off to it.
SRE is a highly skilled function so you want to ensure that your resource are up to the right levels. This could entail training or hiring in new people who already have the skill set.
Secure Cloud Centre of Excellence (CoE)
The Secure Cloud CoE sets the standards for Cloud security. This differs from the standards set by the architects as its more nuanced. They may also set guidelines or guardrails and write the standards that need to be followed. Again, this is a highly technical role – Cloud security, as mentioned earlier, is a different paradigm from legacy security and there are many aspects to consider.
Secure Cloud Admin
The Secure Cloud Admin are the implementers and doers of Cloud Security. These are the people who encode the policies, set users up, make sure that policies set by finance and others are incorporated into the templates (that they create).
Mode 2: Product Teams, Features and Support
Existing products may not be suitable for support from the Secure Cloud Ops / SRE team. This may be because of known quality issues, third party contracts, or a host of other reasons. When this is the case, the team may be responsible for the support or it may be outsourced to a third party. Yet the product development itself may very well be following a Mode-2 development path.
Importantly, the Production instance used by these products will be separate from that supported by the Secure Cloud Ops / SRE team.
Mode 2: Product Teams
These are the teams that develop products but once live, they are mixed in with the ecosystem that the Secure Cloud Ops / SRE team are responsible for.
Mode 1.5: Traditional Development Teams
Mode 1.5 wasn’t in the original Gartner model. It’s important because it’s where the interaction between Mode 1 and Mode 2 takes place. It’s the acknowledgement of that necessary interaction, where traditional development teams – whose may be required for some time yet or who may never disappear – are creating systems that interact with the Mode 2 systems. Importantly, the integration may impact the SRE function.
Additional Resources
Web Resources
Of course, we would love to engage with you on the leadership piece – helping leaders to navigate the complexity and set the goals and outcomes for those they engage – but, at StoryPositive, we’re not the engineers. We have worked with the following companies to provide successful outcomes on Agile-based Delivery. Here is a selection:
- Adaptavis – A company focussed on Agile methods, efficiency, and the removal of Delay Costs
- eSynergy Solutions – Delivering pre-formed software engineering teams and projects related to DevOps Transformation, Cloud Computing and Data Engineering.
- Think Above Cloud – A firm focussed on delivering high-value change through Public Cloud engineering
- Secure Delivery – Experts in Application Security Consulting, Training, and Assessment.
Before you Go...
If you’ve found this article informative, please consider sharing it with colleagues and others in your network.
Next time...
In the next article, weโll bring it all together as we conclude the Digital Maturity. There’s an aspect that hasn’t been covered in any of the previous articles and its one of the most important to understand and get right. Donโt worry, it’s also aimed at leaders, not engineers.