Todd Biske: Outside the Box

There’s some interesting banter going back and forth between Dion Hinchcliffe and Steve Vinoski, stemming from Steve’s IEEE Internet Computing column, entited The Social Side of Services.

In this blog entry, Dion states that socializing SOA is “not the first order of business or the most important aspect of adoption.” Steve counters in his own blog.

Whether you agree with Dion or Steve, this is a very interesting conversation. I, for one, fall more on Steve’s side. In 1998, a presenter at SD East spoke on implementing reuse in a corporate IT shop, and his experience at several large firms was that marketing and communications was the number one factor in achieving success. I tend to agree. The degree of communication across IT groups is simply not what it needs to be to foster reuse. Dion dismisses this, and more blames it on “software that is actually extremely hard to mesh together.” Here, I disagree. I don’t think that integrating a typical corporate Web Service using SOAP/WSDL is all that more difficult that integrating a REST-based service, especially for system-to-system interaction. I’ll give REST or simple XML over HTTP the nod for AJAX-to-service interaction.

Dion does make some good points that corporate developers do need to embrace, however. He states that “Web 2.0 approaches to service design dictate an almost extreme preference for encouraging unintended uses.” Here, he hits the nail right on the head. Roy Schulte commented in a webinar that we need to switch from “build to last” to “build to change.” If an internal IT team builds a great service, they need to understand what it means to be a service provider, and encourage any usage they can get. If they take a rigid stance with regards to their customers, they won’t be successful.

Where I see the gap in this debate is really the cultural differences between Web 2.0 development and corporate development. Corporate developers are working to the demands of the business according to a project schedule. I’m willing to bet that the typical Web 2.0 Google Maps mashup is not, or at least not in the early days. On top of that, the mashups are creating new applications out of existing parts that would be too expensive to go and build from scratch. I don’t think any Web 2.0 programmer (unless they work for MapQuest, Yahoo, or the mapping provider…) could go out and write Google Maps on their own. For the services being reused in corporations, this isn’t the case. Often times, the developer has everything they need to write it themselves. In this situation, it absolutely is about marketing and communication. If the developer doesn’t know someone has already done it, they’ll go off and do it themselves. If they do know it exists, now it’s more of a trust and control issue.

In the Web 2.0 world, we’re encouraged to communicate, socialize, and share. (hmmm, isn’t this what Steve was saying is a critical factor?) If the service needs to be tweaked, we’d contact the service provider and get it tweaked. Even in the Web 2.0 world, if the group was unresponsive, that service will quickly fade away.

In the corporate world, the team providing the service does not have resources assigned to that project, and this makes project managers very, very nervous. They’re now dependent on something outside of their control, and unless the corporate culture changes to allow that, they may be apt to do it themselves, strictly to control their own destiny. If your organization can’t built the internal trust to get over this, they won’t be successful with SOA.