In a recent article, Ron Ross quoted a slightly terrifying ancedote on the ability of large organizations to care for their expensively implemented systems.
A business analyst at a major insurance company recently said this: “When we looked hard at business rules currently implemented in existing systems, we found at least 30% were flatly wrong. That’s a very conservative estimate: the actual figure was probably much higher.”
Given that an insurance business is really little more than sets of rules – underwriting rules, claims management rules, customer cross-sell rules – and that it is a heavily regulated business, incorrect rules are more than bad business but a potential regulatory nightmare.
Still, the overall point is valid. For many corporations, the problem starts with the ability to find a specific piece of business logic.
After years of making tactical IT decisions to create short-term ‘agility’, what’s left is a maze of interlocking systems built by teams lost two recessions ago. Many businesses are at the start of their SOA or Rules journey to bring order to chaos but the road is long and lonely.
In this context its often not even self-evident what system is making which decision, let alone how to change the rules.
Ross goes on to write:
… the business analyst went on to say, “ IT told us they couldn’t solve the problem because it was a business issue not a software issue. And they were absolutely right about that.” Yes indeed they were.
As much as the headline resonates with me, I really dislike the punchline.
First off, it creates a false dichotomy between software and business problems and ignores the fact that most software problems ARE business problems.
Secondly, it suggests that the business analysts or the underwriters can maintain rules without any assistance from IT. If these rules are really in a legacy system and not a modern rules engine with built-in governance, this assumption is fundementally untrue. To change the rules, IT will have the build the change.
Thirdly, the ultimate system selected to hold the business rules was a technical judgement guided or completely made by IT. No senior underwriter at an insurance company makes the final decision to put business logic in a CRM system rather than a custom-built application. Fundmentally, it is pretty annoying when a technology team that helps you to dig a hole but won’t help you dig yourself out when you need it.
Perhaps, the overarching problem I have with the conclusion is that the problem is neither a business nor a IT problem but a problem for both. To suggest otherwise, ignores the fact that these groups must work together to succeed.