Comments on: More on Business Rules in Legacy Modernization http://jtonedm.com/2009/05/18/more-on-business-rules-in-legacy-modernization/ James Taylor on Everything Decision Management Mon, 14 May 2012 18:05:17 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Cyrus Montakab http://jtonedm.com/2009/05/18/more-on-business-rules-in-legacy-modernization/comment-page-1/#comment-14326 Cyrus Montakab Fri, 22 May 2009 11:14:56 +0000 http://jtonedm.com/?p=1981#comment-14326 Hi James, At SoftwareMining, in addition to our translaton tools, we have tools to help extract Business Rules and document the COBOL systems. Some of our BRE-QT enquires are focused on migration towards COBOL rules. Usually such enquires are looking at re-factoring a big chunk of their system, if not most of it. Such projects are <i>already</i> big and expensive. Question is how bigger would the project become if they migrated to “maintainable” Java first? Would they have to migrate the whole thing – or just parts which is destined to be re-written as rules? Depending on the COBOL platform (IBM, ESQL, UNISYS – DMS-II, ….), this often is a viable possibility. When looking at modernization projects, one should investigate cost, risks and benefits of each option. If, as you say, only a small part of the system needs changing, then perhaps it can be done quickly with minimum changes to other areas. If it is going to be a big project, then it would make sense to also consider long term maintainance options. I have posted a more detailed response on <a href="http://www.softwaremining.com/blog/CyrusMontakab/2009/05/22/1242986820000.html">COBOL Business Rule projects are large projects</a> I look forward to your feedback there. Regards Cyrus Montakab <a href="www.softwaremining.com">SoftwareMining</a> Hi James,
At SoftwareMining, in addition to our translaton tools, we have tools to help extract Business Rules and document the COBOL systems. Some of our BRE-QT enquires are focused on migration towards COBOL rules. Usually such enquires are looking at re-factoring a big chunk of their system, if not most of it. Such projects are already big and expensive.

Question is how bigger would the project become if they migrated to “maintainable” Java first? Would they have to migrate the whole thing – or just parts which is destined to be re-written as rules? Depending on the COBOL platform (IBM, ESQL, UNISYS – DMS-II, ….), this often is a viable possibility.

When looking at modernization projects, one should investigate cost, risks and benefits of each option. If, as you say, only a small part of the system needs changing, then perhaps it can be done quickly with minimum changes to other areas. If it is going to be a big project, then it would make sense to also consider long term maintainance options.

I have posted a more detailed response on
COBOL Business Rule projects are large projects

I look forward to your feedback there.

Regards
Cyrus Montakab
SoftwareMining

]]> By: Vijay Narayanan http://jtonedm.com/2009/05/18/more-on-business-rules-in-legacy-modernization/comment-page-1/#comment-14321 Vijay Narayanan Thu, 21 May 2009 01:39:37 +0000 http://jtonedm.com/?p=1981#comment-14321 Couldn't agree with you more. I think there are a number of challenges with maintaining rules in legacy systems: - lack of transparency and high cost of maintenance - lack of consistency/categorization of rules and possible duplication of rules across legacy systems/modules - mixture of presentation logic such as green screens with business rules Last but not least the cost of change and lack of agility/declarativeness all make legacy rules unattractive when compared to placing them in a rules engine. The rule engine per se won't guarantee every benefit but it certainly makes it easier to achieve organization, modularity, reuse, integration for SOA-based processes, and consistency. Couldn’t agree with you more. I think there are a number of challenges with maintaining rules in legacy systems:
- lack of transparency and high cost of maintenance
- lack of consistency/categorization of rules and possible duplication of rules across legacy systems/modules
- mixture of presentation logic such as green screens with business rules

Last but not least the cost of change and lack of agility/declarativeness all make legacy rules unattractive when compared to placing them in a rules engine. The rule engine per se won’t guarantee every benefit but it certainly makes it easier to achieve organization, modularity, reuse, integration for SOA-based processes, and consistency.

]]>