InfoWorld Executive SOA Forum March 2006

The InfoWorld SOA Executive Forum remains an interesting and apparently popular event about a year after it first started. This is the third one, and I’ve had the pleasure to attend all three as a participant on one of Jon Udell’s various panels (here’s his description of the ones from yesterday).
Did I ever mention what a great guy Jon is? (Did I also mention that he reads my blog? 😉
Seriously, it has always been a pleasure to participate in Jon’s panels. He always comes up with good, challenging questions and I always learn something from the other panelists. I thought this one went very well because we had a good conversation on a range of topics, but someone came up to me afterward and said there wasn’t enough controversy for his taste…I think he was joking.
Anyway this time we were talking about the various development paradigms available for SOA, including RPC, asynchronous messaging, and document oriented (which I actually tend to equate with asynchronous messaging but you can pass documents using RPC, or maybe more correctly request/response since this is how HTTP works for example).
In the end, the enterprise probably needs some combination of all of the above. But how to choose? Go by whatever the developers are most familiar and comfortable with? It is true that subcultures in distributed computing tend to spring up around these different approaches since they each have their tricks and best practices and lessons (to be) learned.
But I do not think so. I think it’s more important to choose the best tool for the job since some application requirements are better served by one or the other.
Here’s my rule of thumb, which I explained in a bit more detail during the panel yesterday. I think it depends on the significance of the reply to the application and especially to the user.
For example, if you are authorizing a credit card, and you get a successful reply to your message, you expect to be able to use that credit card on the next message to buy something. The significance of a synchronous, RPC-style reply is that the database has been updated.
On the other hand, you may need to know is that the message was reliably captured for later processing. For example, you’ve placed an order with and the reply says that Amazon has received your order and will process it later.
One other interesting point of discussion was who should we make things easy for? The developer of the service or the consumer of the service? If we make the programmer creating a service do a bit more work to produce a more useable and useful service, isn’t that time and energy well spent? As opposed to just assuming that all services can and should be easily and automatically generated by tools, which is kind of where we seem to be now with Web services tools.
Overall the event is really good because it focuses on lessons learned from customers working on SOAs, and also because Jon and his colleagues manage to focus on technology and business topics of general interest.
Yesterday’s keynote was by Jeff Gleason of Transamerica, who told us how they had started an SOA pilot but cancelled it because it was at the project level. Their problem was that they were already suffering from project based architecture.
He also described how their core policy rating application had dozens of other applications integrated with it, making changing the core business application too difficult because of the impact of change on all the other applications depending on it. SOA as an approach helped resolve this issue.
He also described the way they inventoried existing systems to see what could be reused, identifying deltas representing new development, and how they categorized business events and the functions and services associated with them.
The InfoWorld folks have promised to post the presentations so I will post a link when they do.


One response to “InfoWorld Executive SOA Forum March 2006

  1. The webservices tooling is a very gray area esp. the question of whether we should make it easier for the developers or the customers.
    From the face of it, what you said makes sense. But what about companies who are the intermediary in providing these tools to other companies who then implement some system for the end user. What approach do we follow in the intermediary company? Should we make it easier for the developers or the end users? Because the developers become the end-users for that company.
    I think the tooling is here to stay even if we dont like it from a logical perspective.