Hi, my name is Mario Mees, and I work here at Anubex. We are modernization specialists migrating mainframe applications to the cloud.
When people consider the future of their legacy mainframe applications, they basically have three choices. Two of these, the obvious ones, have already received a lot of attention in the past:
The first choice is implementing new applications.
· Either via redevelopment, custom coding:
o be it from scratch,
o or based on re-engineered specifications,
· or via the implementation of a package solution
Gartner calls this approach rebuild and replace;
The second choice is staying as close as possible to the current solution. This can be done:
· either via encapsulation or
· via a lift-and- shift of the mainframe environment towards an X86 architecture.
o This last one can be done without recompiling,
o or with making minimal changes.
Gartner calls this reuse, rehost and re-platform respectively in their taxonomy. It has become clear recently that in many cases both of these approaches do not offer the right solutions.
The first group of solutions - rebuild and replace - can of course offer an attractive promise, only … the horror stories about painful failures of the past thirty years have prompted most companies to consider their options carefully before embarking on this risky path and to look for more manageable solutions.
If selected anyway, it will take years, sometimes decades to complete them. This exercise will probably not only be
· too costly and
· too risky to execute,
· but it will also be way too late.
So – when do you want to consider rebuild or replace: only do it if two conditions are fulfilled:
1) you have enough time and budget, and maybe even should double the original estimates of your specialists,
2) your legacy applications do have a big deficit in supporting the business needs
Now let’s have a look at the second group of solutions - staying as close as possible to the current solution.
Since there is a huge upcoming skill issue, these solutions simply are not good enough since, well … they do not offer a solution after all: the technologies used remain the same! COBOL stays COBOL, and JCL will still be JCL. With a whole generation of architects, DBA’s, developers, and operations people about to retire, this is not how any organization wants to move into the challenging business environment ahead of us!
So – when do you want to use the second group of solutions? The answer is: only if one condition is fulfilled:
1) you still have the knowledge / skills for the foreseeable future, say at least 10 years.
Because, if you want to buy time, and if you are looking for a quick solution, there is a better alternative
Fortunately, there is this third possibility:
· you can migrate your mainframe assets to the cloud and
· at the same time transform them into the latest technologies: replace Assembler, Natural, COBOL, etc. with C# or Java, and JCL by a modern scripting language.
You want to consider this if:
1) your applications still have value out of a business point of view, and
2) you are looking for a fast solution that solves are your legacy skills issues, and you are ready to get rid of your old languages.
This is called refactoring and rearchitecting by Gartner.
There are a number of vendors out there with great technologies, great solutions and good references, and luckily mainframe users start to find them and embrace the solution! Check it out for yourself and start at www.anubex.com or contact us!
