James Taylor’s notes on his lunch with Sandy Carter of IBM and the CEO of Ilog prompted me to write this. Part of the conversation concerned the appeal of SOA and rules to business users. Speaking as a former vendor, we all want business people to appreciate our technology. We earn more if they do. They say to IT “we want SOA” or “we want rules” and our sale not only becomes easier, it becomes more valuable. So we try to convince the business that they are service-oriented, so they should use SOA. Or we tell the business that they have (and make) rules, so they should use (and manage their own) rules. And rules advocates embrace and enhance the SOA value proposition saying that combined, you get the best of both worlds. This is almost precisely the decision management appeal. Externalize your decisions as services and externalize rules from those services for increased agility in decision making. This is an accurate and appropriate perspective for point decision making. But it doesn’t cover the bigger picture that strategic business people consider, which includes governance and compliance.
Nonetheless,
Effective SOA and business rules have one requirement (or benefit) in common: externalization.
The externalization of services from applications simplifies development, most notably by eliminating arcane programming considerations (e.g., compilers, linkers, operating systems, and instruction sets). This is the most bankable benefit of SOA itself. There are other reasons, such as XML constituting a less rigid schema that (remote) procedure calls constrained by flat, strongly typed argument lists, but as you can read, this is another arcane benefit that cannot practically be considered by the business. To the extent that business likes SOA it is that it reduces development costs, which reduces maintenance costs, and that it allows for switching implementations of services over time. These are IT ROI benefits. They are indirect from a business perspective.
The same is true for rules. Externalization is absolutely critical to deliver the agility value proposition.
Whether the rules are externalized from an application or a service is not as important. We want business people to think that SOA and rules matter to them because it will drive our market. Service-oriented is a great name that you all recognize attracts service-oriented business managers, but that is strictly semantic, having nothing to do with architecture.
What we need to do collectively better is understand that non-technical people don’t want rules or services, they want more control over more agile processes. They are confused by what we call rules versus their governance and compliance issues (which current BRMS and BPM handle poorly, if at all).
My two cents:
Until we externalize knowledge and logic – not just rules – from infrastructure, business people will remain frustrated with the lack of flexiblity and agility of their IT infrastructure and unsatisfactory returns on their IT investments.
Most technologists either share these frustrations or are threatened by them. We all want easier control and more agility. For the business, it increases profits. For technologists, it increases productivity and value.
Externalizing knowledge and logic includes not only decisions but compliance (and governance, in general). To the extent that externalized knowledge does not encapsulate well within decisions at specific points in a business process, however, our current tooling is inadequate. In the future, more of the application will be generated so that it can be governed and compliant in ways that BPM cannot address using externalized rules, whether or not such externalization is encapsulated within SOA.
To put it another way, if agile decisions, governance and compliance is possible through code generation from knowledge managed by subject matter experts, why will we care about SOA? And we will be freed from thinking in rules.