Most Enterprise Architects are looking to migrate outdated COBOL to Java environments to lighten the burden these old systems place on innovation. Why?
Businesses are under tremendous pressure to create new value for their customers. Coupled with the enormous demand for software-based products and services, the trend of competitive differentiation through technology isn’t a huge surprise. Additionally, organizations are finding that traditional approaches to software development and delivery are not sufficient to meet these needs.
DevOps, a contraction of development and operations, represents a philosophy that drives collaboration between teams to achieve efficient, competitive, sustained innovation. DevOps is a new term emerging from the collision of two major related trends. The first was also called “agile system administration” or “agile operations”; it sprang from applying newer Agile and Lean approaches to operations work. The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development life-cycle when creating and operating a service, and how important operations has become in an increasingly service-oriented world.
Why does moving COBOL to Java Help the DevOps Push?
Mainframe code, applications, and environments have typically been in place for decades. They cause a lot of pain for the organization from a number of points of view, all of which DevOps could address:
- Rigid and difficult to access development and test systems
- Extreme sharing of environments, causing bottlenecks in development and test
- Code that is difficult to understand, difficult to establish dependencies within
- Unfamiliar or unknown build and deploy procedures
- Back level software, with no idea how to upgrade or what impact that may have
- Inability to make chances, sometimes due to inability to test
- Lack of integration/coordination with other platforms
The problem is, most of the concepts that DevOps embraces are central to object-oriented languages and concepts. Moving old COBOL to Java is a huge part of the transition.
In the end, the question isn’t ‘should DevOps be a part of my mainframe development process?’, rather ‘how can my DevOps strategy include applications on the mainframe?’
Attempting to apply DevOps to the legacy environment unchanged is a recipe for disaster. Procedural codebases, pre-relational databases, and mainframe infrastructure is incredibly immalleable. Furthermore, the talent pool that is capable of maintaining these ancient systems is shrinking at an astounding rate. Consider this from a 2013 Computerworld Survey:
Given this reality, the smartest route to take in extending DevOps to the mainframe, is to abandon the mainframe. Modern Systems offers a number of methods for extricating organizations from the confines of the mainframe, to finally make the transition from COBOL to Java.
When it boils down to it, implementing a culture of DevOps against a mainframe environment is incredibly difficult. First, the lack of a service oriented architecture and extensibility make “systems thinking” a difficult task to achieve. Second, the core concept around DevOps is to connect development with technology operations. Big Iron is notoriously expensive to extend, which makes enabling mobile access to data a risky move. When the system itself is the biggest hurdle to realizing a culture of continual experimentation and learning in the name of competitive edge, it is time to replace the system.
Even if your organization isn’t ready to rip the bandage off and convert from COBOL to Java, there are options to enable replatforming such as Modern Systems’ Application Transparency Platform (ATP), that remove the infrastructure-based constraints that stand in the way of the intimate connection between development and operations. If you are ready to get away from the legacy world, tool-assisted reeingeering software like Modern Systems’ eavRPM can help enable DevOps at much earlier stages than other alternatives.