Sometimes, you just know that things won’t end well.
When a company takes on a Cloud Native project, let alone a full transformation, it’s already got a lot of challenges ahead of it.
There are so many choices (more than 1,200 vendors and products in the space at this writing). So many unknowns. So few engineers who have experience with these new technologies. And so little understanding of the changes that need to be made in people and processes to get the most benefit from the tech.
But there are some red flags that can appear even at the start of the process that makes the chances for success even smaller.
I’m an independent consultant for financial technology (fintech) who served as Starling Bank’s chief technology officer, helping it rise from start-up to successful online financial institution. I’ve worked with the Cloud Native experts at Container Solutions. Recently my peers at CS and I talked to a European company that has just embarked on a Cloud Native transformation.
The most worrisome part of the experience was the strong sense that this company is falling prey to a common problem with such initiatives: repeating mistakes it has made in the past.
This is surprisingly common. After all, there’s a reason you made the mistake once. Unless you can recognise it and confront it, you are doomed to make it again.
Locking In to a ‘Low-Code’ Future
The company we met with is working with aging and inflexible systems, a hodgepodge built over the years by bolting a variety of new systems onto an AS/400-based legacy core written using proprietary development technologies. It’s still a profitable company, but its customers are beginning to leave, and the company’s own reporting shows revenue trickling away each month.
The project is rightly targeting not just tech but also organisational culture. However, currently, it’s an IT-only undertaking, with little to no involvement by its business executives. Despite this, it’s set very aggressive goals for reaching milestones, one of which requires a partner it has not yet identified.
These factors could all be considered red flags. But the biggest one involves the company’s choice of platform. The organisation is locking into a ‘low-coding’ platform product, one that will almost certainly be hard to adapt later, and will leave the company overly reliant on the vendor. Unlike with open standards, mainstream languages, and open-source products, it will be hard to find support in the wider engineering community for any problems that arise.
The company has opted for a ‘low coding’ platform because it does not believe it will be able to hire engineers, either in quantity or quality, to build any other way.
In essence, it is repeating its past: locking itself in with an inflexible, proprietary ‘dumbed down’ platform that will grow progressively harder to maintain, and to scale up. There’s not a lot of support documentation available on Stack Overflow or elsewhere for proprietary or niche development technologies. The ecosystems are tiny.
Worse, the technology choice contributes to a vicious circle in recruitment. It will get harder and harder for the company to hire high-quality engineering talent. The best engineers want to work with cutting-edge technology, not dumbed-down products.
As I mulled these concerns over on my journey home, I came to the view that there are enough red flags that the transformation would fail—maybe not right away, but probably in six to 12 months’ time. At best, it will deliver what the company currently does more efficiently, and maybe in a more resilient way. Even if it is successful enough to last into the longer term it will have reproduced the problems of the past, the next twist in an ongoing cycle of stagnation and transformation. But more likely, while it’s busy building a system to maintain its status quo, its competitors will innovate and outpace it. Some of the sharpest tech outfits on the planet are now working in the company’s industry.
But it doesn’t have to be this way.
A Transformation Case Study
The European company whose new project is beset with red flags reminded me of a project I participated in a few years ago. A decade ago, CHP Consulting —a U.K.-based organisation now called Alfa—was seeking to migrate its platform away from the same proprietary, niche development technology.
Over the course of about two years, the company replaced a million-line AS/400 codebase with a modern Java codebase, by a process of automated conversion and targeted rewrite. At the same time, it transitioned to agile dev processes and underwent other organisational change.
It was a high-risk, high-investment task, but it worked, for these reasons:
- The project relied on high-calibre technologists, with good knowledge of the target state.
- The people managing the project correctly identified the key problems the transformation needed to solve and understood that they needed to develop in Java, rather than repeat their initial selection of a dumbed-down proprietary development technology.
- The company recognised that it needed to change people and processes as well as technology, and acted on that knowledge.
Today Alfa has transitioned from a consultancy to a software engineering company, and now hires high-calibre engineers. By running its initiative with technologists at the heart right from the beginning, and by thinking strategically and making careful changes and choices throughout its organisation, its transformation worked.
A Cloud Native transformation, when undertaken in a thoughtful, stepwise way, should reduce risk. Its success is also dependent on getting everyone in an organisation involved. The days when business executives and board members can hand off oversight of technology to the IT department are gone.
No matter what your business is, you’re in tech now. The way forward means embracing that idea—and learning from past mistakes.