Protecting your Greatest Assets and Limiting Risk During an OpenVMS Transition Part One: Your Development Team

Senior IT development managers often tell us there are two things at the top of their list of most valuable assets: their proprietary business logic – the smarts at the heart of their strategic business applications – and their people – developers who uniquely combine their business knowledge and expertise with technical know-how.

As IT managers around the world try to understand what HP’s 2020 support road map for OpenVMS means for their organizations, they now realize that these important assets –their business logic and technical know-how — are at risk.

If you decide to move to a new platform, what will happen to your source code and business logic that took years to perfect? Will you keep it in the same programming language?  Will you convert it to Java, or in the case of COBOL compile it to .NET at runtime?

Big Bang Transformation Gone Wrong

Many firms offer source code transformation services but the challenge is protecting a company’s investment in their technical capabilities and productivity while they transition away from legacy development platforms.

It is a common tale:  A company completes a big-bang transformation only to find that it cannot affordably maintain and operate the resulting application. The result is expensive re-staffing, maintenance of two apps and two teams or even full out project failure.

What is the root of this risk? The fact is while it’s relatively easy to convert COBOL to Java, transforming COBOL developers into capable, productive Java developers – each using a modern integrated development environment and contemporary development processes – is another story altogether.

Transforming Risk into Value

Getting Open VMS transformation wrong is expensive. Extended periods of lower productivity, costly attrition and the incalculable price tag of lost institutional knowledge are a high price to pay just to get what you already had. These risks make moving developers from one development platform to another a high-risk management challenge.

At eCube Systems, we see value in both the code and the people that write it. We fight to protect our clients from this risk by enabling them to simplify the developer’s transition.

Rather than force developers to adopt a new language, a new development process and a new development environment all at one time, eCube’s NXTware Remote platform allows organizations to introduce a modern IDE that works on their current platform with their current languages and development utilities. Managers who select a phased approach achieve the greatest flexibility and agility with the lowest amount of risk.

The Benefits of a Phased Approach

NXTware Remote allows developers to use the languages they know — COBOL, C, FORTRAN, PASCAL BASIC, DCL, etc. – on the platforms they love. This gives managers improved productivity while their developers build new skills and become comfortable in a modern IDE.

Comfortable developers, who can focus on the front-end development process, are more productive and less likely to feel threatened by change.

By modernizing the IDE and development tools, managers lower the chance of failure and simplify the move to a new platform, if and when it comes.

As a modern integrated development environment based on Eclipse that streamlines development for OpenVMS, Unix, Linux and Windows applications, NXTware Remote enables you to take your custom development environment, processes and know-how wherever it needs to go. NXTware Remote will fully support your transition while your development team works in an environment they know, with tools they are familiar with, no matter the platform.

Leave a Reply