Legacy, a reassessment - Legacy applications may be generating the profits that are paying for your innovation

I always get a bit irritated whenever I hear someone talking disparagingly about legacy technology, often in a Mainframe context. If I hear that a long lost uncle has left me a legacy, I usually feel good. In the case of legacy technology, this is the stuff that has been underwriting the organisation’s profits for the last few decades. Sure, you might write it differently if you wrote it today, but it has a demonstrable and proven ROI – if you are still in business. The agile, mobile, bang-up-to-date app which is going to replace it, has delivered virtually no ROI yet and won’t until it has been in use long enough to recoup the cost of development.

In the meantime, if you despise your legacy systems and the people working on them, these people might leave and the systems become unmaintainable – and unmaintained. Then your customers may desert you – and the resulting bad publicity may discourage the potential customers for your innovative replacement systems. At the beginning, at least, probably either your profitable legacy customers are paying for your innovation, or you’ll be dependent on venture capitalist investment. Or, perhaps you are selling stuff off, to get money in the bank for innovation. Whatever, profitable legacy systems with loyal customers are not to be sneezed at.

I’m really, really not against innovation. But, contrary to what some innovators tell you, innovation isn’t an automatic, safe and immediate path to success. Innovation is risky but its returns often justify the risk many times over. Innovation is all about exploiting risk (which is good – risk brings profit) but something has to pay the wages of the innovators, the cost of migration to the innovative systems, and maintain customer service levels (profits) and customer loyalty while all this innovation is bedding in and starting to deliver ROI. That something is often, as I’ve already suggested, legacy systems. Don’t knock them, they’ve delivered proven ROI for the business.

That said, although there is a risk with innovation, there’s also a risk in standing still. There’s a huge pressure towards the status quo – familiarity, known behaviour, current expertise, proven track record etc. So, a little balancing positive discrimination in favour of innovation is probably justified, even though I don’t think that anyone should rip out legacy as soon as they can and rush headlong into new, untried systems and markets. Unless, that is, a change in the business environment makes this inevitable. Even if it does, a new start-up may be best placed to exploit the innovation opportunity early on, while an established player consolidates its profits from its legacy customers and plans its move to innovation in stages. It may still be around (if it has good management and a strategic vision) to pick up innovative intellectual property when an innovative start-up has crashed and burned from cash-flow problems.

Nevertheless, the big risk facing the big established company with successful legacy systems or tools is probably complacency in the face of innovation; whereas unrealistic optimism may be the risk factor for the innovator.

I was thinking about all this when I reported Compuware’s view that CA Technologies CA Endevor Software Change Manager product on the mainframe represented a legacy that couldn’t cope with Agile development (which I take to include DevOps, continuous delivery pipelines etc).

OK, there may be some especial rivalry between CA Technologies and Compuware (Compuware’s CEO used to run the mainframe business unit at CA Technologies, I believe – perhaps if you like what he said in his days at CA Technologies, as I did, you’ll like his messaging at Compuware too), but Compuware’s ISPW (part of its Topaz product) does look like an innovative and agile software change management product to me – and, most importantly, it seems to integrate mainframe and distributed systems development and supports visualisation of changes well; although, it perhaps doesn’t yet have the proven track record of CA Endevor SCM, nor its huge (and active) user community.

But, can Endevor SCM balance support for historic Waterfall approaches to development with support for modern Agile approaches too, as CA Technologies tells me that it can? Well, remember that Royce’s original Waterfall paper described an iterative process (of mini-Waterfalls), which is what most successful uses of Waterfall actually do, instead of the failing “Aunt Sally” put up by Agile enthusiasts when promoting Agile. And, Agile is about “individuals and interactions over processes and tools“, remember (the right people can make most tools effective for Agile), so I suspect that the claims of CA Technologies can be justified.

CA Endevor SCM has been developed and delivered with an Agile (incremental) approach since Version 16. Its development team uses CA Endevor SCM itself and, since Version 18, it now supports continuous delivery of the product too. True, the development team may not have much choice of whether to “drink its own champagne”, but this does seem to confirm that CA Endevor SCM can cope well with Agile approaches – as well as supporting older ways of working, and an existing customer-base.

Even an Agile SCM tool has to, I think, integrate with the big picture of Configuration Management generally. I was recently talking to an ITIL specialist from CA Technologies, Services Architect Armin Lengauer, who pointed me at “CA CMDB Connector for z/OS version 2.0“, which includes a new discovery method focused on “on in-depth discovery of CA Endevor Software Change Manager Elements and their relationship to customer defined Endevor Types”. This integrates CA Endevor SCM with Configuration Management, one of the foundations of Agile, in my book, because how can you deliver rapidly to the business if you don’t know what you have and how it relates to the business?

Does this all mean that CA Endevor, and Compuware ISPW (and, probably, any actively maintained, modern tool) are now all essentially “Agile” tools? That is the wrong question, I think – “Agile” is a mindset thing and a human culture thing, not something you can achieve just by buying a tool. What you must do is decide what “Agile” means to you, in terms of changing process in order to deliver more value to the line-of-business in what Bloor calls “the Mutable Business” (a business in a constant state of change, in response to changes in its environment). Then, you can choose tools that will actually support the changes you need to make.

What I do think is that CA Endevor SCM is more likely to support Agile and other innovations going forwards if it has an active rival (such as Compuware ISPW), with a strong story in this area, to compete with. Compuware ISPW also has the advantage of starting comparatively recently (if you take the Compuware acquisition as the starting point), and a newcomer has the advantage of knowledge of any issues CA Endevor SCM has and, with fewer initial customers, the option of “cherry-picking” forward-looking customers for its Agile solutions; and it can perhaps also afford to avoid customers with serious legacy software installations and older approaches to manage. This is the “digital disrupter” story, where a newcomer can take a market away from a seemingly secure incumbent.

On the other hand, the newcomer hasn’t got the provenance of a market-leading incumbent and may not have met unusual situations that the incumbent has evolved solutions for. More important still, is the relative quality of the support and consultancy available for each product – the product with an established leading market share has more experienced human resources available and probably a more active user community. We tend to remember the “digital disruptors” that succeeded rather than the ones that didn’t.

CA Endevor SCM is still being enhanced, and CA Technologies is well-aware of Agile, as should be evidenced by its acquisition of Rally Software in 2015, so I expect it is being made Agile enough for its users. A CA Technologies spokesperson suggested to me that many of its existing customers in effect started their journey to Agile, without realising it, when they started to isolate work areas and adopt continuous delivery processes and began to tie changes to user stories and backlogs.

Nevertheless, I haven’t looked at either the CA Technologies or Compuware software change management tools in enough detail to say which is “best”. I suspect it depends on who is using them, and what their specific needs are; but I do believe that tool competition is good and that it promotes useful innovation (rather than innovation for its own sake). This means that I welcome the resurgence of Compuware and its ISPW acquisition (as well as the enhancements to CA Endevor SCM). partly because the Mainframe world, in particular, needs more competition and Mainframe customers need more choices.

I do hope, however, that neither Compuware ISPW nor CA Endevor SCM are ever the only game in town. And I also hope that users of both products recognise the value in their legacy systems and technology and the ability of their tools to support this legacy.