So how can web technology help address the problem of paper shuffling? To recap the previous post, the three key problems are:

1. Tracking documents.
2. Versioning documents.
3. Locating documents.

Let’s tackle these problems in reverse order. The web has a simple solution for locating documents: the Uniform Resource Identifier, or URI. You might have heard it called the Uniform Resource Locator, or URL. The two concepts are closely related, but the differences aren’t important for this discussion. Unique Ids are nothing new; record numbering or library classification schemes like the Dewey Decimal System have been around for a long time. But the URI standard supported by the W3C is the first such system to be truly global.

It’s more than a classification system, however. It’s an addressing system. In addition to assigning a unique Id, a URI tells you how to access the document. It also tells you where it lives and who owns it.

For instance, the URI http://www.microsoft.com/en/us/default.aspx tells us that a unique document named default.aspx lives at the domain named www.microsoft.com. If we look up the domain name, we’ll find it’s registered to Microsoft Corporation of Redmond, Washington, United States of America. It also tells us that we can interact with the document using Hypertext Transfer Protocol, or HTTP. That’s a lot of information in just a few characters. It’s a simple yet powerful system.

If we want to take advantage of this well understood and widely adopted international standard in the enterprise, we need a way to assign a URI to every block of information that has importance to the business. Many existing enterprise content management tools already do this, Microsoft SharePoint, EMC Documentum, and Oracle Stellent being the big three. But all three of these tools ask employees to do something very odd from a web perspective: They ask that the employee send their local files to a central server in order to get published with an addressable URI.

This is weird. We don’t email our public web pages to Google in order to have them appear in its index. Why do we send corporate documents to a centralized server? “To give it its unique number,” an organization’s records manager might reply. But this is old-school thinking; We’re not talking about a librarian stamping a number on a physical book.

It’s far easier to move a unique number from a central server to a workstation then to transfer an entire spreadsheet from a workstation to a server, only to pass it back again so that the employee can continue working on it. In other words, have the librarian send a sticker with the URI on it to the worker and let the worker slap it on the document. The label’s much easier to ship than a book.

But that approach is old-school thinking, too. We don’t need to move the book or the unique identifier: We’ll let the workstation create its own URI.

On the Internet, when you want a document from Microsoft, you type http://www.microsoft.com into your browser. Why not go to http://mary.mycompany.com when you want to get a document from Mary in Accounting? The same technology that makes the “big I” Internet work can make our “little i” intranets work, too.

All we need is a small program that assigns a URI to an employee’s documents and allows the employee’s workstation to act as its own webserver. Naturally this program needs to be secure, but we have two advantages. The first is that an organization knows its members. Nobody can log into the corporate network without a valid user account. On the public Internet, everyone is anonymous, but on your intranet, you can identify all of your coworkers. Second is that the same corporate firewall that prevents network attacks from the Internet can also prevent leaks coming from your intranet. (You do have a corporate firewall, don’t you?) With a few sensible precautions baked into this mini-webserver, you’ve neatly solved the addressability problem.

The system is remarkably intuitive. If you know Bill was tasked with coming up with the latest marketing presentation, you won’t have to search a vast corporate repository for it; You’ll find it on his machine. When Steve finishes work on his policy memo, he doesn’t have to upload it to headquarters and remember where to file it. He just asks this little program to publish it. Ding! Now it’s got a unique number and it’s available for all to see.

That’s how we’d solve the problem of locating information: It’s easiest to locate information if you never need to move it in the first place.

Continue Reading

With my background in Enterprise Content Management, one of the blogs I’ve been subscribed to for a long time is Chuck Hollis, from EMC. EMC Documentum is a competitor for my former employer, TOWER Software, so back then, it was prudent to keep an ear out for those guys. As my focus moved away from ECM and towards Enterprise 2.0, I kind of stopped reading his posts regularly.

Which was dumb, because, as I found out from Jeremy, it turns out that he’s just as excited about emergence and social media in the enterprise as I am. So much so, that he’s started a dedicated blog detailing the deployment of Jive Software‘s Clearspace within EMC.

The immediate question for me upon hearing this news, was, “Huh? EMC already own two products that claim to be able to do this stuff.”

Documentum Collaboration and eRoom were both touted to “enable distributed teams to work together more efficiently”, and yet EMC’s selected product was neither of those. They opted for a third party solution outside the ever-growing catalog of EMC Software.

After catching up on about half-a-years’ worth of posts, I found the answer, beautifully identified by Chuck himself in this post. After discussing Transactional Collaboration (workflow), and Document Collaboration (sharepoint, eroom) he goes on to discuss what he called “Social Collaboration”:

…Doing it in the margins between meetings isn’t efficient or productive, and having formal “brainstorming” sessions doesn’t always feel quite right. And if someone schedules another conference call, I’ll cringe.

It’s not predefined interaction. It’s not a structured workflow. It’s something entirely different than the other two collaboration models. It’s people talking with each other about what’s interesting — hopefully in a work context.

Brilliant! That’s exactly what it is. It’s about knowledge workers being able to share, discuss and distribute the things that they know and care about, without being shoehorned into a process box, or a pre-defined meeting space.

The most productive information enterprise is the one with the smartest, best connected people that can adapt and make the best decisions. Not the one with the biggest, most perfectly enforced quality procedure manual.

Chuck, welcome back to my collection of must-read feeds.

Oh, and speaking of those, Sam Lawrence from Jive Software also shares his experience with the EMC deployment over on his blog, Go Big Always.

Continue Reading

We’ve mentioned before that computers don’t think the way people do. A simple example of this is that your PC doesn’t understand how to move something. For a typical operating system, a “move file” operation is actually composed of two steps: copy and delete. The original file is copied from one location to another and then the original is deleted, leaving only the new file in a different place.

That’s all the computer knows. If you ask for the original file, the computer tells you it doesn’t exist. As far as it’s concerned, it might never have existed. Maybe you got the name wrong. Maybe you got the folder wrong. Maybe you imagined it. All you’ll get in response from the computer is Bad Command or Filename, the computer equivalent of saying “Dunno, boss” and shrugging.

Keep in mind that the computer’s not trying to be unhelpful; it just doesn’t know what happened. It sees the world differently than we do. The way it moves things is not how things move in the real world.

It went that-a-way…

If this sort of thing happened in real life, the document lying on your desk might suddenly vanish in a flash of light, and a new document might materialize out of thin air in the conference room.

Are they the same? If you walked into the conference room and picked up the new document, how could you tell if it was the same as the one that vanished?

You’d have to search your memory to figure out whether this new document matches up to what you remember of the document that left your office under mysterious circumstances.

This is exactly the problem that computers face all the time. Without going through the system logs, or comparing a system backup to the current state of the system, there’s really no way for your computer to know whether the document in the conference room was the same as the one on the desktop, whether it was a different version of the same document, or whether it was a different document altogether.

Now imagine that you’d told Sally, a coworker, about the document on your desk. After the mysterious document transfer operation, she walks into your office to have a look at it. But it’s not there anymore. It vanished without a trace. She’s got three options: First, she can assume you threw it out and the file is no longer available. Second, she can assume you moved it somewhere. She could begin searching the entire building for it. Third, she can wait until you get back to your office and then ask you what happened to it.

The third option is what most organizations rely on today. Sally might have a peek into your office to see if the file’s there, and if it isn’t, she’d send you an email to ask about it. Most of the time, though, she saves herself a walk down the hall and just sends the email. Since you’re the only person on the planet that knows the file mysteriously reappeared in the conference room, she’ll have to wait until you get back to your computer to find out what happened. Then you can reply to her email with this amazing story of the disappearing-reappearing weekly sales report.

You can almost hear her voice on the other end of the phone now, “Uh huh. Magic. Really. That’s great. Look, just send me the figures, OK? I need them right away.”

But again, how do you know — and how will Sally know — that the document you found in the conference room is the right one, or the right version of the right one? You don’t. You’ll both just have to hope that it’s the same.

The next day, when Pete reviews the numbers in the team meeting, he looks at the paper Sally handed to him. He shakes his head. “I’m pretty sure I updated these yesterday.” You’re just about to tell him this absolutely amazing story when Sally glares at you and kicks you from under the table. Another lousy day at the office…

Three real-world problems

The story highlights three critical information management problems:

1. Tracking documents.
2. Versioning documents.
3. Locating documents.

Since computers aren’t doing these things for us, we have to figure out ways of doing them by hand. As most of us discovered decades ago, email solves the second problem fairly well. Every email is date-stamped with the time it was sent and the time it was received, so you’ve got a good idea of how recent the attached documents are.

Email partially answers the third problem; if you can remember to whom you sent a document, they might be able to retrieve it for you using whatever memory aids they find effective. Sure, using email for this purpose is slow and annoying for both you and your coworkers –

“Hey, uh, could you send me that presentation again? I can’t seem to find it…” –

“Oh – I think it’s in my Sent Items…”

…but it seems to work a fair amount of the time.

That leaves the first problem, for which email is almost totally ineffective. Once you send a document out, there’s no telling who it could be forwarded to, or when you’d get a reply back, or whether you’ve actually gotten a reply back to an older message with an out-of-date copy of an attachment, and so on.

All three problems can be summed up in one short phrase: paper shuffling. Paper shuffling is the bane of the knowledge worker’s existence: It’s tedious, boring, tiresome drudge-work. This is not what your well-educated, well-paid creative staff were hired to do. It’s not what knowledge workers want to do. Yet lots of their time is spent doing it.

Recent studies claim that knowledge workers spend more than a quarter of their time in email applications. How much of that time is spent on fixing the three problems above?

And all because our current computer operating systems don’t understand basic operations like move.

Continue Reading

So what are you guys actually doing?

Gordon and I have heard this question a lot lately. Friends, family, and former coworkers have all asked us. We’ve been cagey so far, mainly because we weren’t sure we could bring all our ideas together and make them work. But we reached a major milestone last weekend: Our core API now passes all of our unit tests. Now that we’ve got a solid foundation in place, we can see how the rest of the structure fits together. So it’s time to start talking about what infovark is all about.

In one way or another, Gordon and I have worked on enterprise software systems throughout our careers. We’ve built them, implemented them, sold them, trained folks to use them, and provided technical support for them. And if there’s one thing we’re both sure of, it’s that “enterprise software” today is an unmanageable mess. There are a lot of reasons for this, from battleship gray syndrome to dysfunctional procurement to poor change management techniques. Also, good intentions aside, the analysts and vendors don’t always help the equation either. So we’re throwing the old approaches away and starting again.

The main problem with enterprise software is that it’s targeted at an ill-defined customer: the enterprise. The enterprise is not a single thing; it’s a collection of things. It’s the people, policies, practices, strategies and culture that together comprise an organization. Most business software is targeted at the policies, practices, and strategies, but there’s really only one item in this list that matters: the people. Everything else is an emergent property that arises from the interaction of people.

In my time as a management consultant, I was “the flowchart guy”. My job was to produce elaborate wall-spanning diagrams of the procedures and processes that our clients followed, so that we could see points that could be improved. I sweated over these diagrams; I interviewed people, watched them work, and took pages and pages of notes. I developed a detailed knowledge of how all the pieces fit together. After several weeks of drafting and revisions, I’d present these works of art to our customers.

Most of the time, the charts that I made were reviewed with surprise. “Oh, that’s how it all works!” was one of the typical comments. Then I’d begin pointing out areas where improvements could be made. I was usually disappointed with the outcome of those meetings, because the most common result was to roll up the detailed diagram I had so labored over and file it away, never to be seen again. Business carried on as usual.

Years later, I’ve come to realize two things about those diagrams.

1. Our clients didn’t need my flowcharts in order to operate a successful business. The procedure manuals weren’t guides that workers referenced in order to do their daily tasks; they were merely descriptions and distillations of corporate know-how, written long after employees had figured out what needed to be done. The companies managed to function even though many had no idea how their internal processes actually worked.
2. Flowcharts bear the same relation to an enterprise as the Platonic ideal of The Circle does to a wheel. It’s an abstract model that never truly exists in the real world. An actual wheel is very rarely a perfect circle, and in some cases a perfect circle would be less effective. In the case of the wheels on your car, you get better traction if the tires flatten out on the bottom, to put more of the wheel in contact with the road.

Traditional enterprise software typically looks at the structure, policies, rules and norms of a business and codifies them into software. It tries to build a functioning real-world system from abstract principles. At best, this approach creates a short-lived tool that works only as long as those practices remain the same. But in many cases, the practices change all the time because the business environment changes all the time and the people that comprise the organization change all the time. It’s like the old proverb: you can never set your foot in the same river twice. Even if an enterprise solution could be precisely tailored to meet your businesses needs today, tomorrow is a new day.

Incidentally, this explains why most enterprise software has eight zillion configuration options. It also explains why you need a team of experts to implement an enterprise system. You’ve got to take that idealized flowchart and make it real. You’ve got to tweak the settings so that it matches up with the way the business actually operates. And here’s the dirty secret of enterprise software: you’ve got to keep tweaking it. You can’t just bring in a team of experts to set up the system initially; you’ve got to make sure the system continues to align with the way you do business. That means you’ll be reconfiguring the system all the time. When you buy one of these systems, you’re buying it for the long haul, and you can expect significant and ongoing maintenance, training and configuration costs. And that’s a best-case scenario. A worst-case scenario is that the system actually stands in the way of getting the job done. It will limit the flexibility of your knowledge workers to try out new approaches. When your business needs to change, you’ll be stuck with a rigid program designed for the way your business operated at a single point in time, several years ago.

So if we can’t design enterprise software to capture those ineffable emergent properties like “best practices” or “corporate culture,” how can we design these systems? We have to go to the source: the people that comprise the organization.

If you watch a bunch of kids on the playground at recess, you’ll notice patterns and order emerge. Groups will form, ideas will be shared, norms and rules established. These things happen naturally. The same is true of enterprises, businesses, organizations and associations. If you want to get enterprise software to work properly, you’ve got to focus on the interactions of the individuals involved. If you want your employees to share information more effectively, find out what would motivate Bob to share his weekly sales figures with Mary. Construct the system from the ground up.

We’re doing this at infovark by building an information handling tool that solves key issues for today’s knowledge worker. As a consequence, it encourages practices that benefit the corporate community as a whole. What we hope will emerge from this approach is a transparent, open culture of communication and collaboration.

I still haven’t gotten around to discussing the specifics, have I? We’ll get to them in future posts, I promise.

Continue Reading

My wife Alison occasionally asks me to remember stuff for her. Just yesterday, she said, while we were out “Remind me to ring the bank when we get home”.

I nodded amicably.

As a general rule, this probably isn’t the best way for her to retain a piece of information. I’m easily distracted by shiny things, I routinely forget stuff, and as much as I’d like to, I can’t assure her that I’m actually going to retain the information.

Worse still, I’m almost certainly going to give the same response to every request (an amicable nod) regardless of whether I’m actually going to remember it.

If you want information to be retained outside of your head, you should really write it down. Paper records of information are much more reliable than memory for recall. This notion of recording and managing information is central to the way people work. Since we started Infovark, I’ve had to manage more paper than I ever have before.

If you’re a knowledge worker, chances are that managing this information is essentially all you do. You write messages and documents, you go to meetings, you visit customers, you coordinate with coworkers, you take notes, and you use your brain to make decisions based on all of that stuff. It doesn’t matter if you are working in an industry or a more creative pursuit, you’ll still find your share of forms to fill in and documents to submit.

Computers changed the way enterprises work, because information artifacts that were once recorded on paper started to be recorded digitally instead. This saved space, and sometimes time, and often made it easier not to lose things. It also had two other advantages. First, paper can only be in one place at one time. It has to be physically transferred from one location to another, and generally moves at the speed of a truck. It’s far easier to move electronic bits around and they travel at nearly the speed of light. Second, it’s expensive and slow to duplicate information on paper. Making electronic copies happens at much faster rates and is such a trivial operation that computers do it all the time, usually without you knowing about it.

At first, enterprises thought that storing a record on a computer was a thing. It made sense at the time since disk space was at a premium. Our legacy thinking meant that we treated business artifacts as much the same, regardless of the medium (ink-on-paper or bits-in-transistors) that it was stored in. An enormous amount of time and energy was spent on implementing elaborate control systems to conserve disk space, just like we used to fret about running out of space in our file cabinets or bookshelves.

Nowadays, disk space is cheap. A 500 Gigabyte drive costs $99 at the local MicroCenter. As Nick Galemmo notes over on ITtoolbox, the same amount of storage in 1980 would have cost around $250,000,000. So if there’s one thing that we can afford to do with modern computers, it’s store stuff.

One of the defining trends of Enterprise 2.0 systems is that they store stuff. They store stuff regardless of whether it is finished, or a “proper” version, or a snippet of a comment, or a draft. They store the same thing multiple times, often in multiple places. They record silly things like employee blog jokes, and wiki pages that nobody will ever look at again. They capture recklessly.

Reckless capture is the concept that led Google to its position today. It’s what Sharepoint does with all those team meeting spaces. When in doubt, store it anyway.

At first this might seem frivoulous — wasteful, even. But in addition to storage, one other thing that computers could do well is separate signal from noise. And when it comes down to it, what you want from your system is answers, not efficient use of space. You want tools that help you make decisions. Get things done. Connect with people.

A lot of the reasons for the surge in virtualization technology comes from the fact that a lot of servers in server rooms all over the world are underused. They are super powerful, with loud fans and scary blinking lights. They live in their big, cold, antiseptic server rooms. Do you know what they are doing? Most of the time, not very much at all.

So, let’s capture as much of these information artifacts as we can. It’s not going to hurt the bottom line, and it can only help productivity. After all, nobody ever found a useful document lying around on a network share and complained about wasted disk space. Let’s give those massive servers something to do.

That reminds me, I gotta remind Ali about something…

Continue Reading