It’s inevitable that technology vendors see business transformation as an opportunity to promote their latest wares as the answer to everything. While clearly some (most?) technologies will have a role to play in transformations, the recent Software Intelligence conference put on by CAST, the French specialist in software analysis and intelligence, provided a timely reminder that simply making new technology the lynchpin of such strategies is likely to miss the point.
After all, one of the keys to business transformation is to remember that it is about the business, not a root and branch update of the technology portfolio. Some of that old legacy stuff might need to stay in situ. In some cases the business might collapse without it.
On the other side of the coin, understanding the interactions and interdependencies between applications is going to be crucial, especially in businesses with several thousand different applications in their overall portfolio. Changing one application without understanding those interdependencies with all the others can be a destructive force.
This is the challenge CAST pitches its tools and applications at solving. It also gave the company’s CEO, Vincent Delaroche, the opportunity to exploit the inevitable online delivery of the event to focus attention on customers and advisors that have gone, or are going, down the business transformation route, allowing them to talk through what they have learned.
Thomas Klinect, Senior Modernisation Analyst at Gartner Research, sees the subject from both the ‘why to do it’ and the ‘how to do it’ camps, putting him in a good position to provide a broad brush-stroke run-through of why and how businesses should go about the process of business transformation and general application modernisation. He puts the emphasis on the latter, not least because he feels that this is not a one-off occurrence of ‘transforming’ the business, one that is then done-and-dusted. It is in practice an ongoing commitment to change, as and when necessary or advantageous.
In addition, he argues, it isn’t about changing the technology – that may (indeed probably will) happen as a by-product, but the business comes first:
I bet everybody [can] tell you war stories of how they have failed and why they have failed and how it just isn't possible to modernise these platforms. The one thing that seems to be missing is the dialog around analysis. Because organizations think, ‘I built this stuff, I know how this stuff runs, I don't have to worry about doing analysis, I just start moving’. The one thing I've learned in over 30 years of modernisation is analysis is absolutely everything. To sidestep analysis is tantamount to throwing away or burning millions and millions of dollars.
Stop repeating all of the sins of the past. The only way to stop doing that is to literally stop and think about what you're about to do. Stop modernising it, it is not the problem. The true problem is the business. It's more business-oriented, less IT-oriented. Look at the business problems you have and then begin to think about how you might be able to proceed.
The issue here is that focusing on technology changes misses the point that the business processes don’t get changed. If they do, they are changed because of the technology change, which is entirely the wrong way round.
No ocean boiling
One of the objectives of a ‘technology first’ approach is the reduction of technology debt. Klinect acknowledges that is an important step which can help reduce the decomposing complexity in the business. But it can be risky to launch headlong into cutting technology debt if you are not sure where the debt actually lies. This is where analysis of the software is crucial as this can expose where the real debt and the complexity lies:
Don't boil the ocean. Don’t try to attack it from an IT perspective. IT perspectives only spend vast amounts of money. You want to look through ‘the keyhole of business’. Look at a business process from beginning to end, understand what's involved in that business process and how do you understand it.
Such analysis will allow a business to understand what resources it has, where they are and how they work. Those resources can then be grouped as business processes or functions, so that the applications which make up a business process can be worked on simultaneously, rather than the old method of ‘pick a database, convert it’ or ‘pick an application, convert it’. For Klinect, not only do these mantras not work anymore, they result in spending lots of money. And it has to be remembered that technology is not the only debt problem, he says:
There is personnel [to consider]. You have people coming out of university today who don't know any of the older languages. They don't know what's been put out there before them. They know what they know from their college environments. Universities teach what they can, but once you land inside of an organization, there's so much more than just the technology.
He refers to the analysis needed as Enterprise Complexity Analysis (ECA), demanding tools that can analyse the enterprise in totality, down to the level of an individual user. This he likens to an X-ray into the entire enterprise and the cradle-to-grave flow of data, from application to database to file system and on through the network.
From this what steps should then be taken will emerge, with a key one being the mapping of business processes - how a company buys and sells, what it buys and sells and so on - and maps them into the time quadrant. Klinect urges:
Do something crazy here. Don't take the low-hanging fruit. The value of low-hanging fruit is almost zero to business. Any organization which is doing a modernisation has to concentrate on one thing, bringing value from the monetisation back to the company and to the business processes. So, take the ones that are in the best quadrant, those are the important ones, and rank them the most valuable one on top, the least valuable on the bottom. That's your order of modernisation.
The last job – before the modernisation work begins – to is map this list against the ECA results that have emerged. Each business process is connected to specific applications, databases, file systems networks, which becomes the target list of modernisation tasks that also address the most valuable need within the business:
And it's all about continually doing this. Don’t just do it once. It's about a continual evolution. Don't just stop because, ‘Hey, I'm done, I’ve got it fixed.’ Now look at what you can do with all that you've done.
Have you got 53 year-old apps?
One company currently going through that on-going process is the $80 billion-plus Wells Fargo Bank, one of the largest in the USA. Its Head of Technology, Saul Van Beurden, deals with an applications portfolio that is numbered in the thousands. To give an idea of size, he heads up some 40,000 technologists and a tech budget of around $9 billion. Modernisation across that scale of operation is difficult – but essential, he says:
We have, of course, mounting competitive pressure of the tech giants, where Google, Apple, Amazon are all going into the banking space and we have the fintechs steaming out.
The bank sees its main responsive weapon as speed of operational and service delivery, combined with stability and security. The bank’s modernisation plan includes building cross-discipline teams who work with a goal of automating as much as possible. This needs less governance as controls can be embedded in the automation. The goal is ‘information at the fingertips’, which in practice means software-defined everything, with the goal of becoming cloud-enabled. That raises some interesting challenges, admits van Beurden:
We have thousands of applications and expect that a large part, between 60% and 70%, can go to cloud. We have a long tail of applications. The oldest applications that we have are 53 years old and we have also fresh micro-services that were implemented yesterday or over the weekend. Basically, we deploy them continuously.
That's why we use CAST - to get better information on state of our code, where we know what is cloud-native and what can go to the cloud without any large rewrites, versus things where we really need to refactor the whole application to make it cloud-native. And then you're going to see what is the business case to do.
John Granger, SVP & COO of Global Business Services with IBM, cites two other factors that some more established businesses might not realise when it comes to migrating to the cloud. One is that it is not just a simple lift-and-shift of every application; the other is that there is not just one cloud, but rather an open, hybrid, multi-cloud environment that has to be exploited correctly if the best is to be made of modernisation.
What is more, most businesses are still in the learning phase, coming to the end of what IBM dubs ‘Chapter One’, that period of concepts, innovations and pilot projects. ‘Chapter Two’ is where some of these are scaled-up to work with core business processes and mission critical workloads. This is when the pilot projects have to be mapped against the analytics of the existing applications and business processes so that a roadmap can be built covering which applications can be lifted-and-shifted, which can be rebuilt or refactored, which ones are rewritten and which ones retired:
We're now tipping from Chapter One to Chapter Two. But the other thing that is really important is what the destination is. Everybody talks about the journey to cloud as if it's a monolithic destination, but the reality is that most of our clients are really thinking in terms of hybrid, because a one-cloud-fits-all approach is not going to work. Clients typically have their on-prem environments, they will have a private cloud, they may have a number of public clouds, so when they think about their application estate, they may not wish to move all of those to the public cloud. Some are complex and long-lasting and it's simply uneconomic to move them.
Here is another example of how, while it is about the technology in one way, in practice the process of business transformation comes back to basic issues such as `Why you want to do it in the first place? What are the goals?’. These make up the map that must then be followed, with analysis of the data flows through applications detailing the paths and the pitfalls. Only then is it possible to decide which applications can be retired, which re-written and what is required that is new. Only then will issues about technology come clear and make sense at a time when so many vendors still seem intent on producing solutions in search of a problem.