Recently, Don Estes and I were working on responding to a government solicitation for the replacement of a fairly large, 30 + year old legacy system. The request for proposal (RFP) was quite well done including a comprehensive list of requirements. The majority of these requirements were expressed as business process and data models with almost 1,000 supplementary text based requirements included. In addition, the RFP referenced the need to manage thousands of business rules – but the actual rules were not provided. Our design for the new system clearly required the use of a business rules management system, but how to identify the rules to configure it?
We suspect that the agency itself does not know all of the rules at a sufficient of level detail for implementation. The rules embedded in the legacy system were developed and then continuously modified over 30 years the system had been in production. It was estimated that at least 15% of the business logic of the system had to be changed annually in order to keep up with new or changing federal mandates, legislative changes and changes in agency policy. Several of the people responsible for the original design, implementation and support have retired.
Could we identify and migrate the legacy rules from the old system into the new? Could we ensure accurate and complete coverage of the business rules? How would we estimate the cost of performing that work? The following is a summary of a dialog between Don Estes and I as we explored a solution to this problem:
Don Estes: Hi Mark, I want to schedule a demonstration of a tool I’ve used in the past which can help us extract business rule details from the legacy system. It is a key part of the re-engineering and legacy modernization services that will be required on this project.
Mark Treat:
Thanks Don, that sounds very interesting. In terms of reusability of existing code our real focus will be on identifying just the business rules. The process, data structures, and interfaces are all likely to change per the models which are included in the RFP. I’m concerned about reusing too much of the legacy system – which is the source of their current constraints.
Our client has gone through a fairly significant business process re-design effort and would like to deploy these new processes with the new system. The new process design is expected to be far more efficient, save money and improve customer service. Their existing legacy system constrains their ability to deploy these new business processes and they want to make sure the new system is designed for the new processes, not the old.
Don Estes:
Agreed, however my concern is that the RFP does not have enough detail on the business rules which will govern the processes they would like implemented. Essentially, the stated requirements reflect a top down approach ~ i.e. requirements which have been elicited and documented solely from existing stakeholders as they understand them. People typically do not know all of the nitty-gritty detail of the business rules which govern their business processes. As one of my colleagues , Jim Highsmith, has stated – from his experience requirements which are elicited from stakeholders “are rarely more than 70% complete … and 50% correct.” It’s just too complex for anyone, even the original system implementers, to understand the system at this level of detail, particularly when it is constantly changing. But we need that level of detail to successfully deliver a new working system.
This is why almost all legacy modernization projects deliver late and go over budget – vendors bid only on the stated requirements. When they deliver a system that meets the stated requirements, it proves to be insufficient. It is then expensive and time consuming to go back and forth refining the business rules expressed in the new code until they get it right
Mark Treat:
What other option do they have?
Don Estes:
The requirements as only stated in the RFP significantly underestimate the true cost of the project. The full, detailed requirements emerge as the project is delivered, when the new system is tested and the results are found to be unsatisfactory. While the new system may comply with the requirements as stated in the RFP the detailed business rules that govern the process are shown to be incomplete. Repairing these deficiencies requires additional work leading to change orders, sometimes litigation and often very dissatisfied customers.
If we are going to do a good job for our client, we need to combine the top down stated requirements with a bottom up approach derived from the legacy code. We know that the existing legacy system contains all of the rules which currently govern the business process – because the system, however antiquated, is nevertheless doing its job every day in conformance with state and federal law, regulation and procedure.
Detailed business rules are embedded in program code and invisible to the current users of the system. Many of these are years, if not decades, old, older in some cases than the people who use the system. Those users are the same stakeholders from which requirements were elicited (top down). It is unreasonable to expect those users to be able to express the requirements at that level of detail.
Mark Treat:
How can we extract what we need from the old system while ignoring what is obsolete?
Don Estes:
We are not talking about reusing legacy code in the traditional sense of modifying it for future execution in conjunction with the new system. Rather, we are talking about “knowledge mining” the legacy code for the identification and documentation of the detailed business rules that are invisible to the stakeholders. Think of it like data mining, but applied to a library of program code rather than the data in a relational database or OLAP cube.
This is the only way for us to ensure that we have 100% coverage of all of the rules which currently govern the business process. And, consequently, it is the only way that our bid will in fact be a correct bid. Any bidders who do not do this will be – knowingly or unknowingly – submitting a significant underbid or, conversely, putting too large a risk factor into their pricing.
Mark Treat:
Thanks Don, understand and generally agree with your comments on the notion of completeness, however I would also argue that many of these invisible legacy business rules embedded in the legacy system may not be relevant any longer. In fact, some may inhibit the organization in ways it does not understand – because they don’t know the rule even exists.
In reviewing the requirements as outlined in the RFP I notice changes in the way services are delivered to the constituents of this agency. In some areas there is more automation implying hard coded business rules for straight through processing. In other areas our client is looking for an increase in the use of professional judgment – where a human being (vs. the system) reviews information and makes decisions. What we really need is a way to identify all of the rules, show them to our client in the context of their stated requirements, and validate which rules continue to be relevant, which may have changed, and which are no longer relevant.
Figure 1Figure 1 represents an example of the user interface of one of the tools used to analyze legacy code. The upper left quadrant provides a view into the actual legacy code. The upper right provides a navigation framework of the legacy code throughout the system. The lower left quadrant illustrates the actual rules within that application, while the lower right quadrant provides information about those rules.
Don Estes:
Absolutely agree, and it gets better. By using the proper tools we can identify the rules in the legacy system and directly export them to our requirements management tool set. If you check Figure 1, you can get an idea of what the tool yields for expressing a detailed business rule. Then, while we work through our Joint Application Development (JAD) sessions with our client, we can bring the extracted rules relevant to each session directly into our discussions. By having the actual business rule right there where we can project them on a screen we can determine that it is correct and complete, correct but needs updating, or obsolete – and update it or delete it on the spot. This is what usually happens during that test-fix process at the end of a project. By doing it in the requirements/design stage the costs of getting the details right are a fraction of the cost of test-fix over and over again. The difference can literally be millions of dollars saved in change orders, not to mention litigation.
Let me drill down a little bit so you’ll see what I mean by this. Our tooling lets us find and efficiently extract the business rules into our requirements management system. Once we have them captured:
- We can associate rules to underlying data sets and processes.
- We can classify these business rules into various categories, for example:
- Interface rules which validate user / data inputs into the system (for example, a social security number must be numeric and have 9 digits).
- Control and security rules which define who can do what, when within the system.
- True business rules which define how the work itself is being completed within the process.
- We can report these rules to our client in a more meaningfully way, simplifying their review and validation of the new system business rules.
- When we change the rules based upon our stakeholder feedback, we maintain an audit trail of those changes, who authorized the changes, and the reasons for the change in the requirements management system.
Mark Treat:
OK, I like where you are going and understand how to integrate this work into our delivery methodology. It would seem that having an inventory of rules and the ability to classify them would also significantly help us in estimating the project cost.
On the subject of cost, I have one more concern. The customer has not asked us to mine the legacy code and the RFP does contain specific requirements for the new system, however incomplete we believe them to be. While we may be doing the right thing by including this approach in our delivery methodology, aren’t we creating more work and therefore more cost to our bid? Our competitors will only have the work identified to build out the specific requirements outlined in the RFP. Their cost will be minus the legacy rules.
Don Estes:
A good point, but experience shows that our costs will be lower. Here’s why: our competitors will be starting from scratch. They will have to spend many hours trying to elicit clarification on the requirements expressed in the RFP. They will have to reconstitute those requirements, validate them and put them into their development environment for coding and testing. They also know that there is a tremendous amount of uncertainty. How long will it take to elicit and validate requirements? Will the client be able to answer all of their questions in a timely manner? How might this affect the amount of code that may need to be generated from the project? While they can try and protect themselves with strong contract language to address these issues, their ability to actually get the required change orders is in question. Bottom line is it will be difficult for our competitors to estimate the true project costs resulting in a lot of risk and a large risk factor in their bid.
Contrast this with our approach. Within days of award we will be able to have a complete set of requirements in our requirements management tool set. We will be able to trace the rules to their origin, rapidly test their validity with stakeholders, and ultimately be able to export these rules into executable code using another set of tools, including the use of a commercial off the shelf business rules management system. This is the subject of another discussion we need to have.
Mark Treat:
OK, I get it. When can we have the demo?
Closing Thoughts:
This thread represents an actual discussion reflecting a specific set of circumstances. While Don and I believe that this approach can be useful in a variety of projects, it may not fit all situations. In this case the legacy system had to be replaced due to specific technology risks. The system was large and complex. There were thousands of business rules. There were to be only moderate changes to the underlying business processes, rules and data structures. The reuse of the business rules contained in the legacy system made sense, but the reuse of the legacy code itself did not. There are a number of alternative approaches to legacy system modernization and business process improvement initiatives. We look forward to discussing some of these with you in future dispatches.
