The primary purpose of most business applications is to bring automation and efficiency to the business. Outside of a few examples, most of our business applications are required to evolve along with our business, and that, of course can be a challenge for most organizations

The time it takes to change application software gates our business's ability to remain competitive or stay current with internal or external initiatives or regulations. This article is about the core asset in our applications that deals with our business: our business logic or business rules. We will discuss how to group these business rules together to form automated business decisions that can be easily created and maintained.

So where are your business rules? In many instances, most of our business rules exist in one of two places: in the heads of our employees (hopefully in the context of formal policy or procedure manuals) or in our applications, our legacy applications. When I asked Forrester analyst Phil Murphy to define what constitutes a legacy application, he said, "Anything that was written more that 18 months ago." Once programmed, applications become "legacy" fairly quickly. When these business rules are buried in "legacy" applications, problems exist for the both the business organization and IT. Problem one is agility, or the ability to change the application to meet the current business need. Problem two is transparency, or the ability to know exactly what the application is doing in a reliable and auditable way. A recent Forrester report indicated that more than 75% of the IT budget is allocated to application maintenance leaving little for new application development. These problems create friction in many organizations¹.

Along comes SOA or Service Oriented Architecture. Explaining SOA is an article onto itself but in a nutshell in a SOA-based application the business rules associated with key business decisions (like rules that determine claim approval) are formed into standalone business services or, in our case, Decision Services. We will discuss the lifecycle of finding and transforming these critical business rules from your legacy applications to well-formed Decision Services. Decision Services let you maintain the logic in a more agile and transparent way and gain the benefit of greater reuse. These new Decision Services can be called by your legacy application or can be used in new SOA-based application frameworks (e.g., Business Process Management Systems). We'll summarize three topics focused on getting to this tremendous base of legacy business logic:

• Knowledge mining of legacy applications to surface your business rules
• The value of transforming business rules into business Decision Services following the precepts of a Service Oriented Architecture
• Methods for transforming your business rules to modern agile business Decision Services

Knowledge Mining
Most organizations I've talked are concerned about what's in their legacy code. In fact, when we have used knowledge mining techniques to determine exactly what's in their code, most are surprised. Knowledge mining is the process by which legacy code is analyzed and documented. Knowledge mining can be accomplished manually (people reviewing code), but it can be done more effectively by using software tools to parse and map every element of an application. I'll list a set of some of the key outputs you should expect from a knowledge mining exercise.

• You should get a clear map of program flow and control including application overview maps, flowcharts, and UML diagrams,
• Get a map of all variables in the code that identifies which are business variables (relating to business rules) and which are control variables (relating to internal control structures),
• Get a listing of your business rules, including the organization of the business rules into logical functions and sub-functions.

Note on Business Process
I'm often asked if knowledge mining solutions can surface an organization's business processes. For most solutions I've seen I would have to say no. Business process wasn't an explicit design in most legacy applications. User interfaces exist and, for the most part, employees know which screen to use when. I've seen this at banks, for example, where the employee moves from one application to the next to go through the process of opening a new account for a customer. The process can be different depending on whether or not an employee is dealing with a new customer. Legacy applications are rarely explicit about the business process. There are some interesting new capabilities emerging that mine data and use inductive principals to form the business process based on changes in data over time (following the business process lifecycle of the data). One such tool is available from the business process management company IDS Scheer.

Transforming Business Rules into Decision Services
We've seen organizations knowledge-mine their business rules only to transform them from one language (e.g. COBOL) to a different language (say, Java). The problem with this strategy is that you've created your next legacy application problem, almost before you've completed your work. There are two concepts that you should entertain in considering what to do with your legacy business rules. The first is using a business rules management system (BRMS). The second is forming them into discrete business services or Decision Services

A business rules management system is a solution that helps form your business rules into independent Decision Services and then manage the lifecycle of change and promotion of these Decision Services into production. Most notably, a BRMS will enable rules creation and maintenance in a way that allows the business organization (think "Business Analyst") to create and modify its own business rules. To accomplish this sharing of IT assets a BRMS will have a user interface that's "business-friendly," will have a rules management repository that controls access to business rule change, and will manage the approval and promotion of the changed Decision Service into production.

The value of SOA-based services is described above, but again includes agility, transparency, and reuse. Following the principals of a SOA, each Decision Service is atomic and can be changed without impacting its service contract in most cases. This enables significant agility as the core logic can change, but the application(s) in which it's used remain stable and unchanged.

Methods for Transforming Legacy Applications Logic to Agile Decision Services
Most knowledge mining tools or solutions on the market produce reports (knowledge), often based on a database of information mined from the legacy application. These reports are quite useful and go a long way toward helping you understand your application. For some organizations these reports become a critical tool to help in the software maintenance process. For others they become the basis or starting point for transforming their business rules into well-formed Decision Services. The best solutions help to automate this critical transformation. There are companies that form their solutions around these tools and others that use a more manual process combined with low-cost offshore resources to create a similar cost to knowledge mining and business rules transformation.

Summary
The number of legacy applications has never been estimated, but based on many discussions, the pain is clear. Knowledge mining business rules and transforming them into effective Decision Services provide a clear path to SOA and to significant business value. But this is not a simple process, so make sure your solution provider has the experience and proven results and doesn't just move you from your existing legacy application to your next one.

Resources
1.  Phil Murphy. "CIOs: Attack Weak Application Maintenance Processes That Stifle IT Productivity." Forrester Group. February 12, 2007 (www.forrester.com/rb/analyst/phil_murphy)