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.

On the topic of enterprise architecture, some colleagues of mine talk about defining a corporate lexicon to outline what a business does, or wants to do, as a business. The aim of this activity is to arrive at a desired future-state where the business can talk about its core functions in a language that is not tied to its operational or business support systems. The language becomes an abstraction on top of those systems, and further analysis shows where core systems don’t support the corporate lexicon.

Let me give you an example of what I mean. Being a linguist at heart (I majored in Spanish in university) I thought I might simplify this approach by defining several business requirements for a telecommunications company:

1. Provision broadband internet for residential customers.
2. Provision broadband internet for small business customers.
3. Send customers an invoice monthly.

The first thing to notice is the lexicon has been standardized. When I mean “provision” I say “provision”, not “activate” or “setup”. “Customers” are not “clients” or “accounts”.

Next, sentence structure. All of the nouns in this sentence represent core data entities, the adjectives (attributes of the nouns) represent types that extend the core data entities, and the verbs represent actions that can happen to the object pronoun (data entity) of the sentence. Each of these needs to be supported by the enterprise architecture.

Let’s analyze the first requirement more closely: Provision broadband internet service for residential customers. Verbs are highlighted in yellow, adjectives in green, nouns in blue and prepositions in red.

• There are two core data entities, “service” and “customer”.
• We need a provisioning business function for services (”service” being the object pronoun of the sentence).
• “service” entities can be of type “internet”, and “internet services” can be of type “broadband”.
• “customer” entities can be type “residential”.

Furthermore, prepositions show us relationships between core data entities. In this case we see that “customers” and “services” have at least a one to one relationship (meaning a customer can have at least one service).

Applying the same analysis to all of the requirements, we’d end up with the following, semi-normalized data model:

We’d also end up with two business services (think SOA), one that sends invoices on a monthly basis, and another that provisions internet services.

Sure, this is simplified, but the requirements gathering process, when done in this way, can tell an Enterprise Architect a lot about the core data entities and functions an organization needs to support to do business. He can then perform a gap analysis to understand where his current-state architecture is deficient in supporting this future-state view.

• Knowledge Workers access the E2.0 suite through a consolidated UI that sits on top of all of the applications
• Applications integrate to the suite through a library of standards-based APIs and widgets.

I’m very optimistic about Enterprise 2.0 and actively seek to promote it internally and externally. We use social collaboration tools for projects, proposals, price lists, user groups, minutes etc. in a very ad hoc, non-official way. The result, and this is largely because we’ve bypassed IT for all of this by procuring domain names and servers outside the firewall, is I have 9 different systems to login to to collaborate on different topics. Each system essentially represents a loosely defined context boundary (i.e. project). This becomes very confusing for me and other users. And I’m sick and tired of setting up accounts on each of these systems every day.

This is what happens when we bypass IT to generate our “Enterprise 2.0 emergent collaboration platforms”. In light of a recent post by Andrew McAffee and another by Shiv Singh, IT does play a significant role within an organization (especially a large organization), and we need to embrace this to avoid the collaboration hell that I’m in. Misguided though they may be, I’d much rather transition the administration of our collaboration systems to IT. Let them provision new users. Let them backup the data. Let them schedule outages for upgrades.

Within my organization we’re working hard to socialize the benefits of socially-oriented collaboration tools and have made great progress with our initiative. But an interesting dilemma has surfaced, and I’ve read about this happening elsewhere too (but I can’t remember where - otherwise I’d link to it). The dilemma revolves around whether an enterprise should focus its energy on promoting a single instance of a collaboration tool (i.e. wiki), or if it should instead embrace wiki federation. The inherent benefit of having everybody use a single instance is, of course, that all collaboration occurs in one spot. This makes it easier to find content and people since there’s only one place to look. From an IT perspective this approach also makes sense as it consolidates governance of the tool and makes it more manageable.

But the “single instance” approach might be more of a utopian ideal. We often talk about having a bottom up, non-sanctioned approach to Enterprise 2.0 adoption. Bottom up often entails disparate groups creating their own collaboration environments for specific needs, and the result is wiki proliferation. And I’m not sure there’s much corporate IT can do to keep this from happening.

So, pragmatically speaking, it makes sense for the enterprise to embrace wiki federation. This can be accomplished through Enterprise Search. Slap a Google Search Appliance or FAST instance inside the firewall, point it to the federated wikis, and we have discoverability across all collaboration tools. This negates the impetus behind moving the enterprise toward a single collaboration tool instance. Of course the challenge here is to keep the search index up to date with all of the new wikis that popup. But that’s why we have IT guys.