Business Rules to Programmers - Methink thou doest protest too much II

Syndicated from ebizQ

Continuing my response to – Programming Sucks! Or At Least, It Ought To it’s time to take some of the arguments Alex makes and show why I think his arguments should lead one to adopt a business rules approach. Despite the vociferousness of some of the comments and the tone of Alex’s post, I think he actually makes some of my arguments for me.

First, some context. He says:

From a development perspective, however, the percentages are flipped. Only a select few get paid to develop “sexy” software, whereas most of us are stuck developing the boring stuff.

Loading...

Syndicated from ebizQ

First, some context. He says:

From a development perspective, however, the percentages are flipped. Only a select few get paid to develop “sexy” software, whereas most of us are stuck developing the boring stuff.

Absolutely. These are the kinds of systems I too am trying to improve – not the cute, whizz-bang things that get all the press but the heavy duty, back office systems that run businesses. Most of these systems are as dumb as toast – they let you enter data, they store it in a database and then, if you ask nicely, they regurgitate it for you in reports. Many of them are part or completely packaged solutions but these are pretty dumb too. To make these systems smarter you need to automate decisions – have the system decide how to act on your behalf. The problem with that is that these decisions are awash in rules – regulations, policies, judgment or expertise collected from business users etc. Making sure these systems implement the correct set of rules, and that they stay up to date with those rules as they change is often the most difficult part of developing these systems. This is not to say that they don’t have technical challenges like performance, scalability or usability because they do. It’s just the reality that most of the effort in developing and especially in maintaining them is going on the rules.

Under the heading “rethinking software development”, Alex outlines his rules for developing this kind of software. He makes the very valid point that trying to get too clever or trying to find excuses to learn/try new things is particularly dangerous. Three points seem to me to be relevant to my argument:

1. Learn the Business. It’s preposterous to believe that you don’t need to understand the business in order to develop software for the business. Without understanding what their actual needs are, it’s impossible to give stakeholders what they actually need.

The challenge with this, of course, is that it is a little like saying to the business “learn to program” so that they can understand their systems. Programming and developing applications is a skilled job but so is running the business! You can’t be both a programmer and know the business as well as the business people do. Yes, you should try and understand the business as Alex says, otherwise you will not be able to map what you know about systems to what they know about the business.

But why keep giving them fish? Why not teach them to fish? Why not learn enough about the business to see where they could manage the rules themselves? Why not expose some of the logic in the systems – the decision making rules. Not every decision makes sense in this regard but the ones with lots of rules, rules that change often, rules that require lots of domain expertise to understand or that the business just really wants/needs to own do.

2. Serve the Business. Every tradesman wants to use the latest, greatest, and most powerful tools, but rarely are they appropriate for the job. Likewise, there’s hardly ever a business case to immediately upgrade all platforms/libraries/languages. That 10-year old “Classic ASP” code hasn’t gotten worn out, just much less fun to maintain.

Agreed. One of the most powerful ways to apply business rules and a business rules management system is in partial replacement of existing systems. Lots of systems end up getting upgraded to a new platform because the old one is just taking too much maintenance – too many change requests that take too long to fulfill. Replacing the high-maintenance part of the system with a BRMS can dramatically reduce the time to make changes and empower more business ownership of the changes. Less work overall and much less work for the IT department. I have met dozens of companies who have done this and had tremendous results.

4. Code mostly Business. If the overwhelming majority of your hand-written code isn’t domain-specific and doesn’t relate to the application’s purpose, then you’re using the wrong tools. If you truly believe that the system needs a custom logging framework, then externalize it and get a buy-in from the stakeholder.

Here, while I agree with Alex’s emphasis, I might disagree a little. You should certainly not be spending a lot of code on generic capabilities – this is what frameworks and third party components are for – and you should be focused on domain specific code. I strongly believe, however, that hand-coding domain-specific business logic instead of empowering the business to own at least some of that logic is a mistake.

I was struck this week by a post on the Forrester application developer blog – Charles Darwin’s Assessment Of Application Developers where Mike Gualtieri emphasizes how much change developers have already embraced. He quotes Darwin:

“It is not the strongest of species that survives, nor the most intelligent, but rather the one most responsive to change”

Absolutely. It’s time for programmers to realize that just as reports no longer need their expertise and that processes can be usefully designed and maintained by business users, so too are business rules something that non-technical experts can and should own.