individual-entry-BA-Blog

« Business Role changing? | Main | What do the analyst firms say about business rules? »

Starting with Legacy Rules

At least 50% of our BR projects involve excavating "rules" from existing legacy code.  This does not mean simply chopping existing code into smaller pieces and forward engineering them into new technology. It usually means trying to salvage the true business rules out of the code, correlating them to business vocabulary, and analyzing them for business value prior to putting them into newer technology (such as a BRE).  At odds is that the mining of rules from code requires very technical resources while the analyzing of them for business value requires knowledgeable business leaders.  How have people addressed this challenge?  What kinds of people and skills are needed for a project that starts with mining rules from code, then analyzes them for business reasons, then forward engineers them into a BRE?  Do such projects often involve mining rules from code and from documents and from peoples' heads?  If so, how are these rules integrated safely into an automated solution that makes sense?  (We are finding that this is a requirement that is becoming extremely prevalent).

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451629b69e200d83470b4eb53ef

Listed below are links to weblogs that reference Starting with Legacy Rules:

Comments

Barbara von Halle

I am surprised that there are no postings on this thread. Let me ask some simple questions to see if we can address this all important (and emerging) topic in some depth.

1. Is anyone out there doing legacy modernization of any kind and, if so, do you use automated legacy understanding tools?

2. Are any of you trying to find the business rules in legacy code so as to forward-engineer into a BRE, such as Fair Isaac's Blaze Advisor?

3. If the answer is yes to either of the above, do you have lessons-learned to share (about methodology, legacy understanding tool functionality, or relevance to BRE implementation, etc)?

Barbara von Halle

Let me ask a simpler question. Does anyone out there have a need to find out what the rules are in an existing system (so that you can put them into a BRE, like Blaze Advisor?) Please share thoughts, concerns, advice.

Paul Vincent

Barb - although it is an interesting question, I get the impression that many organizations are still "investigating" what to do with their "legacy" (and usually business critical) applications. One alternative approach, which seems very popular, is to automate the translation of (say) COBOL code to (say) Java code, in the vain hope that such code will be more maintainable. Of course, a better approach might be to re-use the COBOL investments for system code and simply embed business rules (eg Blaze Advisor for COBOL) maintained via a web-based Rule Maintenance Application.
One group very active in "reengineering" legacy applications is the OMG Architecture Driven Modernization Group - see http://adm.omg.org/ - some of whose members certainly understand the benefits of mining business rather than just IT semantics.

Narayan

I would also very interested in how rules extraction is being done. Per whatever i have read on the net, tools like SEEC are suggested. There are similar tools from a java perspective also. How effective are these ? I guess even after that we would require effort of both the business people and technical people to extract the required rules and document them. Incase any folks have already done this sort of activity i would be interested in hearing from them

Nic Walsh

I am working with a company which is a member of the OMG group you mention. we have clients who have used our toolset to mine BRs, for forward documention-only, for extraction as reusable oomponents, or for movement into BR engines. Typically rules projects need to proceed first with a discussion of what constitutes a BR (client dependent and may be represeted outside code - e.g. screen ordering). Then both top-down (e.g. use case, data flow etc.) and bottom up simultaneous analysis can be undertaken - bottom up to search for types of code operation suggesting rules are in operation (for gap analyis and validation we haven't missed anything). Rules can be extracted either as documented statements - a la requirements (e.g. max_credit = 1000) Or as actual code - algorithmic routines. Both can be relevant. Useflu tests of technology is in the depth of the legacy parse tree (determines search types, flexibility and veracity), openness of the Repository used to store the meta-data and flexibility of outputs - can it produce rules, requirements, java, UML, class defintions, XML, etc.

Paul Vincent

There is certainly a need for analysis tools. The problem is that "business rules" are really at the Computation Independent layer in OMG MDA, whereas code (including database triggers etc) is at the Platform Specific Layer, and is mixed with lots of process code and technology-specific code.
I'm certainly hoping the OMG ADM team can bring to fruition some standardized approaches for extracting rules, processes and information from existing codebases!

The comments to this entry are closed.

Search Site


  • dmblog.fico.com

Subscribe

  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.