While attending DIALOG I had a chance to have lunch with Sandy Carter of IBM and Pierre Haren of ILOG. There was a lot of interesting discussion but two key themes caught my attention – business v IT drivers and reuse.
Sandy discussed how top-down SOA being driven by BPM and has an executive focus, although this only represents about 20% of SOA projects. The remainder are challenge-based implementations with a single focus area. Regardless, the business side represents more and more of the people IBM teaches about SOA with 40% line of business types in their SOA Executive Summits. These folks are driven by a desire to be a more “service-oriented” and dynamic business as well as by a desire to “fix this for good” in areas that have had many temporary solutions over the years. They see SOA as foundational in getting this permanent fix even while their business continues to change. Clearly business rules and policies are increasingly important in this approach and IBM sees that also. One of the key challenges IBM sees is how to measure agility and this has lead to their work on Key Agility Indicators. SOA is an evolution of previous attempts with standards now crossing many companies and a more business-centric language. Both Pierre and Sandy emphasized that business needs and business people are driving a surprising amount of the move to SOA.
Pierre took an interesting position on reuse. He felt that the main value of SOA today is in collaboration and understanding not in reuse. Sandy had some examples of customers getting a lot of reuse but generally supported Pierre’s point, that reuse is not essential to the SOA value proposition. After all, many previous architectures promised reuse and it never seems to get delivered. Reuse may well come, whether through reused services or reused rules between services, but the power of SOA to bridge the business and IT is key. Interestingly, of course, this is also the key value proposition for the use of business rules as a technology.
The group at lunch was lively and touched on governance, centers of excellence, demonstrable compliance through business rules and issues of process integrity across decomposed processes. Wish I had been able to write faster…
Anyway, that’s it from DIALOG.
Comments on this entry are closed.
Seems to me that the externalization is the key part of both rules and SOA with respect to decisions, James.
The fact that service-oriented professionals find the term SOA titilating should not constitute a technical strategy, however (even if does constitute a marketing strategey!)
It is amazing that people still take about reuse even though that promise has been broken or wilted so many times, from object-oriented to service-oriented. The focus should be on productivity until it gets to the knowledge level. It seems tautological that knowledge would not be reusable.
Interesting that business control over agility is not more front and center. Words like rules and architecture don’t belong in such conversations (my view).
75% of a Fortune 500 company’s IT budget is spent on maintenance (Forrester). It stands to reason that the real lift from reuse is the positive impact it could have on maintenance. We spend a lot time thinking about design and development, but that really isn’t the pain point for most companies. So how would SOA provide the kind of reuse that would have a real impact? I only see two options. In the first, we build services that are so fine-grained and so numerous that applications can be composed in an infinite number of ways. For this to work, there has to be metamodel that describes the features of these services in excruciating detail and (said repository) has to be endowed with enough intelligence to reason on its own about best choices, redundancy, dependencies, etc. I don’t see anything like that available in the near future.
The other option is a few giant services that do everything, but are so general in nature that configuring them for an application is a massive undertaking. SAP R/3 comes to mind, though the reuse is at a higher level (the software company’s).
Clearly, something in between is the answer, but we have a way to go before we have the kind of active, inductive, representational framework to arbitrate an architecture like this.