Exclusive Interview with  Dr. Cyrus Montakab   Founder & CEO   SoftwareMining   "I setup SoftwareMining to address the need for COBOL legacy transformation. However, during its existence we have engaged in a lot of work in COBOL and Java architecture and design, in addition to migrations."

SoftwareMining is a leading supplier of tools and services for rapid modernization of legacy COBOL applications.  It provides a proven, cost effective route for quick and risk-free migration.  Softwaremining unlocks the value in legacy systems by transforming them into Java/JSP and C#/.NET through a unique, heuristics driven, semi-automated process developed by Dr Cyrus Montakab. With SoftwareMining you will be able to migrate your COBOL applications to maintainable J2EE compliant Java or .NET C# within 1 year.

SoftwareMining's tools and expertise permit and facilitate:

    ►  change of application architecture from COBOL to easily maintainable and strategic Java or C#

    ►  automatic generation of legible, 'future-proof' applications ideally suited for SOA-centric solutions

    ►  automated, heuristic [i.e. AI technology-based] application clean-up; i.e. removal of dead code

    ►  automated and dynamic re-documentation

    ►  automated extraction of business processes and rules for reuse in other applications per SOA principles

The platforms already supported by Softwaremining include: CICS, IMS, IDMS, ESQL, HP e3000, DEC VAX, ICOBOL, MicroFocus, AccuCOBOL, WANG, STRATUS, SHADOW, BULL, UNISYS, FUJITSU, HITACHI and TANDOM.

SoftwareMining was founded in 1993 by Dr. Montakab, an experienced software engineer. Dr. Montakab is a specialist in Artificial Intelligence (AI) and SoftwareMining's tools were developed originally from a project of Dr. Montakab's, using his knowledge of AI to create CORECT (COBOL Reverse Engineering Translation Tool). CORECT was created to translate COBOL into 4GL, then Visual Basic, and more recently into Delphi and Java - which it generates as an Applet or Application.

By 1999 CORECT was able to generate Java code for HTML/Servlet architecture and in 2000 additional development resources were brought in to handle J2EE and XML as well as produce flowcharts and documentation from the source COBOL code, thus offering the market a uniquely valuable, affordable and commercially risk-free alternative to the byte-code translators available from competitor organizations.

SoftwareMining now produces commercial transformation tools and offers a total transformation service package through strategic partnerships with companies that support and enhance CORECT, and provide migration services on four continents. SoftwareMining also provides architecture design and programming consultancy in e-commerce, migration and transformation to global companies such as Deutsche Bank, Sema Group, and SwissRe Insurance. SoftwareMining is a registered technology partner of IBM, Borland and Sun Microsystems, as well as an active member of OMG Legacy Transformation Work Group.

Dr. Cyrus Montakab, gives us an exclusive, in-depth look at what is possible with SoftwareMinning's technology and services in this interview with Anura Guruge, IT In-Depth's editor at large.

Q1: Cyrus, to cut to the chase, and also to grab the our readers attention, is there a SOA-related play you can have by using your tools to create Java- or NET-based services from COBOL routines?

A1: Absolutely!

      We are currently working with a client which wants SOA.

Basically, any COBOL batch program can be easily turned into SOA.

Much of the original code typically focuses on Business Logic.

Therefore the translated code is basically Business-Logic oriented: How an invoice is calcalated or how an order is processed.

The translated code Java code - sits on top of a Framework which controls the application 'plumbing'.

The plumbing controls various non-business related activities such as Database Access (JDBC or via EJB), Screens JSP, XML or AWT, deployment: Tomcat, WebSphere or WebLogic, or Java Application .. One . of the features of the framework is how the programs communicate with each other: Is it native Java, EJB Invocation, RMI or SOA.

So, provided that the translated code can act like a Service (take an input, process it and return an out-put without any user interaction) - then we can turn that piece of code into a SOA.

Q2: Cyrus, are there any practical limits as to the size [e.g. number of COBOL statements] of COBOL application that can be converted with your technology

A2: The translation of 'business logic' part of a COBOL program results in a Java or C# program of similar size.

So - the real limitation are the one dictated by the target language.  A 50K Lines of Code (LOC) Cobol program is big - but acceptable.

A 50K LOC program in Java is not too desirable - as it may cause memory and performance problems.

We offer 2 means of breaking down large programs:

The first method is by identifying the unrelated areas of code - and then breaking down the program at these points.

The second method is by Business Rule Extraction (BR). The BRE module is based on providing Data and Statement-Type filter criteria. Most programs do a variety of tasks. For example, a Order-Processing program may calculate invoice, update inventory records, have data-entry screens, and etc.

The BRE allows extraction of related code using 'data' and 'statement-types' filters! For example, it can be asked to show "ONLY non-screen-handling, and non-file/db-handling statements which are involved in handling INVOICE record". this will lead to a section of program ONLY showing how the value of invoice is actually calculated

Each large programs can undergo many BRE cycles - breaking the program into smaller - more logical units.

Q3: Cyrus, are there any platform-related limitations when it comes to the conversions [e.g. I/O, services etc.], and if not, can you take a mainframe COBOL program and convert it so that I can run it on a Windows 2003 server?

A3: Typically each COBOL platform uses its own set of libraries; e.g. IBM CICS and IMS, HP TurboImage and VPLUS, Unisys DMS-II etc.

Most of the time there each of the library calls have a good equivalent in Java.  We have needed to develop our own support libraries for these for the following reason.  A single CICS API may be translated into several lines of Java code. We don't want to insert these 'several lines of Java code' into the actual business logic.  That is a bad practice. Instead, we have moved these lines into our own set of libraries. The translated business-logic will just reference the API in these libraries. Currently we have libraries for CICS, IMS, UNISYS DMS-II, BULL, IBM Shadow and HP.

To-date, we haven't come across anything that we have not been able to handle when it comes to migration.

Q4: Cyrus, I see that you also talk about “outsourcing”.  How does this work and given that in the U.S. IT outsourcing is indelibly associated with India, do you also use resources from India?

A4: Currently our outsourcing arm is based in St. Petersburg, Russia.  But we are also discussing the possibility of working with selected Indian outsourcing companies. This will give us a bigger expansion path and the possibility to have coverage over a bigger portion of the working day.

Q5: Cyrus, with ‘re-documentation’ and ‘business rules extraction’ capabilities that you offer, is there a strong
BPM angle possible with your solution set?

A5: The BRE can indeed be used to extract business rules - which can be massaged back into a working application, or they can be used for documentation purposes; i.e. - the following BRE will show how to calculate the value of an Invoice ....

However, we do not see this as a part of Business Process Re-engineering if that is what you mean by BPM.

We believe that the application re-engineering should be done AFTER the translation.

In other works - we think that translation is the first step of an iterative process.  So the first task is to move the code from COBOL to Java or C#. Once the application is moved over, and works fine - the client can move it into 'production' environment - and get a good ROI.

If necessary, then the client can engage in the next step - to further cleanup the application and if necessary re-factor the code.

Q6: Cyrus, as my last question, have you folks, given your hands-on experience, seen any tangible advantages towards opting for either Java or C## [e.g. performance], in preference to the other, or doesn’t it really make a difference – and as a subsidiary, follow-on question, do you folks steer customers towards one language as opposed to the other?

A6: The biggest advantage of Java is that it can be developed on relatively cheap hardware (Windows PC's) - and then deployed on the BIG Unix boxes or even an IBM mainframe.

C# runs faster than Java - but then the biggest machines that you are going to run C# apps is going to be
64-Bit XP!

C# is a recent development for us. We are jointly looking with Microsoft to find smaller COBOL applications to translate into C# - and see how it performs.

Thank you very much Cyrus.

Cyrus this was dynamite.  I learned so much from you, very quickly.  I have been involved with legacy transformation, in one way or another since 1996, and you have opened my eyes to some very exciting possibility.  I am SOLD.  I know that our readership will lap this up.  You should be getting a lot of calls soon.  This was great Cyrus.  Many thanks, especially since I know how busy you are right now.