Why was Relativity sold so cheap !!
The most widely used COBOL Business Rule Extraction tool (and the most accomplished?) was developed by a company called Relativity.
From what I know, the Relativity raised at least $16 Million in investment during its existence but then it was sold for $9 Million to MicroFocus. So, what went wrong? After all those years of product and business development – they sold for only $9 Million? And now MicroFocus with its bigger marketing muscle has not been able to use the product to change it’s depreciating share prices.
We all agree that Business-Rule-Extraction can be very attractive to most companies. There is a lot of knowledge in systems that have been developed over decades. Proper documentation of these systems is very useful – it can be used for rewrite of the system, regulatory compliance, documentation, and … So why wasn’t Relativity more successful?
I think there were multiple problems with this field. For one people have different understanding of what a Business-Rule is:
- is it a inference engine, atomic, rete-based series of if-then conditions which fits into a rule-engine? Going from a procedural logic written in cobol into such a rule requires VAST amounts of code re-architecture , which currently no tool (including SoftwareMining’s) can achieve.
- Or is it a piece of documentation which outlines how an operation/process is achieved? Whilst a tool can easily identify the set of COBOL statements which define that operation/process, it is difficult to define the correct level detail! If you ask the system to provide all information – you’ll be flooded with too much information and the project dies. If the system provide too little information – then the tool vendor can be sued for missing potentially important information!
I am not suggesting Business-Rule-Extraction was a complete dead end – it worked in some but not all projects.
But now I am coming to realization that a better path exists. Over the last few years SoftwareMining has been focusing on performing automatic re-structuring / re-factoring of COBOL code into an Object-Oriented Java or C#. For example, imaging a COBOL program working on CLIENT-RECORD. During the translation the statements to do with printing the CLIENT-RECORD to should be moved to Client-Class, and the statements establishing whether a client qualifies for a loan, should also be moved to the Client-Class. This would produce a new “functional” Java or C# code base, which is maintainable (due toOO), and can be tested for correctness (regression testing). But also after such OO componentisation – various parts/components of the system can be easily re-implemented manually within a Business-Rules management system!
In conclusion - first move from COBOL to a well structured Java or C# code base, test it, and only then consider re-implementing the appropriate parts within a Business-Rule system .