Archive for the ‘Blog’ Category

  • June 28th, 2017

    COBOL & The Definitive State of the World’s Greatest Legacy Ecosystem

    TL;DR — see picture left, or… a career COBOL’er makes a compelling argument that legacy application systems (COBOL et al) on the IBM Mainframe are killing IT digital transformation initiatives.

    So, a heads-up… this article is going to be self-serving (at least to start with, perhaps longer), as I’ve come to the conclusion that it is necessary for me to “introduce” myself in an attempt to establish a greater level of credibility than I might otherwise be able to muster!

    I’ve been working for over 30 years. My entire career has been in the “COBOL space”, the vast majority of it working with Global 2000 companies to deliver COBOL application development & deployment platforms that were primarily focused on adding value to the IBM Mainframe (“The World’s Greatest Legacy Ecosystem”).

    I have worked at the “coal face” developing bespoke commercial COBOL applications. I have worked developing COBOL compilers and runtimes. I have led global teams of astoundingly brilliant people that have built COBOL ecosystems from scratch. Back in 2010, myself and a group of others with similar career profiles, and significantly greater areas of expertise, founded Heirloom Computing to bring a new COBOL ecosystem to market.

    Heirloom leverages open-source software stacks (primarily Java); one that immediately exposes existing business rules from mainframe workloads as a collection of Java interfaces and RESTful services so they are immediately available to other applications; one that from day 1 is absolutely guaranteed to accurately retain existing business logic, data integrity, and security profiles; one that allows application developers (using Eclipse) to continue in COBOL, or Java, or both, so IT can “iterate away” from a constrained model to an agile one, at a pace that is determined by their own unique business drivers. This approach removes the “re-platforming” risk and makes the workload instantly agile.

    We did this because we believe (and our investors and customers have validated) that IT needs to get beyond decades-old legacy systems if they are going to compete in a digital world.

    Credibility enhanced? Either way, on we go…

    The IBM Mainframe is without a doubt (and by far) “The World’s Greatest Legacy Ecosystem”. Its reliability, pervasiveness, and keeper of systems of record are unmatched. Today, however, that proud legacy is increasingly burdensome. These (crucial) systems: are severely & systemically constrained (and today, agility really matters); have paralyzed IT with a (fearful non-viable) “do nothing” strategy which consequently inhibits execution of strategic initiatives (like digital transformation) that are needed to compete. And up to this point, we’ve not even mentioned the operational expense nor the risks of an ever-aging/depleting skills pool.

    Some of these systems, especially in government, have eroded/warped to the point that paper processes have been introduced to integrate legacy workloads with new services! This is NOT a failure of DevOps, nor tooling, but a failure of leadership and the brutal reality that mainframe systems of record are inherently NOT agile because a) they were never designed that way, and b) the COBOL ecosystem itself (an archaic compute-model, a procedural language, a failure to embrace open source, a lack of application frameworks, an entrenched culture, …) is NOT agile.

    In article, after article, after article, IT leaders and analysts have clearly identified the challenge. Progressive enterprises like GE and Capital One are already working on solutions. Mainframe workloads are an essential part of any digital transformation strategy, but those workloads will persist in a different form. One that protects existing function, but also one that is seamlessly integrated with an agile ecosystem.

  • April 20th, 2017

    Moving Beyond COBOL

    Gary Crook, President & CEO

    I’ve been involved with COBOL for most of my professional career. It is a language that has many unique characteristics, not all positive. Loved by few and (unfairly) vilified by many, it has persisted because it is extremely good at what it was built for — encapsulating business rules.

    Many of you who have experience with the COBOL eco-system will appreciate the quiet reality of the absolute dependence that we all have on it as we proceed through our working day. The rest of you will likely be somewhat perplexed that anyone even uses COBOL today, and no doubt bemused by the bold assertion that your daily life without COBOL would result in unadulterated chaos. Well, despite the many predictions over recent decades of COBOL’s demise, this reality is not going to change anytime soon. That said, it would be remiss of us to not acknowledge the strategic intent of enterprise IT to convert COBOL to Java.

    For typically risk-averse enterprise IT organizations, moving beyond COBOL is a tricky proposition. These applications represent the competitive differentiation of the business. They are the operational and transactional backbones of the business. They are the definitive manifestation of “mission-critical”. The thought of rewriting or replacing the high-value trusted business processes embedded in these systems can induce violent shudders of apprehension.

    For server-side transaction processing, Java is often (if not already) the strategic platform of choice of enterprise IT – and even in the cloud, many PaaS providers have adopted Java as a supported engine (e.g. Amazon’s Elastic Beanstalk, Oracle Cloud, Google App Engine, and yes, even Microsoft’s Azure). Our take on why targeting the Java platform makes so much sense for enterprise IT, comes down to 4 key benefits:

    1. The ability to deploy and extend applications on an open/strategic platform that is proven and trusted for high-transaction workloads that demand performance, scalability, reliability, security, and manageability.

    2. Consolidation of application infrastructure to a single platform. No need to deal with multiple platforms on multiple operating systems.

    3. Strategically positions applications for the cloud. Many enterprises have already made a strategic commitment to the Java platform. It’s a smart move — Java has already established itself as the de facto execution engine for the cloud.

    4. Improves the productivity and agility of the development organization by modernizing skills, methodology, and process.

  • March 29th, 2017

    Trump, Kushner, COBOL

    Gary Crook, President & CEO

    Not 3 words you’d immediately assemble together, but that’s exactly what Senior ComputerWorld Editor, Patrick Thibodeau, did yesterday.

    His article was prompted by a White House announcement of an “Office of American Innovation” to oversee the modernization of federal IT.

    The article then goes on to give Compuware a platform to launch a somewhat bizarre defense of COBOL, as if somehow, wrapping COBOL applications up in DevOps methodologies makes them agile, and consequently, the mainframe can be seen as (according to Chris O’Malley, Compuware’s President/CEO) “… a working environment that looks exactly like Amazon (Web Services)”.

    No. It’s not. There’s no amount of makeup that you can apply to my face to make me look like Brad Pitt. Fundamentally, all the required structures for that transformation just do not exist.

    There’s much to applaud with Compuware’s mission to modernize and retool the application development lifecycle on the mainframe and impart valuable new skill sets to a workforce that has been largely isolated from considering different approaches to the art of application development. However, beyond that DevOps veneer, you are still working with a language ecosystem on the mainframe. If that’s where you want to be, go for it.

    As Shawn McCarthy, an analyst at IDC said later in the article: “… the challenge with older COBOL systems is that many were not designed to be extensible and everything that needs to be done has to rely on custom code”.

    And that’s essentially why no matter how much makeup you apply, COBOL systems on the mainframe will never be truly agile. Instead, for as long as they persist, they will continue to be an increasingly burdensome anchor that will slowly but surely impinge on an enterprise’s ability to compete.