Put Business Rules at Center of Agile Development


Last week I wrote about Agile software development's ability to help bring IT and the business closer together, thus increasing the odds that IT would provide enterprise applications that actually (gasp!) help users do their jobs.


The post prompted a pingback by James Taylor, who wrote a thoughtful response on his Smart (enough) Systems company blog. I am spotlighting it here, since I know many folks may not have clicked through to it and it deserves a wide audience.


Taylor's software-development chops certainly show -- and that's a good thing. I am a writer, not a developer. I've never written a line of code in my life. My intent with the original post was to offer some deserved exposure to Agile development concepts. In doing so, I passed along some tips from a Computerworld article on how companies could try out some of these concepts.


Taylor rightly called me (and Computerworld) out on a suggestion to "use dynamic scripting languages like Ruby, Python and Perl." He poses a question that simply hadn't occurred to me: Is the average business user going to be any more likely to understand Perl than Java? Ahem, not this business user.


Taylor suggests:

Instead of continuing to use procedural gobbledegook that no user is going to understand, it is time to move the business logic that drives our systems into something more useful - business rules.

Doing so makes sense because business users can actually read and write these rules, putting them on an even footing with developers. As a bonus, it also makes it easier to follow some of Computerworld's other suggestions.


For instance, Taylor notes that business users can make tweaks to rules that can be tested in isolation and rapidly deployed. Voila, you've achieved the Computerworld article's objective of emphasizing frequent releases.