What’s blocking digital transformation?
by John Browne, on May 27, 2020 3:30:00 AM
We don’t have to look very hard to see that with each successive wave in the growth of computing, organizations that quickly and correctly embraced each new wave gained enduring competitive advantage over technology late-adopters.
The fourth wave is no different.
The ability of institutions to fully adopt digital transformation could very well be an existential issue. Those who fail to quickly and appropriately embrace DX may not be around much longer, either shuttered or snapped up at fire-sale prices by more fast-moving competitors.
IT in the enterprise has long held many of the keys to the future, and the governance of IT in how and where to deploy its limited resources has spelled the difference between success and failure in many organizations.
Sadly, the ability of most IT organizations to accurately predict the resources, time, and risk of new endeavors is poor. Over lunch recently, one CIO of a significant organization ($200M annual IT budget) recounted how a rewrite of a small legacy business application was estimated at $300K but in the end cost $1.2M, a 400 percent cost overrun. The literature is filled with similar accounts of both major and minor IT development projects which routinely miss delivery deadlines, fail to satisfy user requirements, and blow budgets to pieces.
Legacy code blocks digital transformation
Every significant organization—private and public—has bespoke legacy applications that provide vital capabilities. These applications are so valuable that they are constantly updated and maintained, even when that means retaining in-house expertise in obsolete programming languages and platforms like Visual Basic 6 or PowerBuilder. In fact, legacy client-server applications represent in total the largest single legacy problem that organizations face.
And those legacy apps are blocking digital transformation.
Client-server apps are captive to the desktop. As such, they block agility. CI/CD and DevOps allow not only for authentic Agile software development practices, but also for agility in the organization as well. And enterprise agility is a key goal of DX.
- Legacy client-server apps are written in old or obsolete languages like VB6 and PowerBuilder. Finding and keeping developers who can or will work on those kinds of workloads is increasingly difficult as older developers age out of the workforce. Those that remain cost more each year since supply is dwindling while demand remains high.
- Client-server apps require complex installation programs and exten- sive configuration testing to avoid “DLL hell.” Deployment can be so expensive for apps with large user bases that organizations might limit updates to only once or twice a year, meaning a bug can be present in an application for months before a fix can be rolled out.
- Desktop apps have no ability to be mobile except through clunky, ex- pensive screen sharing/terminal server type remote access scenarios. As users embrace “bring your own device (BYOD),” the limitations on access to critical apps further attacks agility and productivity.
- Feedback loops for client-server apps are difficult to implement and can’t provide timely data. Typically, a company will ar- range for surveys or focus groups of users, compiling weeks of data for the product team to incorporate into a future release of the code, months or even years in the future.
We’ll discuss later how true digital transformation addresses all these limitations.
Legacy systems provide significant obstacles, challenges and even business risks for midsize enterprises that are striving for a digital business. (Mid-sided enterprise) CIOs must fund legacy modernization to support digital initiatives and mitigate the risk of failure.”
How Midsize Enterprise CIOs Fund Legacy, Gartner Jan. 2020
Legacy code creates risk of attack
Legacy systems not only block DX, but they expose the organization to cyberattacks.
Cybercrime is a relatively recent phenomenon. The explosion of programming languages, operating systems, and application frameworks in the 80s and 90s was driven by the need to build efficient software quickly. Languages like C were focused on execution performance, not security. Before the internet, cybercrime was usually an inside affair, and prevention was more concerned with access and privileges than actual application or network security.
The internet is an amazing system, bringing knowledge, entertainment, and help to people all over the world. Sometimes it’s hard to remember what life was like in the pre-internet era.
But by connecting millions of computers together, the internet also opened a doorway for bad actors. Cyber criminals don’t need to break into your data center to hack your computers—those computers are reachable from anywhere in the world as long as they have a connection to the internet.
It’s convenient to be able to connect to one’s bank from a laptop or smartphone, but that connection needs to be extremely clever to secure the connection to the intended customer. Today, as software engineers set out to write applications, the security of those applications is—or should be—uppermost in their minds. But that awareness is a recent development. Applications designed, written, and deployed in the pre-internet days were not constructed with an eye to preventing SQL injection attacks, buffer overloads, or phishing attempts. Equifax lost billions of dollars in shareholder value because of obvious security holes like using admin/admin for a login/password combination, storing user passwords in plain text, not requiring users to change initial access PINs, and more.
All those applications were legacy applications. Frequent security issues with legacy applications include:
As current and patched operating systems are foundational to secure information environments, running a legacy operating system is an ill-advised practice. Operating systems that have been unsupported for five, ten or more years (decades in some cases) greatly increases a healthcare organization’s risk of being compromised. This is particularly significant in light of recent international cyber-attacks such as WannaCry and NotPetya. Based upon these findings, healthcare organizations may still be vulnerable to future attack using the same or similar exploits.”
2019 HIMSS Cybersecurity Survey, Healthcare Information andManagement Systems Society, 2019
- Weak user privileges, weak authentication methods and policies, and authentication tokens discoverable in network traffic or de-compiled source code
- Web interfaces that are publicly exposed (not hardened)
- Use of un-encrypted HTTP sessions
- Passing un-validated user data as SQL strings, enabling SQL injection attacks
- Using source languages and platforms that are unsupported, obsolete, out of support and that have known vulnerabilities open to attack (source: How Midsize Enterprise CIOs Fund Legacy Modernization, Gartner, Jan 2020)
Why lift and shift won’t get it done
As little as 10 years ago the Enterprise was skeptical of the cloud, especially public cloud offerings like AWS or Azure. Today, that’s all changed and organizations across all industries and sizes are racing to move into the cloud, taking advantage of Platform as a Service (PaaS) and Infrastructure as a Serviced (IaaS).
What happens when the C-suite tells the Infrastructure and Operations (I&O) team to “move everything to cloud this fiscal year”? As private data center hardware ages out, the pressure to move away from that traditional model to a public cloud is significant. The usual response falls into three uses cases (Evolve Your Infrastructure and Operations Organization to Remain Relevant in the Cloud Era Gartner, Feb. 2020):
- “Lift and shift” by taking monolithic applications and hosting them in a virtual environment in the cloud. This approach “gets to the cloud” with the least disruption to existing applications. However, increasingly organizations are reporting that this approach failed to meet expectations for effectiveness, user experience, and ROI. It further delays addressing the issue of obsolete underlying technology—the application can run in a virtual environment, but that does nothing to assist the team charged with maintaining and fixing the source code.
- Independent software vendors (ISVs) are moving from license-only, fixed install models to SaaS subscription models. Horizontal-market vendors like Adobe and Microsoft have already made that transition (Adobe Creative Cloud and Office 365) but increasingly vertical-market vendors are finding themselves at a disadvantage compared to newer entries who enter the market already as a SaaS offering. I&O teams shifting their user base from captive desktop commercial off the shelf (COTS) software to SaaS further move toward the “all in the cloud” directive.
Finally, “lift and shift” does nothing to unblock digital transformation. Although it moves some desktop assets to a cloud environment, the underlying application code and runtime platform is unchanged. A cornerstone of DX is system integration via web services, i.e. APIs.
Moving critical applications off legacy programming languages and platforms to cloud native architecture makes opening those applications to the API ecosystem fairly simple: leaving them in a lift and shift environment does not.
Next: How legacy applications block digital transformation and what to do about it.