Thursday, August 12, 2010

When Policy Should be Mandatory

I was asked the question today, "when is point to point architecture justified?" Or conversely, "when is it not necessary to use the ESB?"

My answer was along the following lines:
In the end, most policies are discretionary - there are always good reasons why a waiver may be granted. But the use of the ESB and broker pattern is one area where the policy should be mandatory, and no waivers granted. The broker pattern is fundamental to good architecture because:
1. It separates concerns, eliminates hard dependencies
2. It creates an inherently flexible architecture and can easily cater for unforeseen requirements
3. It standardizes onto a common infrastructure, removes considerable work from projects and programs, achieves economies of scale.
4. Enables common services such as audit, logging, security . . .
5. . . . . and all the usual stuff . . .

But there's a further reason that's even more compelling, perhaps particularly so to business managers that might be pressurizing for a DIY initiative. The SOA architecture is actually just a foundation backbone. Enforcing all traffic onto the common bus allows us to scan ALL message traffic without exception for reasons that may or may not be in the purview of the business process or delivery team. The opportunity to use business rules based monitoring opens up a whole raft of possibilities:
- real time business intelligence (BI)
- real time management information (MI)
- complex event processing
- . . . .

And for this reason there should be no exceptions for any reason whatsoever. The success of real time BI and MI will be the ability to bring together disparate events and alerts to apply new rules in new ways. Leave out one domain, application area, business division etc and potentially the value of the BI is destroyed. Methinks business people will understand this.