Keep an eye on legacy apps, COBOL’s not dead!

Third-generation programming languages (3GL) like COBOL or PL/1 are seen as outdated languages for “has-been” developers, and do not interest new ones anymore (there were even predictions saying that COBOL was going to die in mid-term.) These new developers prefer more modern technologies, like J2EE or .NET, and, worryingly, educational organizations provide few learning opportunities for 3GLs.

Don’t Blame the Outsourcer

In my travels, I run into a lot of organizations that are not happy with the performance of their outsourcer. In many cases, the core relationship is the result of a cascade effect. The organization delivered an application that had poor structural quality to begin with, and left the outsourcer with the difficult task of meeting their SLA requirements with a faulty application.
If you want great results from an outsourcer, here’s job one: make sure the application you’re delivering is structurally sound to begin with. Step two: make sure the tools and technologies you use to ensure structural integrity are also part of the outsourcing agreement and, in the end, KPIs in the SLA.
Organizations are expecting a certain level of satisfaction from their outsourcer, and it’s a lot higher than it was in the past. They want cost reduction, without exposure to risk, and they want fast time to market while still remaining flexible. You cannot get all that simply by accelerating your outsourcing contract, because there are a number of risks associated with poor outsourced delivery.
When an organization first approaches outsourcing, they tend to focus more on legacy applications — the ones that they don’t care so much about — to reduce costs. Most organizations have gone through this phase already. When they get more mature, they tend to think more strategic. They think benefits, freeing up resources, concentrating on their business, and finally, getting access to innovation.
They’re typically careful with defining the service level agreements. However, software developers are very uncomfortable with a white line in the contract that specifies the behavior of the software they receive in production. Yet, some still believe that they can go live with the expected results based on some sort of contractual relationship through service level agreements. They don’t have to worry about how it’s done. They just have to worry about the service they get.
This conception, which is still prevalent in a number of shops, might have been true when you only outsourced legacy applications that don’t move much. But it’s absolutely wrong in the kind of outsourcing we do today for fast-moving applications that are important to the business. You simply can’t focus only on cost reduction and rely on operational SLAs. This is why it’s important to know what you have inside the box, even when you hand over the keys to a vendor.
Often when an organization outsources, they continue to rely on testing, but they no longer have control over the product itself. They lose architectural oversight. They don’t see the evolving structure of the software, the technical debt, or the structural software risks which they might have tacitly managed when the software was in house. When they don’t measure the structural quality of the product they’re sending out, they’re exposed to a number of dangers and, while it’s all too easy to point the finger at the vendor, it’s a deeper problem than that.
Structural quality drives 30% of major production defects. And one could argue that more than 50% of all defects are originated in structural quality (if you look at the root cause analysis). Beyond the focus on functionality you get with testing, recent news has certainly showed us that we need to keep a vigilant eye on resilience, performance, and security risk.
By the time such risks materialize, the business impact is often much more than the contractual penalty to the vendor. That penalty may not even be fair, because it could have been a structural flaw in the software to begin with. Unfortunately, most ADM SLAs are based on reactive approaches to managing technical acceptance, rather than a proactive management of the risk. And the business suffers the impact.
If the vendor is getting a badly-constructed application to begin with, their hands are tied. They probably analyzed the help desk tickets or did some code reviews on a spot basis to see what they are taking over, but most of the time there is a fair amount of guesswork. This is an unfair process towards the vendor and the outsourcing relationship.
You can see in one of our recent surveys that almost 70% of the respondents terminated an outsourcing contract because of lack of quality of service. Some of those contracts could have been terminated for the wrong reasons, because it was the application itself that was at fault for poor performance. So the next time your organization thinks about outsourcing, first ask yourself: Am I delivering a structurally sound application to my outsourcer?