Digitalisation in a Post-Covid19 World (2/6)
Welcome to the second in the series on Digitalisation and the Digital Maturity Model aimed at helping demystify an often-confusing realm for leaders, by abstracting the technical to logical concepts. The idea is to help leaders more easily navigate a complex domain.
The previous 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.
This article looks at Cloud Native Applications – what they are and why you should be using them to provide solutions.
Bricolage
The author William Gibson is quoted as saying:
Gibson, himself, has cast doubt on whether he actually said that; however, regardless of the truth of the quote’s provenance, it’s a great way to look at the present in relation to the future. Okay, but what does it mean in practical terms?
Here’s another quote, this time from Professor Keith Grint:
I won’t dwell on the different types of problem other than to acknowledge that according to academic theory, leadership is a Wicked Problem (see below for the seven properties of a Wicked Problem in the context of Cloud Computing). Software engineering is a Wicked Problem. Thus, the leader and the engineer are faced with solving the same class of problem.
Fail fast, the philosophy of try, test, adapt, and adjust (i.e. if the solution isn’t working, find out quickly and pivot just as fast, is strongly aligned to the bricoleur argument made by Grint, above. In other words, use what you have, plug it together, and if it looks wrong, swap out the bits that aren’t working and replace them with other things.
Enter the Native App
Cloud Native Applications completely support this model. There are literally thousands of pre-canned components that skilled engineers can cobble together into any number of solutions. Using these pre-canned components comes with a number of attendant benefits:
- It’s quick to develop. For a majority of components, connecting one to the other is simply about configuration.
- It’s quick to deploy. Most of the solutions come with scripts to aid deployment – again, it boils down to configuration rather than bespoke development.
- It’s quick to change. Swapping out, or reconfiguring a component is relatively quick and can be done in a fraction of the time it takes to develop from scratch.
That’s not to say you can’t build something yourself – of course, you can if that’s really what you want to do. But the sheer availability of solutions within Public Cloud means that you can save immense amounts of time by taking off-the-shelf components and having experts plug them together. In many cases, when you explain the solution you want, the experts will already have a good idea of what components to use.
Common components are, by definition, fungible. For example, if the Azure implementation of Kafka doesn’t work in your context, for whatever reason, you can, instead, use the AWS one (or another provider’s, such as Confluent). If you don’t want to use Kafka as your event processor, you can use a different one. The point is, you don’t need to create a complex event processing engine from scratch.
With fungible software comes fungible expert engineers to implement it. If you build your own application componentry you may well find – as is the case with many legacy systems currently – that you’ve paid resource to develop not only your software but also their expertise only to watch that expertise walk out of the door when the project is “done”. Using Cloud Native Applications derisks the future because it provides a higher likelihood of being able to find available resource who can unpick parts of your bricolage and plug other parts in when the time comes to change… And, to paraphrase Bob Dylan: the times they are a-constantly changing.
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 cover the third aspect of Digital Maturity: DevOps and Site Reliability Engineering (SRE). Don’t worry, it will also be aimed at leaders, not engineers.
The 7 Properties of Wicked Problems
In 1973, Horst W.J. Rittel and Melvin M. Webber, identified ten properties of wicked problems, in their paper Dilemmas in a general theory of planning. The following are adapted, by the author of this post, from these in the context of software engineering / Cloud computing:
- There is no definitive formulation of a wicked problem. This is true in almost all software engineering projects. In Waterfall projects, it’s the reason specifications and software are subject to such a high-volume of Change Requests. In Agile projects, it evidences itself in the “fail fast” philosophy and in the constant reprioritisation of Backlogs.
- Wicked problems have no stopping rule. You can tell when you’ve reached a solution with a Tame or Critical problem. With a wicked problem, the search for solutions doesn’t stop until the problem is tamed or overtaken by another problem. In software terms, this relates to the fact that once a Product is live, it then has to evolve to keep up with client expectations and demand.
- Solutions to wicked problems are not true or false, but good or bad. Tame and Critical problems have solutions that can be objectively evaluated as right or wrong. The problem either works or it doesn’t. Choosing a solution to a Wicked Problem is largely a matter of judgment. Judgement may be flawed, which is another reason why, in Agile, we use the fail fast philosophy and in Waterfall the Change Request mechanism.
- There’s no immediate or ultimate test of a solution to a wicked problem. Solutions to wicked problems generate unexpected consequences over time, making it difficult to measure effectiveness; meaning that effectiveness atrophies over time. What works today, may not work tomorrow – but that’s not testable until we get to tomorrow.
- Every Wicked Problem is essentially unique. Tame problems belong to a set (of similar problems), all solved using the same template. This, by the way, is an excellent use-case for Waterfall as a methodology. Wicked Problems are substantially without precedent; experience does not help address them. This is true in many leadership and software engineering problems.
- Every Wicked Problem is a symptom of another problem. Tame and Critical problems are self-contained. Wicked problems codependencies on other problems. In software engineering, this is evidenced in dependent relations between other (internal and external) systems.
- Wicked problem have many stakeholders, who all will have different ideas about what the problem really is, what its causes are, and, in many cases, what solution to adopt. This is why Agile (the subject of a later article) is so useful – it allows demonstration of problem solving in short timeframes to Stakeholders, allowing an increase in confidence early on.