April 2007

Knowledge and forgiveness

David Weinberger at KMWorld makes an excellent point about knowledge in a recent column:

Knowing is not something apart from forgiveness. Forgiveness is not merely something we do, external to knowledge. The knowing that matters requires forgiveness as its condition, just as it requires language and other people. This most obvious of facts sounds odd because we have so thoroughly demeaned knowledge by considering it to be mere content. But if it were only content, how could we distinguish the content that is knowledge and the content that is, say, propaganda or a joke? Knowledge is knowledge because it is embedded in a social system. Social systems are composed of humans. Humans are fallible, even when we happen to be right.

Therefore, there is no knowledge without forgiveness.

That might sound like a paragraph from a book on the philosopy of science, but Weinberger has a point that's important for collaboration, basic content services, and enterprise content management--in other words, the entire spectrum of activity around content, from the informal to the formal, from the free-form to the regulated. Every day, we're caught between the two poles of life that Max Weber (pictured to the right) described in "Politics As A Vocation" and "Science As A Vocation." At times, we have to get things done (politics). However, we also have to understand what we're doing, and share that understanding with others (science).

We face obstacles when we move along both paths. Not everyone wants to participate in a project, or think it's a good idea. Politically, we have to win them over. We also have to convince them that our understanding of the pertinent facts (how well our marketing program is working, what are the obstacles in getting our product manufactured at a lower cost, etc.). That step may require an admission that they were wrong in their cherished beliefs. What Weber says about teachers therefore applies to pretty much everyone in this position:

The primary task of a useful teacher is to teach his students to recognize 'inconvenient' facts--I mean facts that are inconvenient for their party opinions. And for every party opinion there are facts that are extremely inconvenient, for my own opinion no less than for others. I believe the teacher accomplishes more than a mere intellectual task if he compels his audience to accustom itself to the existence of such facts. I would be so immodest as even to apply the expression 'moral achievement,' though perhaps this may sound too grandiose for something that should go without saying.

We have to admit what when we're wrong, too. That principle applies whether we're preparing for an important presentation (collaboration) or preparing pharmaceuticals for clinical trials (enterprise content management). A shorter way of saying the same thing is, That's life. The tools you use can make your life easier, or harder. I hope that the ones we build make both politics and science easier.

Web 2.0 in the enterprise

I've read a lot of musings about Web 2.0 adoption in large organizations. The basic question is either, Are people using these tools? or Are these tools adding value? Mike Gotta makes a good point: we shouldn't be approaching these questions as if this is the first time anyone has struggled with collaboration tools..

The metadata-driven view

Mike Straus, product manager extraordinaire, just published his new project (code sample plus documentation) about a metadata-driven view of content in our system. Why is this interesting?

• It exposes the metadata entered for document classes (our term for categories) in a way that's immediately useful. Anyone looking for a particular piece of content, or interested in what's available generally, can benefit from this view.
• It provides a reason for entering the metadata in the first place. If you don't enter the metadata, your work won't appear in this view. If you do a lousy job of entering it
• Customers and partners have already built views like this one. For example, Time Warner built a much more sophisticated version of this view, but the point is essentially the same: let people browse by the metadata.
• The folder structure is increasingly less important than other views on the content. Everyone knows how to navigate files and folders, but this view of the content doesn't fulfill everyone's needs. Looking at a folder full of documents, I don't know who is their intended audience, what there topics might be (other than what the file name suggests), and whether they're really in good enough shape to use. To answer these questions, you need something like the metadata-driven view.
• Customer use cases often demand a metadata-driven view. That's effectively what the institutional repository solution provides, a metadata-driven way of browsing and searching library content. You can take Mike's code as a starting point for exploring the third option discussed in the institutional repository white paper (building this view of our system, instead of integrating us with a separate institutional repository application).
• We're building metadata-driven views for future versions of our product. We're not necessarily building something that functions in exactly the same way that Mike's project does, but there are plenty of other ways to use metadata (and other types of metadata). For example, you might use a metadata-filtering view, in which you click particular standard or custom metadata to narrow the list of files and folders that fit that profile. (Think of the way iTunes lets you filter music by genre, artist, etc.).

Take a look at Mike's project, and let us know what you think.

Shared areas, by the numbers

My friend and colleague Mike Straus has published a tech note about creating shared areas en masse. For example, you may want to create a common set of directories, configured in a particular way, for each department, as defined in LDAP. Mike lays out the options in this brief but helpful document.

Security web seminar

If you were interested in our security web seminar last week, here are the slides from it. As I said in the presentation, it's hard to find a success story with Xythos that doesn't address an important security concern.

The Swiss army knife of content

I carry around a Swiss army knife that was one of the best birthday gifts I've ever received. Where countless sweaters have been entombed in the back of my closet, the Swiss army knife's unparalleled usefulness compels me to take it everywhere. It's such an intrinsic part of my daily routine of stuffing things into my pockets as I leave for work that I have to be extra, extra careful to leave it at home before heading to the airport.

Obviously, I need other knives for many daily functions. I don't cut a steak with my Swiss army knife, and I don't fence with it. (Actually, I don't fence at all, but you get the idea.) I do use the Swiss army knife every day for cutting through packaging, opening bottles, loosening screws, prying open containers, or other challenges to a tool-wielding mammal like me.

Our products, the server ones in particular, are a lot like my Swiss army knife. You won't use it for everything, but you'll use it for a lot of things. That's the "basic" in "basic content services." If you want a templated web site, we'll be glad to point you in the direction of many excellent web content management tools that ably perform that task. If you just want a place to put a static HTML document and publish it to someone across the Internet, don't go yet--we can probably help you.

Here's where I have to make a small confession: our customers concoct uses for our products that we never imagined. That's probably no surprise, since that's the nature of product development. The person who designed the first jeep probably never imagined it to be the family car, but that's exactly what SUVs have become. I've hard of customers using the Xythos server for sharing course materials, processing insurance documents, maintaining a library of digital assets, and publishing file-based reports of row-column information from databases. I could list 17 other use cases, off the top of my head, but that would only be a fraction of the many uses to which customers and partners have employed our technology.

There's one key difference between the Swiss army knife and our server: you can't customize the Swiss army knife. Even the incredible Ginsu knife collection didn't let you build a special knife for a particular job, or replace the handle with one that fit your hand perfectly. On the other hand, you can customize our server; not surprisingly, nearly every customer does.

Being the "Swiss army knife of content" is pretty cool. I'd rather build that sort of tool than something that suffers the same fate as those sweaters in the back of my closet.

Fear-mongering

If you read our compliance-related marketing materials, you'll notice a theme that might not be echoed in the industry at large. As Doug Henschen of Intelligent Enterprise says, most vendors rely on the fear-sell for compliance. Law suits! Audits! Jail time! Angry investors! Godzilla!

OK, we can probably leave out Godzilla. Unfortunately, rampaging radioactive reptiles sound not much worse than the nightmare scenarios about non-compliance.

We strive to be consistent in both our design philosophy and marketing about compliance. You can't discount the risks of non-compliance, but you want to put compliance behind you as quickly as possible. An even larger fear than criminal and civil penalties is the loss of productivity. The motif is less Toho Studios, and more Kafkaesque: no one wants to live in a world where they waste time documenting what work they did today, archiving that documentation, documenting the archiving, responding to feedback about the documenting and the archiving, documenting the response to the feedback, scheduling meetings to review the archiving and documenting and feedback...This is the way the world ends, not with the bang of Godzilla's giant foot, but the whimper of bored, unproductive people.

That's yet another why you can't make compliance a separate application. It has to be embedded in the tools people use, in ways that are (in order of preference) invisible, helpful, or painless. Otherwise, you might as well slap a giant Portal To Hell logo on your "compliance application," because that's how your users are going to treat it.

[I can neither confirm nor deny that the previous post was a threadbare excuse to post a picture of Godzilla on this blog.]

The Age of Security

In IT, what's the definiing set of concerns in 2007? Most professional periodicals you read might emphasize Web 2.0 tools, such as blogs and mash-ups, or Web 2.0 technologies, such as Ajax. Another concern casts a shadow at least as large as Web 2.0, and in terms of real work done, may be more important: security.

Now, I'm not going to write one of those self-serving scare pieces that you'll find on vendor web sites (often in the same lurid tones as the movie poster to the right.) Exaggerated security concerns lead to misplaced priorities, but they also inflict decision paralysis. The risk of someone stealing personal information is a genuine risk. Is it a problem, however, if internal users can overwrite each other's changes? The most precise access control scheme might define exactly the privileges people should have on every piece of content, but it may make it impossible for users to work efficiently. In many cases, there's no substitute for trust.

Having said that, security factors into nearly every IT project. According to the customers and partners with whom we work, security is a higher priority than it was, or the concerns have new contours. For example, several years ago, ROI drove most vendor consolidation projects. IT managers were watching the bottom line, including the hidden costs of a best of breed strategy. Today, security is a dominant concern behind vendor consolidation questions we receive.

In point of fact, the real concern is application consolidation. How few systems will require our attention, when we do a security audit? How few integrations with the central LDAP service do we need to implement? When we need to deal with unexpected security challenges (for example, the next generation of denial of service or spoofing attacks), how can we limit the number of points of vulnerability?

As a vendor, therefore, we get security questions from two directions. The first is the traditional and obvious line of questioning: Are you integated with LDAP? Can you support single sign-on? Do you work across HTTPS? The second line is subtler, but definitely driven to a large degree by security: How many different business problems can you help us solve?

Of course, I'll toot our horn here. Since I track how customers and partners use our technology, I know initmately the broad array of different solutions in which Xythos technology plays a part. Ad hoc collaboration, digital libraries, document processing--these solutions, and more, have even more subspecies. Not only do we see customers use one Xythos server instance to address a particular business problem, but we also see many customers use the same Xythos instance to address multiple needs. The server that the entire company uses for day-to-day collaboration may also be an important part of how the HR department uses to move along the recruitment process.

Security shapes all of these solutions, to an unprecedented degree. Security limits the contours of projects, so that they will fit into the risk management box. Security determines the acceptable raw materials that go into a project, including the choice of technologies. For thiis reason, you might say that, in 2007, we're living in the thick of the Age of Security.

The unpaperless office

Wow, there's still a lot of paper out there. It's striking how often the problem of dealing with paper content arises. Here are some recent conversations I've had about this topic:

• A government agency has rooms full of historically significant documents, for which there is no electronic representation.
• A university has a great fear that untold amounts of important research and teachning materials are in someone's desk drawer.
• A private corporation has a backlog of customer-related documents that need to be scanned, so that important business processes can proceed. (They count on being able to search and find things during calls with customers.)

Fortunately, our core story as a vendor is pretty simple. Scanned content is much like content from other sources, such as productivity tools. Therefore, go ahead and scan using whatever tool you want, and through the Xythos Drive, the OS-level WebDAV, or web UI upload, put the electronic content on the server. If you're using a multi-functional device, some already support WebDAV. If not, we have a connector for one manufacturer's devices, Ricoh MFDs. If you need to get fancier, adding metadata (in the scanning world, indexing) or doing other things, take a look at our plug-ins for Captiva and Omtool.

You might wonder, if we live in the age of the "paperless office," why it's important to provide these different options. The answer is pretty obvious: we're far, far away from a paperless world.

How not to collaborate

People in the software business often describe collaboration as if it were a completely technology-driven process. While you might think that's just self-serving marketing, I can say that, working from the inside of multiple companies, it's more of a subcultural thing. If people don't use collaboration tools in the way that you expect, maybe the tools are badly designed.

However, people matter--perhaps more (egad!) than the technology, which can certainly make collaboration easier. Software can encourage or suggest better behavior. It can't make people better, however.

A prime illustration is this this post from Babsonknowledge.org. (Thanks to Mike Gotta for the original pointer.) You might title this piece, "How not to collaborate." After someone produced a new source of critical information of genuine value, a manager nixed the project:

The article was never published. The company executive whose approval I needed admitted that the article was accurate but said he didn’t want the public to get the impression that things happen in such an informal, ad hoc way at the company. Although he didn’t say so, I think he was also uncomfortable about casting disobedience in a positive light.

I'm not aware of any software that will cure a manager of insecurity.