Mare Nostrum

JSR-170: If at first you don't succeed...

For a proposed standard to be successful, it needs the right mix of good design, timeliness, vendor backing, and simple luck. JSR-170 has a good chance at meeting all those requirements, which is why Xythos has been building a JSR-170 layer above the existing API. In 6.0, we finished the first phase, the read-only interfaces ("level 1," in JSR-170 parlance). We'll soon be finishing level 2, the complete read/write interface.

JSR-170 has a lot more momentum than its predecessors, such as ODMA, the now-obsolete effort to specify a document management API standard. ODMA came too early, pushing a standard when organizations viewed DM as a niche function. To make matters worse, IT departments successfully implemented DM systems only about half the time. The other half were, of course, highly expensive failures.

JSR-170 has emerged at just the right time. While not everyone knows the term "basic content services" (BCS), most people in the workforce today understand the need to manage documents better. On the stick side of the incentive question, IP protection, corporate risk, and compliance have enlarged the circle of people who need to think about their documents more carefully. Increases in productivity, the rich variety of web-based applications, and the Web 2.0 generation of collaborative applications have expanded the number of people who want to manage their documents.

Just as importantly, people in the technology biz, from software vendors to IT departments, have learned how and why to implement standards. For example, the SOA movement couldn't move anywhere, if there weren't standard interfaces among the different components in the larger

JSR-170 also benefits from a trail already blazed by another content management-ish standard, WebDAV. At some point, enough applications added WebDAV support to give the standard the critical mass of acceptance. Not just Apache, but Dreamweaver, had a lot to do with WebDAV's success.

Is JSR-170 a better standard than ODMA? A comparison of the two APIs might be illuminating, but it won't necessarily tell you why ODMA failed, and JSR-170 has a good chance of success. The best-designed standard has no chance of success, if the timing is wrong.

P.S. If you're interested in being a beta customer for our level two JSR-170 implementation, drop us a line at support-beta@xythos.com.

E-portfolio white paper available

If you're wondering how to fit Xythos technology into an e-portfolio initiative--well, imagine no longer. This white paper walks you through the options with our current products, and discusses what future plans fit many e-portfolio use cases.

Another archiving option

As I've noted here before, there are a lot of potential uses for the new import/export framework. One of them is archiving.

Let's say that you want to preserve the HR department's shared directory. Backing up the content means a lot more than just copying the files and folders. There's also all the information about the document--document classes, security settings, comments, etc.--that needs to be preserved. How do you store this extra information as part of the backup?

This short research note answers that question.

I like my first life, thanks

Since I've been doing some research on the state of Web 2.0 technology adoption, I spent some time looking at Second Life, There, and other virtual world applications. I've reached one preliminary conclusion:

Either I'm really getting old, or these applications are really goofy.

I've heard people try to position Second Life for business. I know that companies are trying to market their products through these virtual worlds. But are they a collaborative tool, in the same fashion as Wikis, blogs, IM, and the like. Uhhhh, probably not.

If I'm missing something, please tell me.

RM by any other name

When we designed the 6.0 version of Enterprise Document Manager, we took some pains to make its features generally useful. The 5015.2 requirements looked, from a particular angle, like many of the features we already planned. Disposition rules and vital record indicators are, more or less, the ways in which you'd automate the lifecycle of content. Final disposition reflects the formal rules of good content hygiene--get rid of junk you don't need, handle other content with care--that's a general priority in many organizations today.

Therefore, as a product manager, a lot of questions I've been answering lately take the form of, "When would I use the new 6.0 features to...?" That's one reason why I wrote the institutional repository white paper, to describe how you might use the RM and non-RM features in a particular scenario.

I'm writing another white paper, this time covering the options for plugging our technology into an e-portfolio project. Much of the discussion will be the same: when do you use particular features, and how?

It'd be great if there were a single answer. However, not everyone means the same thing by the term, "e-portfolio." Making RM a hidden or subtle part of collaboration is new, so most people need to ponder how "RM by any other name" might help creating, publishing, maintaining, and exporting an e-portfolio.

In a couple of years, maybe, e-portfolios will become more better defined, and RM integrated into collaboration will become more commonplace. Until then, it takes a little extra explanation, or a quick demo, to get to that "Aha!" moment.

E-learning mashups

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.

The big, fuzzy picture

Can someone explain the usefulness of this "Big Picture" view of C|Net content? I always want to know about related stories, but the whole "knowledge map" view seems even harder to figure out than just a list of links. I looked at their example, but the crazy-quilt of graphical connections doesn't seem more useful than just a link that says, "Click me to read more stories about Apple."

The What's Hot view seems slightly more useful. On the down side, it's not relevant to what I'm reading now, and it seems like a self-fulfilling prophecy. I'm sure that the headline, "Cyberbullies scare schoolgirls into stripping online," feeds on itself. (Plus, need I say it? Ewwww...)

Sticky ideas

I often think that the IT business needs to look beyond its borders. There are all kinds of debates in content management and collaboration circles that boil down to relatively simple questions, often asked and answered by people outside our field. For example, IT professionals often worry that important bits of information aren't getting the attention they deserve. For example, Mike Gotta of the Burton Group recently posted on his blog a set of questions about "event stream processing." He does a nice job of linking it to some real-world use cases in the US government around "need to know" versus "right to know." Here's the kind of puzzle that gets under his skin:

Specifically, I'm looking at how attention data and "post" activities act as informal, loosely-coupled signaling methods that, when streamed in a public manner, can be combined with sensor/filter/relay mechanisms to intelligently pull messages and information to other people or situate the information to the right place (e.g., a "my space" created as a honey pot of sorts to house interesting/relevant items).

Meanwhile, elsewhere on the Internet, a recent Scientific American podcast featured an interview with one of the authors of Made To Stick, which tries to explain why certain scientific discoveries get attention, and others don't. We assume that, as soon as someone makes a discovery, it instantly leaps into practice. However, it often takes years, or even decades, for the implications of a discovery to sink in, or for someone to realize its practical implications. For example, the first steam engine wasn't invented by Thomas Newcomen. That honor goes to Hero of Alexandria, an ancient Greek who documented how to drive the rotation of a sphere through the expulsion of steam. More modern inventors toyed with steam engines before Newcomen and Watt convinced people that they were worth putting into mass application.

And that's just one interesting book on the subject of how "to intelligently pull messages and information to other people" that historians of science, psychologists, sociologists, and other researchers have discovered. Maybe it's time for IT to incorporate as more social science into its work?

Comments...awaaaaay!

Are Wikis wacky?

It's hard to find an organization that doesn't have a Wiki project going. It may still be in the "I've got a feeling inside/But can't explain" stage, or people may have piloted a departmental Wiki, which other groups are scrutinizing for their own possible use. What's clear is, out of all the Web 2.0 collaboration technologies (Wikis, blogs, mash-ups, etc.), Wikis seem to have the biggest traction right now.

But why? Wikis can be the John Q. Public version of web content management, suitable for situations where you want a simple, easy way for people to create web pages about important bits of shared content. For example, I have a Wiki page for product management here at Xythos, because I need to explain and link to content from a variety of sources. Sure, I could create an enterprise portal infrastructure, aggregating content via web services into a decision-maker's dashboard, customized for each viewer--but why would I do that, if all I want to do is show everything the PM department is doing?

Before getting swept into the psychology of the crowd, it's important to pose some harder questions. Alan Pelz-Sharpe of CMS Watch has some deliciously contrarian things to say about Wikis. I suggest you read the comments, too, for some thoughtful reactions.

I'll say this about Wikis, after a couple of years' experience using them:

• As with all web content, their value depends on the freshness and relevance of the content they contain.
• Therefore, Wikis can be a great tool, or just another regular task on your daily to-do list.
• As with other Web 2.0 collaboration tools, Wikis are more valuable when hooked into other collaborative technology. For example, a Wiki without a forum doesn't seem to make sense to me.
• The more content creation can be automated, such as through RSS feeds, the sweeter life will be as a Wiki author.