In this updated version, we want to emphasize the user and business standpoint of our migration projects:
no disturbance for business: new system is smoothly built in parallel with the running one.
users can be migrated from old system to new one at the rythm fully chosen by the customer: people can switch from their old 3270 screen to the new UI on a browser whenever they are ready and one by one.
No training is needed as the screens are fully identical: field positions, keystrokes and inter-screen chaining
functional level identical on both old and new systems thanks to Eranea’s exact iso-functionality and 100% automation. The Java version is generated each night using the very version of Cobol source code to obtain 2 systems at exact same functional level.
Of course, the main driver is detailed and explained: huge savings (up to 90% in some favorable cases !).
Finally, we show how the development team adhere to the project: the Cobol to Java conversion is done in such a way that developers understand the structure of the new Java code very quickly is it looks as much as possible like the old Cobol code. The level of effort to adapt is minimized in order to keep productivity stable if not improve it !
On this last point, get in touch with us to obtain samples of converted code: firstname.lastname@example.org
Our NeaRuntime framework and the application Java code that we generate just require a regular Java Virtual Machine to run flawlessly. This JVM can run then on many platforms: Microsoft Windows, Linux, Solaris, AIX, zOS or zLinux IBM mainframe, AS/400 from IBM, etc. So, customers can choose whatever they need or prefer.
But, it doesn’t mean that don’t have favorites: our preference goes to Linux on x86. Let’s see why.
This video provides a lot of very interesting figures:
concerning penetration, Linux gets (positively) overwhelming : 850’000 new Androids phones running Linux activated every single day, most of the 700’000 TV sets sold every day run Linux, 8 out 10 financial trades are made on Linux, etc.
the tech stars of 2012 (Google, Facebook, Twitter, Amazon, etc.) all built their gigantic infrastructure of hundreds of thousands of servers on Linux. It was easy to bet the house on Linux as they were nimble startups. But, anyway, they did it and their scale now proves that Linux can be the right infrastructure for the largest and most stringent companies in the world !
8’500 developers coming from 800 companies have, since 2005 only, contributed patches to the 15 millions lines of Linux kernel: 10’000 of those patches are applied in every new kernel release that comes out every 2-3 months.
This figures are highly important for us:
It is not by chance that companies like Intel, IBM, Nokia and Oracle are in the Top10 contributing companies to the kernel. They can’t take the risk that they hardware devices would not run optimally with Linux: so, they contribute hardware-related optimizing patches to make sure that the kernel makes best use of all the smart architectural and technological features they include in their last servers or devices! Isn’t that a guarantee of longevity, quality and efficiency.
The efficiency and scalability is also proven from another angle: scientific calculation benchmarks. As of today, 10o% of the leading 10 machines in the Top500 ranking deliver their teraflops based on Linux: more than 10.5 teraflops for the K computer running Linux on its 705’000 Sparc cores !
Beyond all advantages above, Linux is our recommendation #1 to clients for another of its feature: it is Open Source so 100% free if you are ready to rely of a pure community version. If you don’t want to go so far, version sold and supported by companies like Redhat are really cheap compared to proprietary operating systems. It does mean that there no money to be made for Linux suppliers: Redhat recently announced that it just crossed the bar of 1 billion dollars in yearly revenue! A significant achievement, of course for Redhat but also the entire Linux / Open Source community, as noted by Jim Zemlin, executive director of Linux Fondation, on his blog.
This achievement is also very reassuring for CIOs seeking arguments to motivate their migration to Linux: it is no longer a hobbyist gadget but a real operating system supported by big and reliable companies!
Anyway, a Linux distribution like Redhat is valued well over 10 billions dollars in R&D costs. So, sound business managers by IT suppliers will from now on bet strong on it for decades: such a jewel cannot be found every day as a part of our collective (free) commons !
The x86 choice
The second part of our recommendation for customers willing to transcode their Cobol application to Java via our technology and looking for the most optimal hardware platform is the x86 architecture (either by Intel or AMD, it doesn’t matter.
This is motivated by:
worldwide server shipments: the x86 architectures dominates heavily with over 2/3 in revenue share and much more in machine shares (because x86 machines are always cheap compared to high-end proprietary servers)
By the way, we consider those 2 benchmarks best representative for workloads like those we obtain when we convert administrative business applications from Cobol to Java. They allow customers to obtain public figures on machines / architectures that come to their mind when they plan their migration.
To sum up, our architectural recommendation is to select the path of horizontal growth by progressively building a cluster of “regular” (i.e not equipped with fancy hardware) x86 powered by Linux.
Scalability and reliability are simple and easy to achieve: Linux is packed with features providing redundancy, fail-over, load balancing, etc. to such a growing and mission-critical cluster !
GWT has a ton of other advantages for us: we’ll write again about that soon.
The point of this post is that GWT is a great facilitator of our tactics to achieve “migrations by (tons of) little steps”: we are deeply convinced (by – past & painful – experience) that executing small things one after the other is at the end of day more efficient and safer than trying the method of progressing by quantum leaps: this “Big Bang” approach most often fails. Those leaps have often to been reverted and tried again (until users get fed up…) because of unexpected damaging consequences while small steps produce permanent recurring improvement at a very low risk level.
Google Web Toolkit efficiently supports this progressive approach:
its remote communication protocol (see page RPC) allows us to transport into some cache within the browser the data objects coming from business processing. We store them in a form neutral to the presentation format to be selected.
the sophisticated graphical widgets supplied by GWT can then be combined with those that we produce for our specific needs to achieve a data presentation totally independent of processing done by the central server. Over time, the use of different widgets and widget combination (as well as their CSS styling) allows the look and feel to vary massively over time without any change on the server side.
The look-and-feel that we recommend to start with is the one presented below: for that purpose, we have developed a widget to reproduce as exactly as possible the original presentation of the data as it used to be on the mainframe via its character-oriented protocol (3270, 5250). The rendering in Internet Explorer (but also in Firefox or Google Chrome) produce the following outlook : text fields on a black background with a limited set of colors and other video attributes.
We push the similarity up to the emulation of all the function keys found and heavily used on a mainframe application keyboard: we want users to be able to do on the transcoded application exactly what they were doing on the legacy Cobol version.
This look-and-feel often surprises / shocks the gurus of web interfaces and rich presentation technologies. But, we clearly use this structure on purpose: it allows a very smooth and cheap migration of the end users to the new system. The transition task is limited to informing them about the URL on the corporate intranet of the newly converted application. And that’s done !
End users then open their browser instead of their character-oriented emulator and they are ready to work. They find on those web pages the application that they know for ages:
position and format of data fields are strictly preserved.
use of keyboard keys is fully identical.
chaining between screens did not suffer any change.
This strategy has a double advantage: no training costs and no loss in productivity by end users. They clearly appreciate !
Of course, this legacy-like interface is just the first step to bring all users on board quickly and efficiently. Afterwards, we apply the well-known Open Source strategy « release early, release often » in order to improve this starting point by successive and frequent introduction of interface changes.
Those small improvements are very easily digested by end user: the beauty of “small steps”. A simple mail to explain what is rolled out is enough: no training. Finally, the high frequency of changes results in a high speed of evolution which permits to catch up with today’s standards: We finally achieve a UI that is state-of-the-art for RIA and Ajax interfaces. All of today’s standard stuff is eventually incorporated: predictive input, buttons, check boxes, scrolling lists, etc…
Original goal of the transcoding is achieved: legacy application has been fully modernized and mutated to best technologies (Linux & Java). But, this migration with massive added value was delivered smoothly and with no risk from a starting point mastered by every employee of the corporation: the legacy “black screen” initially produced by the mainframe.