James Taylor's Decision Management

I often get asked about calculating the ROI for decision technologies like business rules management systems. One particular aspect of ROI calculation that I think is often overlooked - your "value backlog".

Most IT departments have a backlog - the list of projects that are not being worked on due to a lack of time and resources or to higher priorities being assigned to other projects. If your IT department doesn't then please feel free to stop reading now. Assuming your IT department does have a backlog then someone has probably estimated the potential business value of the projects in this backlog. Most projects don't even make it to the backlog unless they have a positive potential - that is the business value of the project exceeds the cost of the project. What this means is that magically completing all the projects on your backlog would add tremendous value to your business - your "value backlog".

Now there are lots of reasons why organizations have a value backlog but one of the most persistent is the fact that a huge percentage of IT resources are spent on systems maintenance - I have heard of companies spending 75%+ of their software budget on maintenance, for instance. If you're spending all that money on maintenance then no wonder there's an application development / improvement backlog! But what if you could start building new systems, or modifying existing systems, in ways that would reduce your maintenance burden? Then you could reassign these maintenance budgets to new development work and start turning your "value backlog" into value. It is this aspect of ROI that I often see neglected - companies try and consider the Total Cost of Ownership for new systems but they don't account for the additional value in other projects that could be completed if the new system was easier to maintain.

One way to make new systems easier to maintain is to use Business Rules Management Systems to automate the business logic in those systems - this is the part of the system that never seems to stabilize. If the business users can change these rules for themselves then IT can go off and generate some value - something companies often spend less than 15% of their IT budget on. So if you actually need to deliver any innovation from your systems, you need to free up some of the money you are spending on application maintenance. Going forward that means changing the habits that built systems as if they would never have to change. The maintenance backlog is winning the battle for application development resources and so limiting the ability of the IT department to add value.

Build new systems to reduce future maintenance by using business rules to avoid "write-only" code or code that simply is not readable. This is a particular problem when the code is implementing business logic - the rules that drive how your business behaves. The reality of change is that there is no way to stop "customers" from changing what it is they want. It's also true that even if your customers know what they want when you start the majority of the lifetime of the code you are writing is going to be in the "change time" period after the first version is done when changing realities cause the needs of the code to change. This means you cannot build to last but must build to change. In addition, nothing can be maintained easily unless it can be understood. It is not enough for other programmers to be able to read the code - the people who understand the purpose of the code must be able to read it, or at least some of it. Ideally you want them to be able to actually participate in the ongoing management of the business logic that represents your business embodied in your code which means you need a way to have them manage the "code" without seeming to. Which brings us back to business rules.