I was reading Phil's article The Difference Between IT and Business Enablement and it made me think about how to deliver business enablement whether or not you are using BPM software and whether or not you are building systems on top of an SOA. Business enablement to me means putting the business users, those who understand the business and how it needs to change, in a position to make the changes they want and need without IT being a roadblock. This may (or may not) mean they can change the production system without a release cycle but it certainly means that the business does not have to explain their requirements to IT but can, for those requirements relating to the business, define how they want the business to respond themselves. Phil calls this "driving requirements down into the SOA layer". I think that rules are somewhat different from other kinds of requirements (see this section of my other blog for more) and so business enablement is not so much about managing requirements differently so much as identifying that requirements are not the same as process definitions or the same as business rule definitions. Business users don't need to manage requirements like "have 99.9% reliability" themselves to be "enabled" but they do need to be able to add a branch to a process to handle a new customer type and to add the new rules to define when someone is in this segment. In fact business enablement requires the ability to manage processes or rules or both to deliver real agility (see this post on the different kinds of agility). Phil also points out there must be "no confusion caused by transforming a high level picture to a low level executable". This is an area where business rules management systems excel. For instance, see what Bruce Silver had to say about what BPMS can learn from BRMS particularly in terms of empowering business users to really own business rules not just see them. Bear in mind the dirty little secret of business user rule maintenance though!
So, if you want a way to empower your business users, consider using business rules to build services or to renovate pieces of legacy systems. Business rules management systems will let you give some (or a lot of) power to your business users and enable them to control how existing systems, and new processes, behave. In many ways this is the only way to use an SOA to add real agility as I noted here before.