« Top 10 reasons for not automating decisions - #8 | Main | Top 10 reasons for not automating decisions - #6 »

7. Why do I need more technology to handle business logic?

This excuse comes up both in forward-looking companies that have made an effort to standardize on a set of technology and on technology-resistors who like to stick only with technology they have been using for years. Let's drill into some of the specific excuses that fall in this broad category.

• I can do "decision automation" already.
  Well yes. In code (that the business can't read), script (that IT cannot manage) or what, exactly? Is the logic that makes decisions externalized and managed? Can you find it and reuse it? Managing business rules in code is a little like managing data in programs (rather than databases) - just because you can does not mean you should.
• I can get all the agility I need from SOA
  With the rise of SOA this is a common one. Clearly you get an order of agility from SOA. It allows you to more rapidly assemble composite applications and it allows you to change the implementation of a service independent from those services/processes/applications that use it. What SOA alone will not do is make it easy to change the way a service behaves. For this you need a technology like business rules.
• I can do all this "rule maintenance" with parameters
  Some IT groups feel they can get all the agility they need from parameterized code or database-driven design or sometimes from stored procedures. They think that coding in Java and using parameters will be faster and easier. It might, if your problem is really straightforward or your rules don't change very often. Most users of business rules management systems also have some rules that seemed too straight forward to put in the rules system. Typically they look back on this and say "I wish I hadn't done that". For all but the most trivial situations business rules are going to be easy to manage, easier to change, easier to share with the business and easier to deploy into production.
• I already have a standard technology stack
  Sometimes known as the "that's just not how we do it" syndrome. This comes down to a simple decision - are you really never going to add another technology to your stack? You really think that your current stack is going to be the best way to build systems forever? Of course not. Anyway, it's not as though business rules are "bleeding edge". Every major analyst firm considers them a class of tool, they are on the plateau of productivity in Gartner's Hype Cycle and thousands of companies, many of them brand-names and/or huge companies, are already using business rules. Get over it, sometimes you just need to accept that a new technology has made its case and should be in your stack.
• I can't use something without best of breed features in <some area>.
  Sometimes people forget that business rules management system vendors are in the business of making it easy to write, manage and deploy business rules. They are not in the business of being the "Best of Breed" IDE, Version Management System, Requirements Management System, Application Container or whatever. Most business rules management systems don't feed the cat or take out the garbage either but they still have a great ROI.
• If I was meant to use business rules, my platform vendor would provide them.
  A variation on the "my stack is complete" argument, this excuse gets used by IT departments devoted to a particular development stack. Essentially they argue that if business rules were really useful, their platform vendor would provide them. Well I have news for you - most if not all of the platform vendors partner with rules vendors, embed at least a lightweight rules engine and have acknowledged that business rules have a role to play in modern systems development.

There are more, of course, but they all come down to the basic value proposition issue. There is a return on investment that is demonstrable for business rules. There are problems for which business rules represent the best solution. It does not matter how attached you are to your current approach or tools, they can always be improved and including a business rules management system might well be one of the ways they can be.

Posted by jtaylor in Business Rules • Decision Technologies • SOA |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/427