(…continued from Part 1)

Striding boldly from the wreckage of voracious consumerist discountlust, I head toward the checkout. Glancing down at the sled, I am satisfied with my impending purchase. It is in a word…solid. I approach the line which seems to disappear over the horizon and while waiting for my turn my mind of course wanders into the geeky land of E2oh…

It occurs to me that my journey to find this sled is not too dissimilar from an almost daily frustration of finding information within corporate and government monoliths. I have harped on this issue before but here is what I go through when asked to “go find something”. For the purposes of the dialog below, consider Longfellow anyone who has created information alone, then it stored it in a traditional document management app in order to “share”. (So…like almost everyone in your organization. )

Longfellow: “Hey Nate…when you are done with your nap can you take a look at the deliverable I prepared? Would love some input.”

Me: “Sure no problem Longfellow. I assume you have put this wonder of consulting somewhere I can find it, right?Oh…and…uh…sweet ascot.”

Longfellow: “Thanks. My father Higginsly bought it for me. Yeah… the deliverable is uploaded to the DocuPointShareFireStormDrain site.”

After an interchange like this, I would search for the link to the aforementioned “place” where hopefully I am met with the delight of reading something worthy of Longfellow’s bill rate. Instead, I am presented with this:

Man...look at all that KNOWLEDGE to manage.

Hmmm. Ok. So now what? Clearly whoever designed this folder structure knew exactly how I would categorize information. So this should be easy, right? I should be able to flawlessly navigate directly to this deliverable and life will be good. And so we begin:

1. Click, click, click…not there….expletive.
2. Click, click, click….not there…expletive, expletive.
3. Click, click, click….not there…expletive, expletive, expletive.
4. Enter presumed keywords into search box. Dizzying list of irrelevant junk. More expletives.
5. HR rep stops by the desk. Still can’t find deliverable but am now up to speed on firm policy for professional behavior.
6. Call Longfellow. He stops by.

Longfellow: “Hey Nate…can’t find the deliverable? Weird. I thought it was pretty apparent where it would be. Maybe you just don’t understand how best to organize information.”

Me: “Hey Longfellow…yeah can’t seem to find it. Why don’t you give it a go? And maybe you just don’t understand that I might hobble you when we are done here.”

Longfellow clicks about 37 times and we are presented with this (his deliverable is highlighted):

Totally my fault.

I am sure you can imagine the rest of our interchange.

Sure, for the sake of argument Longfellow could have sent me a link but quite frankly that rarely happens. People tend to just state that a certain piece of information is “up there” and expect you to find it. Or even more frequent is the self-prompted need to find something. Either way, there are major issues with this approach constituting the reasons why I have abstained as often as possible from using platforms like this as a way to author and collaborate on content.

• We Need a Better Structure – Typically people will point out that the problem with me (or anyone) not being able to find anything is the fact that the structure or hierarchy (taxonomy) is flawed. Unfortunately this is merely a symptom, not the root cause. Hierarchies often break down because either the person/people who created them perceive information categories differently than the people who use them. It becomes an almost intractable problem when the data set you are trying to categorize approaches any decent scale. Your folder structure on your laptop works because you are the only user and your data is the only thing being organized. But then you get asked to create something like the picture above and scratch your head when I can’t find anything. Want a bigger example of this? You use and find things in the largest data set in the world on a pretty frequent basis. But how often do you use a folder structure instead of search? I would guess never. Traditional, single dimension hierarchies just do not work. Not to mention the fact that it is a holdover from organizing physical information in actual file cabinets and folders. Think about my experience shopping for sleds. The hierarchy I was presented with was designed to 1) hold physical goods, 2) keep me in the store as long as possible, and 3) make me walk through other stuff that I might be tempted to buy. Great for a store, but drop dead ridiculous for efficiency in the workplace.  You are not Henry Brown. Don’t try to be.
• The Search Doesn’t Work – This one is a bit more difficult to tackle. I am a big fan of the search not store mantra but with a caveat or two. One of the reasons search works on the WWW is because of links. The links between bits of info help with determining relevancy, popularity, and a few other things I am sure the smart folks at Google could tell you about.  I think that search tends to fall down a bit without links. In other words, almost all of the corporate stuff you produce. Unless you are creating web-based content and proactively linking (as if you were creating content on the WWW), you may find your stuff…well…hard to find. That being said, it isn’t that search doesn’t work…it’s that your content is not really designed to be found.

So next time you find yourself at a SUPERTARGET or authoring some sort of deliverable, think about the full lifecycle of your stuff. Not only does it need to be created, but it needs to be found. Keeping that in mind from the minute you begin spewing brilliance through the keyboard will at least keep me off probation for shouting obscenities at my laptop and at best, get your stuff found by people who actually might need to use it.

(This post is somewhat related to a post I wrote for Future Changes.)

Howdy Folks…we have a new author joining the crack team at e2oh – Marc Vogtman. Content below is his first post. Welcome aboard, Marc!

- Nate

My Deloitte colleagues, Kate Thompson, Nate Nash, Sam Lampert, and I just attended the fourth annual ICEGOV conference, held in Beijing this year. ICEGOV is a fairly new conference series established by UN University that brings together academics, government representatives, and private companies who have an interest in e-government. This is the first year Deloitte has attended and we did so to present two papers we submitted for the ICEGOV 2010 publication.

It was a pretty interesting week. Beth Noveck, Deputy CTO of the White House’s Open Government Initiative, was one of the keynote speakers and she really drove home the challenges and the goals of interconnected, transparent, virtual government. A major theme, across multiple sessions, was interoperability. Needless to say, this is a huge and complex topic. The goal of allowing people to collaborate and share information within and across government entities requires consideration of organizational, legal, public policy, and technical interoperability issues.

In our business, and particularly in Emerging Markets, we spend a lot of time on the first three. The general consensus seems to be that technology, while important to interoperability, is kind of a given; we have the tools, but successful information sharing hinges on people and process. One set of presenters, Professor Jim Davies and Dr. Steve Harris of Oxford, began their talk by challenging this contention. Yes, people and process are a big part of the process, but are there technology solutions we haven’t considered? There will always be human failure around technology and that’s not something over which we, as development professionals, often have a lot of control. So how can technology be better? How can it control for human failure?

The answer, according to the presenters: computational semantics. You may have heard of this sort of work in the context of semantic web (aka web/enterprise/government 3.0). The basic idea of semantics is that systems should contextualize stored information using machine-readable metadata that enable other software to access that information more intelligently. The idea of computational semantics is that this process should be automated and integrated into the development of ICT systems. This will help minimize the effect of human failure from the developer down to the user. Really fascinating stuff and progress is occurring rapidly.

So, is computational semantics the answer to the problems of interoperability and progress in e-government?

YES!

Well, actually, the honest answer is I have no idea. I’ll leave that question to the software engineers and information theory Phds. But the work in semantics is relevant to us. The government may not be ready for the transition to 3.0 technologies for another decade, but the principles of semantics – of a global methodology for contextualizing data for interoperability – are already implicit in the business opportunities being presented to us. As it turns out, one of the papers Deloitte presented at the conference (written by Sam Lampert) was on the National Information Exchange Model (NIEM), a semantic framework created by DoJ and DHS to “develop, disseminate and support enterprise-wide information exchange standards and processes that can enable jurisdictions to effectively share critical information.” NIEM doesn’t yet support the kind of automation described above, but it’s definitely a first step. And it indicates that the principles of semantics are becoming the default way of framing the problem of interoperability and data sharing. We need to think about how this affects the services we provide.