Get rid of Pacbase (and CASE tools) #1

First of all, the views expressed here are mine and do not necessarily reflect the views of my past, current and future employers.

Situation:
A Company uses a CASE tool (Computer Aided Software Environment) to develop and maintain part of its application portfolio. For some reasons, the company wants to get rid of this CASE tool. One reason may be that the CASE tool’s software publisher wants to stop maintaining it, but there are many other possible reasons.

Whatever the reason, and provided that the application developed using the CASE tool will still live in the future, the Company has to choose a new technology target (or several) and a way to move towards it. Let’s investigate the strategy to choose the target.

#1: Sustainability strategy

If sustainability is part of the key points to take into consideration, the idea is, at least, not to reproduce the current situation in the future. Choosing a new CASE tool that eventually will fall into the same kind of dead-end than the current CASE tool is for sure a weird idea (but live is sometimes weird and business too….).

May we choose not to choose a CASE tool?
One of the first ideas when thinking about a target may be: how about finding a target CASE tool that reproduce what we are used to with the current one (so that change management should be minimalized) but have a more promising future?
Whatever the programming technology, we use tools. And for sure we use, and will use more and more, Software Environments. However we can make a clear difference between a “CASE tool” and an “Application Life-cycle Management” (ALM) tool:
– a CASE tool (historically) offers a way to model some information and to generate “terminal” source code from these models, the generated code being generally not easily readable by a programmer
– an ALM tool, or set of tools, helps to manage the development workflow and holds software development assets (such as code) in an organized way.
The main, and big, difference between them is that we can get rid of an ALM tool without loosing precious information as the source code and other development assets have been made by humans and are still there, readable. This is not true with a CASE tool as some parts of information are held in black-boxes: unpublished code generator, hidden repository data structures…

An alternative to historical CASE tools is to use a more open Model-Driven Development (MDD/MDA) set of tools including a modeler, modeling rules and a code generator engine. This leads, more or less, the Company to build its own CASE tool. Regardless the pro and cons of such a choice (e.g. see MDE shuffled again), this choice may hardly be done without considering the whole application portfolio rather than solely its part tied to the initial CASE tool.

In the end, the sustainability strategy leads either to move towards a technology in the development technologies portfolio yet, or to add a new technology to this portfolio and to move towards it.
Adding a new technology in the development technologies portfolio, when every companies tend today to cut this portfolio, requires for sure strong reasons. Undoubtedly finding a target for the abandoned CASE tool technology will not be a sufficient reason by itself, and replacing the dying CASE tool by an equivalent CASE tool is not a good idea at all…
… for the sustainability perspective. But there may be other important perspectives! It will be the subject of other posts.

Sustainability: the Pacbase case

Let’s analyze the Pacbase case under the sustainability perspective. I took Pacbase to illustrate the CASE tools modernization question cause it’s a current question and I know a bit of it. It could have been another CASE tool: it does not change much the arguments.

Pacbase is a CASE tool initially developed by a French company to top COBOL development with a CASE solution. Pacbase has then be bought by IBM and is now part of the Rational solutions portfolio. Pacbase is mainly (but not exclusively) used by some big french companies, which made this choice a long time ago. Even if the product is good and its design not so far from some of the best MDA/MDD recognized principles, presumably nobody will adopt it tomorrow cause it’s an old CASE.
From a business perspective, the revenue for this product is now only made of maintenance fees and can only decrease in time as customers will switch to other technologies. Why do customer will switch? Because Pacbase practicers and experts tend to retire (they are as old as te technology). Similarly, Rational’s Pacbase experts tend also to retire. So the product is promised to increasing maintenance costs and decreasing maintenance revenues. Do you need a picture? ;D
In a way, IBM also needs sustainable products in term of revenues/costs.

So, IBM announced the end of Pacbase maintenance in the next years. And proposed… nothing clearly as a replacement! Let’s describe roughly the technology core target solutions as I understand them:
a – EGL: a new language/CASE tool. A brand new one!
b – Rational Programming Pattern (RPP): a new CASE tool which reproduces Pacbase design/generation mode inside a COBOL development environment

How to understand IBM’s solutions to get rid of Pacbase? How does it fit to the Company sustainability strategy?

IBM/Rational business problem
The goal here is to make money with software solutions. It’s Rational business: no surprises here.

The first idea (the “a” solution) is then probably to merge several dying captive markets into a new bigger and dynamic one. Pacbase’s customers is one of these markets, but there are other ones (ex: VisualAge series users). One idea behind EGL is probably: let’s offer an up to date CASE tool which brings business oriented design facilities and high productivity for the technical development side. Not a bad idea from a theoretical business viewpoint, but a hard to sell one from market adoption and vendor dependency ones… Not even to mention the modernization path from old CASE tools application portfolio towards a brand new technology !!!

The second idea (the “b” solution) is probably focused on the other end of the problem: how to lower the Pacbase disengagement costs? That means, from business side, how not to offer customers an opportunity to think about their dependency to IBM’s solutions in offering a smooth transition from Pacbase to other IBM’s development technologies? There are three keys here:
– COBOL: as Pacbase generates COBOL, the solution must target COBOL and IBM’s COBOL well-known development tools
– Change management: Pacbase’s developers are used to Pacbase’s facilities such as data dictionary, macros, etc. The idea here is to give equal facilities into a COBOL environment
– Remove the necessity to do massive Non Regression Test after the migration processing by providing in the end exactly the same COBOL code as obtained from Pacbase
This plan sounds better than EGL for customers but… What is the gain for IBM to replace Pacbase by a Pacbase-like CASE tool? And where is the sustainability aim?
And I even don’t mention the technicals problems cause that is not in the perspective I choose here…

Company’s problem
The Company has a Pacbase team, big or small, and Pacbase programs, some or a whole bunch. Programs have to be maintained, frequently or not, in an IT ecosystem that goes away from Pacbase technology each day a bit further. And Pacbase developers have to be replaced as they retire one after another, and tend to become more and more expensive. Even if the technology itself gives full satisfaction, the Pacbase stream is less and less sustainable… IBM’s Pacbase retirement announcement may just be seen as a booster for that trend.

Are IBM’s alternatives to Pacbase solutions to be taken into account? At what conditions?
Well…
EGL sounds like: how about to redevelop your IS with a fantastic new tool? It can be seen as a marvelous perspective, or not. But it’s a “forget and build from scratch” modernization path. A fun path, but not really a smooth one…
RPP sounds like: it has the color of Pacbase, the smell of Pacbase but it’s not Pacbase. So what? Won’t we at least have the pleasure to drink until just before being drunk? And what is the point of maintaining Pacbase-like practices limited to Pacbase practicers that will retire soon or sooner? And by the way, why IBM would maintain RPP if they don’t want to maintain Pacbase ? Wouldn’t it be easier to keep on going with Pacbase?
Not very convincing.

Let’s go back to the sustainability generic consideration: the Company should probably either move from Pacbase towards an already acquired and mastered development channel, either take the opportunity to build a new development channel with a new technology or a new way to work with an existing technology.
The first option leads to move towards COBOL and COBOL current Company’s practices (shortest move) or towards Java (hardest one).
The second option leads to adopt EGL: a very high level challenge!, or to adopt RPP provided that this embedded CASE tool may be used to also boost “non Pacbase” COBOL development, and possibly other technologies (notably Java), productivity: a very good challenge also!

My opinion: as far as sustainability is a goal, for Pacbase the move to COBOL is the best one.

Featured image taken from: http://www.uponor.fr/a-propos-d-uponor/uponor-comme-partenaire/sustainability.aspx