I was reading the Islands of Automation, a post in Minimal IT: Spend Less, Get More.

Pros for Islands of Automation from the Post

1. Identity and clear boundaries. Islands have names.
2. Clear role. Small islands have well-defined economies
3. Clearly defined communication. Movements in and out of the island are very controlled
4. Self-sufficiency. Island communities have to cope with periods of being cut off from the mainland.
5. Clear security. It is hard to get to the island except through the defined communication links.

Cons for Islands of Automation from the Post

1. Shipwreck of automation. To avoid isolation, you can break down system structure, and release functionality into a sea of reusable components. This become unmanageable, with business capabilities scattered unowned all over the place.
2. Gridlock of automation. Another approach to avoid isolation is to draw up a grand central plan, showing all the parts and their proper interconnections. But we are not that clever. Our plans do not survive the onslaught of unexpected business change, such as mergers and acquisitions. Our attempts to centralize build high dependencies between systems. We end up in design gridlock, as multiple systems need to be changed to achieve even the simplest of business changes.

And finally

We need well-defined, purposeful, self-sufficient systems, with rich and clear connections to others. Given the alternatives, well-connected islands of automation are a good analogy for how we should approach systems design.

Cool! Sounds pretty much like the promise of Service Oriented architecture. I am talking about the idea and not of any particular technology like ESB or BPM.

I would however say that any efforts towards such well defined componentization would be incomplete without componentizing the decision making services needed by the enterprise.
BRMS will certainly help because it provides the necessary methodologies, technologies and best practices that might be required.

But this effort is not without its challenges. For one, data model consistency would be a major issue. One trend these days is towards standardizing data models. Some important efforts have been Acord and MISMO. There are of course others, but I am familiar with these two.

Now, with the data model standardized, using a business rules management system, it becomes infinitely easier to carve out business decisioning services that have well defined input and output contracts.

Now, a componentized business decision service offers infinite possibilities. You can reuse it, depending on the service, it is easier to update,change,maintain from a software perspective, so architects will love it.

Going forward, I am sure in the coming years , we should certainly see standardization of business rule formats, standardization of the rule engine and rule repository interfaces. We will then begin to see rule libraries.

To wander off into dreamland for a moment …

1. The government will publish the latest regulations as business policy distributions(libraries) that Enterprises will need to download and their business systems will start applying the new policies. You will have HIPPA libraries, for example.
2. SMB’s will purchase business software off the shelf, and they will purchase policy libraries that they need off the shelf.
3. Mortgage companies will simply purchase Eligibility, pricing, underwriting libraries they need, and customize them if required.

Wow. The possibilities are endless. Long live Business Rules!