InfoWorld has a great anonymous column "Off the record" and one entry, Working on the railroad caught my attention.
Now this kind of story is sadly all too common, both in enormously complex "customization" projects for packaged or acquired software and in "build to suit" software. Massive overruns, hard to make it meet requirements, poorly defined requirements, massive enhancement projects after the implementation is "done" and, probably, an ongoing maintenance nightmare.
Now I am not going to propose for a second that any technology choice could solve the myriad problems that show up in this story and hundreds like it. However I would like to address how business rules might have helped.
If I acquired an application, packaged or from another company, that had been architected with a business rules management system at its heart, how might my experience be different?
- Well key decisions would be configurable by me so I could change the way the software behaved to better serve my needs.
- The rules being implemented would be clear and unambiguous and stored in a central location making it easier to find them, understand them and change them.
- The structure of a rules repository is typically driven by the lines of business supported or some other equally robust segmentation of the business problem. This would have made clear which lines of business were included and what the rules were for each.
- Those rules specific to each line of business could have been exposed directly to the users who understand them. Thus the folks who knew the rules about grain transportation would have had an interface through which they could have managed them directly, without going through the medium of IT.
Would this be perfect? No. Would it be better? I think so.
Now if I was going to be building a system for myself I could avoid some of the parallel problems by using a rules management approach.
- I could clearly delineate the parts of the system that were highly volatile and, instead of trying to nail down the requirements at some arbitrary point in time, I could define the kinds of rules required and let the business manage the actual rules they need at any given time.
- I could structure a rules repository to let me have core or shared rules as well as rules specific to a line of business or state or whatever.
- I could reduce the confusion between IT and the business by using a more approachable, declarative business rules syntax.
And so on.
Food for thought.
