Social Glass

I came across a post from Dion Hinchcliffe recently that talked about ideas for SOA architects in 2007 (ok, so it’s a year old). Dion talks about how Web 2.0 philosophies can be leveraged to enhance the effectiveness of SOA. The recommendation that stood out to me was “Deeply Embracing URI Addressability”, where Dion argues:

The hyperlink is the fundamental unit of thought on the Web and it should be in your service designs and (hopefully granular) schemas as well. Giving each discrete piece of information, every service, and all content a globally addressable URI instantly gives a service, and the data it carries back and forth across its interface, access to countless new consumption and reuse scenarios.

To illustrate how unique addressability might work, consider an organization that sells insurance to customers. Each customer is given an account number. The organization has an SOA strategy and decides to make use of REST (Representational State Transfer) to expose its information assets, including “customer” in an interoperable manner.

REST “strictly refers to a collection of network architecture principles that outline how resources are defined and addressed” (Wikipedia). It also makes use of the HTTP verbs POST, GET, PUT and DELETE (similar to database CRUD operations) to define what action to take on a given resource.

The insurance company develops a REST interface that sits on top of its CRM system. Customers become uniquely addressable by account number, as follows:

http://insuranceco.corp.com/customer/9886574

where “9886574″ represents the account number for a particular customer. A “GET” request (similar to READ on a database) to this URI might return the customer profile and claim history.

This is what Dion means when he says information should be uniquely addressable. Each customer has his own URI, which means behind the firewall other applications can reference a customer using this address. From here the possibilities are endless, where the intranet starts behaving like the internet. Information assets begin having inbound links, and this “democracy” so famously publicized by Google’s PageRank algorithm (where an inbound link counts as a vote) starts to apply not just to web pages, but to entities abstracted by services in an SOA (like “customer”). In this way information can be:

• Bookmarked in a social bookmarking system. Users include comments, like “Harry Young [customer 9886574] calls in every week and I’m tired of dealing him”. Users also tag these resources in the social bookmarking system, i.e. “disgruntled”, “customer”.
• Searched through an enterprise search engine. Adding “http://insuranceco.corp.com/customer/” to the seed of our enterprise search engine causes all customer information to be natively crawled and indexed.
• Referenced from wiki and blog posts.

As a blanket statement I’d say that any SOA architect should strongly consider exposing resources in this manner so that he can leverage the network effects and unintended uses that are achievable through unique addressability.  Good stuff Dion.

Joe McKendrick hit on a great point when he asked “Is Gartner telling us to ‘make sure there are adults in the room’ before launching into Web 2.0 activities?”. Joe goes on to point out that “All the excitement around various aspects of Web 2.0 may truly be a distraction from SOA”. Mashups, or web-based applications that bring together functionality from multiple systems to do something in aggregate that they do not do on their own (think twittervision), require a mature service oriented architecture from which said functionality can be sourced.

We talk so much about widgets and web oriented architectures (the visual aspect of SOA) that we forget about the significant investment that companies must make to deploy enterprise mashups. I touched on this a few weeks ago, but Dion Hinchliffe mentioned that an immature services landscape is a major barrier to mashup adoption. He writes “Mashups are predicated upon the ready preexistence of ready-to-use Web services and network APIs which are ready to be used to build on top of.”

In other words, if I want to create a Customer Search widget I’ll need to have first developed an interface into my customer database of record that, oh yeah, was programmed in Fortran in 1978. That costs money, and in my experience a lot of companies just aren’t there yet.

Joe McKendrick over at the FASTForwardBlog had a great post about the generous tolerance levels us users seem to have with SaaS products. In it he compares the high standards we’ve come to expect with “thick-client” software and how those standards are relaxed a bit with the “thin-client”, or client-server, approach . And I quote:

We’re still enamored by the flexibility and simplicity of the Web 2.0 and SaaS models, and I’ll take them any day over the CD packs and installation headaches of old. But it’s time to start holding vendors’ feet to the fire over the quality of these services being delivered, just as we did in the days of old. Whether the code is inside our machines or out in the cloud, we should expect and demand top quality and high performance.

Well said. There’s been discussion before and there will be discussion in the future about this topic, and how the word Beta is a disclaimer for “don’t blame us if it doesn’t work”. SaaS vendors, especially B2B SaaS vendors, need to get this one right. The quality needs to be there for SaaS truly to take hold.