Is a Services Architecture Threatening?

An interesting CIO insight article caught my eye today - Services Software Architecture: Efficient, but Threatening? This article suggested some good questions to ask about SOA and raised a number of great points about the potential for an SOA to be threatening. Let's take the questions first:

• Are our enterprise architecture efforts providing business users with the business flexibility they require?
• What is our plan for reducing maintenance costs and speeding up development times?

Both of these questions could, and should, be answered by pointing to the development of business rules-based services. Such services not only have all the advantages of a service in an SOA, they also allow:

Business users to maintain the rules in these services, giving them flexibility and agility

Reduce time to develop complex decisioning services by using a technology designed specifically for that issue while taking advantage of the pluggability of SOA

Dramatically reduce maintenance by eliminating the role of IT in changing key business rules in those services (see Gartner, Forrester etc).

SOA and business rules are indeed reinforcing concepts - the value of the combination is greater than the sum of the parts.

As for being threatening, many of the issues with SOA do also apply to the use of business rules. For instance, it is said in the article:

"Application owners and line of business architects are used to controlling the environment, the people and the priorities," Moreland says. "The culture was one of 'If I don't control it then I may not trust it.' Now these things are being shared."

This is very similar to the issues faced when trying to get the IT folks to empower the business users to maintain their own business rules - it means giving up control. I wrote more about this issue, and quoted some good articles in ADT Magazine, here: http://www.edmblog.com/weblog/2005/07/business_rules__1.html