In case you've forgotten some of your Egyptian mythology, a phoenix is a legendary bird said by the ancient Egyptians to have lived five or six centuries in the Arabian desert.  Consumed in fire by its own hand, it then arose in youthful freshness from its ashes.  As a symbol, a phoenix stands for something that experiences a restoration, renewal, or seeming rebirth after ruin or destruction.^[1]

Fortunately in most companies, legacy systems aren't to the point of 'ruin and destruction' — at least not yet.  On the other hand, they certainly aren't equal to today's business and IT challenges either.  Indeed, those challenges are formidable.  Here's a quick list:

• Supporting new channels of business, such as the Web.
• Achieving consistency in operational business decisions across many platforms and channels.
• Reducing the cost of 'simple' change requests.
• Changing rules rapidly in an evolving, fast-paced business environment, while ensuring the stability of code and platforms.
• Maintaining legacy code and platforms as the company loses knowledgeable-but-aging staff.

Compounding the dilemma is that many legacy systems are mission-critical.  Given the industry's less-than-stellar track record in re-engineering such systems, and knowing what the costs would be, many companies (most?) shy away from such projects.  The risk is perceived as simply too high.  So they find themselves stuck between a rock and a hard place, the monolithic past and a looming future.  Hopeless situation?  No middle road?

No, not a hopeless situation, and yes, a middle road.  There is a way that rejuvenated business rules, and perhaps new code, can rise from the ashes.  Let's take a closer look.

A central idea in enterprise decision management (EDM) is that operational business decisions, not data or even business rules per se, should be the focus.  Operational decisions represent the minute-to-minute 'smarts' of business processes.  You can think of EDM as the counterpart (or better, peer and partner) of business process management (BPM).

When legacy systems have problems, or applications written for new channels or platforms produce inconsistent results, many people immediately think "data."  The message of EDM is that they should instead think "decisions" since high-quality decisions are what really matter to the business.  In this view, business rules are simply the means to an end — a means to make those decisions as consistent, agile, and traceable as possible.

Fortunately, current thinking about IT architectures, especially SOA, helps out.  In SOA, the focus is on services, especially business services, and none seems more natural than decision-centric services — i.e., decision services.  Raden and Taylor define a 'decision service' as "a self-contained, callable component with a view of all conditions and actions that need to be considered to make an operational business decision.  More simply, it's a component or service that answers a business question for other services."^[2]

It's not a bad start to think of a decision service simply as a bundle of business rules.  Raden and Taylor add several important clarifications.

• A decision service does not have to be a service in the strict SOA sense.  In a more traditional architecture, it can be an application with well-defined interfaces and strictly limited function.^[3]
  
  
• Although a 'bundle of business rules' is generally basic to a decision service, it can include more.  For example, in highly sophisticated decision services you might find run-time analytics specifically focused on the targeted decision.  (In the large majority of cases, however, the analytics do not need to be run-time.)

With that background, I can now introduce the Phoenix Strategy, a middle road to rejuvenated systems and legacy modernization.

The idea in a nutshell is to focus on two or more applications supporting the same 'problem' decision.  Identifying a 'problem' decision is largely straightforward:  You are getting inconsistent results on the decision from the different applications; there are lots of change requests because the business rules are in flux^[4]; the business feels especially exposed because of customer service issues, competitive pressure, or regulatory deficiencies — or more likely, all the above.  Usually, but not always, the applications are running on different platforms (e.g., mainframe running in batch and Web server).  Most likely, the applications were implemented by different people at different points in time, with different understanding and approaches (you know, that 'stovepipe' thing).

To create the decision service, you follow a business rule approach, using rule management and hopefully (but not necessarily) a rule engine.  The trick is to restrict your scope to the limited set of business rules needed for the 'problem' decision.  You excise the rules from the existing code, unify and 'cleanse' them, and externalize them to the decision service.  The applications then 'call' this decision service when the decision needs to be made.  (It goes almost without saying that rigorous testing of the new configuration should be performed.)

Following the Phoenix Strategy achieves breakthrough improvements and benefits at the lowest possible risk to the company.

• On the decision-service side, the business rules are now single-sourced, authoritative, accessible, and well-managed, and thereby available for continuous refinement and re-use.
  
  
• On the application side, the monolithic legacy has become slightly less monolithic.  More importantly, you have reduced the number of IT change requests involving only business rules, thereby reducing maintenance costs while actually enhancing stability.

The bottom line is that by externalizing the business rules, you have allowed each side a more natural life cycle — slow, cautious, IT-driven change for the applications, and rapid, opportunistic, business-driven change to the business rules.  As Raden and Taylor say, "Decision services are … built to change, not built to last."^[5]

The Phoenix Strategy has additional advantages.

• If you are just getting started in business rules, it offers a great way to show direct value and ROI from your initiative, and to gain valuable experience and credibility, all within a well-delimited, relatively narrow scope.
  
  
• Over time, you will naturally want to address more and more 'problem' decisions, steadily excising their business rules from the application code and unifying them in more external decision services.  That approach offers a highly pragmatic, value-driven plan for your business rule initiative in the longer term.^[6]

After several years of steady progress, those monolithic legacies may suddenly seem not so monolithic any more.  Much of the true business logic will have been externalized, and only mechanical code left running.  That's perhaps when the fun can really begin — reengineering a whole new bird without having to put your company on life support to achieve it.

References

[1] Merriam-Webster Unabridged Dictionary.

[2]  James Taylor and Neil Raden.  Smart (Enough) Systems:  How to Deliver Competitive Advantage by Automating Hidden Decisions.  Prentice-Hall (June 2007).  ISBN:  0132347962, p. 127.

[3]  Taylor and Raden (p.  254) explain that a decision service "… need not be an actual service in the sense of a service-oriented architecture (SOA), although it could be.  Examples of implementations include the following:  a Web service, a COBOL subprogram, a Windows DLL, a .NET assembly, [or] a J2EE Message-Driven Bean (MDB).  You can use any of these implementations or many others.  All you need is the ability to define an interface to the service (data in, data out) and encapsulate the rules in that service.  An interface might mean a pair of COBOL Copybooks and a program or Web Services Description Language (WSDL) and a service implementation.  You should pick the implementation that works best with the platform you have selected."

[4]  Taylor and Raden (p.  127) note:  "In many applications, the majority of the change requests come in a small area, such as the pricing or eligibility module.  In these applications, the majority of the code typically has few change requests and is largely stable.  The change requests are usually requests for changes to the business rules embedded in the code.  Renovating this one piece by using EDM, developing a decision service to replace it, costs much less than replacing the whole application.  The new decision service, built using business rules, will require fewer IT resources to maintain and will allow business users to make many, if not all, of the business changes they need themselves."

[5]  Taylor and Raden, p.  271.

[6]  Taylor and Raden (p.  329) also point out that decision services allow a more effective 'build or buy' decision:  "Organizations can buy services based on best practices and standards where the functionality of those services is not critical to the organizations' competitive differentiation.  They can then build services with competitive potential and use an SOA infrastructure to compose them into effective applications and processes.  Many services that differentiate an organization — that is, that define how it acts differently within a standard process framework — are decision services.  Focusing on decision services can, therefore, make it possible to construct composite applications mostly from standard services that still deliver a unique and competitive customer experience."

# # #