Social Glass

No, this is not another post about combining social bookmarking and enterprise search. Instead I wanted to highlight how the social dimension of enterprise search - the search terms people use and the links they click as a result - can add to the effectiveness of an enterprise search solution.

The idea is simple:

1. Capture “fruitful” search queries - queries that cause a user to actually click a search result.
2. Capture the link, title, query and timestamp for each search result a user clicks. This can be done by re-writing the URLs to post to the search application first before redirecting to the original link.
3. Display the number of times a document has been viewed (”views:5″, as is the case with the first document in the screenshot). Documents that are viewed more than others tend to be more helpful, and this information can be useful when determining what to look at.
4. Massage the search statistics so that popular search terms are displayed in a “Search tag cloud”. This lets the user knows what the enterprise is looking for and helps create stickiness.

“Rabble” is a simple proof of concept that we developed in Ruby on Rails, and we could probably do a lot more with it. It integrates to a Google Search Appliance on the backend, and I’ve discussed how to do this integration before.

Interestingly, much of the information captured by Rabble exists inside the search appliance, and yet there’s no API to access it. Hopefully such an API is on Google’s roadmap, as information about user behavior can go a long way toward adding a valuable social dimension to enterprise search.

I’d often wondered if SaaS (Software as a  Service) could provide all of the features/capabilities required to support and operate a business.  It seems the answer is yes.

Joe McKendrick has written about Ismael Ghalimi who “documents all the Office 2.0 tools and technologies you could ever need to avoid bloatware of any kind and run your business entirely from services delivered over the network” (SaaS).  Check out Ismael’s list here.  It’s worth a read, especially if you’re thinking of starting your own company and don’t want to worry about IT.

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.