Way back when I started getting serious about this blog I outlined the three entry points where we saw our customers getting involved with web services and SOA. To refresh your memories, they were
- Start accumulating web services until you have so many of them that you need to get serious about management and integration
- Then look at service oriented integration and start to consider life with BPEL, and finally
- Take an enterprise view of SOA and think about your ESB plans for internal and external end-to-end communication between services.
After speaking with more customers and business partners, I want to talk a bit more about the first entry point.I got into a discussion during a recent customer event with some CIOs when I made the statement “At this first level, you start adding web services and your CIO might or might not know how many there are.” I didn’t really meant this to be inflammatory but simply meant that various departments would pragmatically start using web services as a simple integration technology because they had to so something and web services seemed as logical a choice as any. I also meant that people would use it to solve individual problems vs. taking a larger, more strategic approach to deploying them systematically (that’s what the other two entry points do). The CIOs pushed back hard on this because they felt that 1) if web services were being used they certainly would know about it and, what is more important, 2) their primary view of web services was as a way of maximizing reuse of assets. You can’t reuse what you don’t know about.
I agreed with them on the reuse point, but I pressed them on the point that web services should only be used when you have multiple users. If the technology makes sense to connect two and only two applications together, use it. If it makes sense to connect with just one customer or just one partner, use it. That said, I think you should try to have at least two planned users in mind when thinking about web services from an SOA perspective (that is, from an architectural vs. a low level technology angle). Ideally the two users would be two different customers or partners or interactions from multiple channels, say a call center and a mobile application. The reason why I recommend this is because of loose coupling. You really want to design your interfaces in a way that you do not intentionally or unintentially expose the programming model of the underlying implementation. For example, it would be a bad idea to force everyone to use an interface that was simple window dressing on a COM implementation. You might later switch to an implementation on a completely different platform, possibly because you’ve promoted the service to a different part of your organization or perhaps because you’ve outsourced the service.
So even if you have one user in mind when you build the web service, force yourself to examine the way it works and redesign it if you realize that you cannot support other users in a natural and efficient way or you have inadvertently tightly coupled the user and your implementation.
Another issue that comes to mind while we are still at entry point one is registries, for example, UDDI. Registries are a tough subject and are often the subject of long, seemingly religious debates. I remember when I first got involved with ebXML five years ago that some people had been talking about registry APIs for ten years, but that had not translated to a universally accepted model and standard implementations. In some sense, with the implementation of UDDI v3 in products like the WebSphere Application Server v6, registries are becoming commoditized, at least if you define UDDI as the basic functionality. That is, buy WebSphere v6 and you get a UDDI v3 registry at no extra charge. If you need more functionality, you have several choices which range from enhanced registries to asset management systems. As examples of this range, look at the offerings of vendors like Infravio and Flashline, respectively. There are other vendors as well, and a web search should turn them up quickly. Registries are also important in IT governance and this helps some of the CIOs I mentioned above. See this previous entry for some links on that topic.
Travel notes: I’m in Sydney after flying close to 24 hours yesterday to get here from New York. I did some press today and will be speaking at the Gartner ITxpo tomorrow. After that it’s on to Canberra and Hong Kong for some customer visits and then home in time for Thanksgiving. In case you are keeping track, the Dylan concert on Saturday night was wonderful. There were a couple of issues with a few drunken (or otherwise) middle aged people getting sloppy and falling over the kids, but I suppose that’s part of their education.