March 2007

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.

Web 2.0 and the organization man

Most of the commentary about Web 2.0 comes from developers, journalists, and devotees.Therefore, it's hard to jam blogs, Wikis, mash-ups, and other Web 2.0 technologies into the frame of corporate America That's no surprise, since the management of these organizations don't yet feel comfortable with the loss of informational control that Web 2.0 might represent.

This clash of cultures, between the Ajax developer and the CFO, is what makes deliberate efforts to fit Web 2.0 into the corporate world interesting. At the Gartner conference i just attended, I heard the author of Wikinomics, Don Tapscott, make his now-familiar argument that the revolution is effectively over, and companies need to just get over it.

While exhortation has its place, so does a more granular analysis of what individual companies are doing well or poorly to incorporate Web 2.0 into their organizations. To get that picture, you need to read publications like the blog maintained by two Forrester researchers, Charlene Li and Josh Bernoff. They'll tell you how beverage companies are trying to glom onto social netowrking, or how Disney is building a portal pitched at young parents.

An early conclusions: Everyone can agree that Wikis are a good thing. Blogs got the spotlight for a long time, and they continue to have their role. However, corporations (and government agencies, non-profits, and educational institutions, for that matter) need a more departmental, less conversational tool. Wikis are "WCM for the rest of us," an easy way for groups to maintain official information of interest to them, or anyone who works with them, withot the overhead of a traditional web content management system.

Wikis aren't perfect, though. I'll have more to say about them in future posts.

ECM DOA

Today, I'm at the Gartner Portals, Content, and Collaboration Summit. (Say that three times fast.) Two Gartner analysts, Toby Bell and Kennet Chin, have made a bold statement: ECM is dead.

What does that mean? Well, it's not that there isn't a place for tools to run big, complex web sites, or high-end DM tools. However, enterprise content management has never been able to expand to either involve or control everyone in the organization. In that sense, enterprise content management--CM by and for the enterprise--hasn't succeeded. In fact, it hasn't really ever gotten off the ground.

Well, heck, who am I to argue with that? Basic content services--content management for the masses--doesn't move from the complex to the simple. It moves fromthe very simple to the somewhat more complex. In other words, it's tough for ECM vendors to prine their technology down to become basic content services tools. On the other hand, it's possible to build from the simpler tools--file management, e-mail, chat, etc.--to more complex rules and processes.

I've often half-jokingly called this process "The Stairway to Heaven." (Yes, I am a Zep fan.) The first step is what people do for themselves, or to work easily with their most immediate collaborators. Once you've made people happy with those tools and processes, you can start adding new functionality, restrictions, content, you name it--as long as you don't stray immediately from what people already know and embrace. In other words, you can't go from 0 MPH to ISO 17799 compliance in 6.0 seconds.

There will always be a role for ECM. As a BCS vendor, we still need to co-exist with ECM systems already deployed. However, ECM today looks a lot like ECM several years ago--and that picture isn't likely to change. People still need to manage content--which is why organizations will invest in BCS.

I used to have a pair of model tanks on my desk to make this point. Both were used in WWII; each represented a different design philosophy. The American M4 Sherman was simple and reliable. The German Panzerkampfwagen VI ("Tiger") was powerful, but prone to breakdown, and consumed fuel and spare parts at a furious rate. Which tank would you buy? For most jobs, the Sherman. For a few jobs, the Tiger. That distinction is a lot like the dividing line between BCS and ECM today. (And who won the war?)

Use case forums

Here's a logical trail to follow:

• We've been answering a lot of questions about use cases with our technology. That's the main reason for the white papers and videos I've been publishing.
• However, the number of use cases is always going to be larger than our current set of support materials.
• Therefore, we need to provide a way for customers and partners to ask questions about use cases, rather than waiting for us to publish white papers, demos, and the like.

Our solution: The forums here on developer.xythos.com now have a section dedicated to use cases. We've already had our first questions posted, less than a day after we started the forums. We're glad to answer your questions, too.

Institutional repositories and Xythos

The institutional repository white paper is finally here. (Actually, it's right here.) It's designed to answer the following questions:

• What options exist for using the Xythos server (whatever flavor) and desktop technology in an institutional repository?
• What are the pros and cons of each option?
• Which Xythos features are important for these options?
• Which version of the server--Enterprise Document Manager, Digital Locker, or WebFile Server--best fits each scenario?
• How much customization, if any, might be necessary?

The white paper makes special reference to DSpace, which probably the most popular institutional repository tool. As always, your feedback is cordially invited.

National Science Foundation guidelines

Here's the research note about automating compliance with National Science Foundation (NSF) retention guidelines. I alluded to it in an earlier post; now we have the official version. If you want a file with the import/export XML described in the appendix, click here to download it.

New use case video: human resources

I've just finished the latest "use case" video. This time, we're showing how to use Xythos technology to handle common tasks in human resources.

I added something a little different this time, a few choice words about integration with other IT components. LDAP, storage, portals--there are a lot of quick and easy mechanisms to integrate us in profound ways. Everything I show in this video works out of the box, so we're not discussing any integration that requires coding.

I'm taking a break from recording these videos. Here's a brief recap of what we have so far:

Research support, part I (video, PPT)

• How can the Xythos server and desktop technologies help the pre-grant process move long successfully?
• What are some situations in which you might want the Enterprise Document Manager instead of the Digital Locker?

Research support, part II (video, PPT)

• How can our technologies help manage intellectual property and automate post-grant rules?
• When would you make the step into the new records management features in Xythos Enterprise Document Manager 6.0?

Internal financial controls (video, PPT)

• How can our server and desktop technologies help organizations comply with financial standards like Sarbanes-Oxley?
• When would you make the step into the new records management features in Xythos Enterprise Document Manager 6.0?

Human resources (video, PPT)

• How can our server and desktop technologies help collect, process, and archive personnel documentation?
• What are some of the important points of integration between the Xythos server and other IT components?

If you have suggestions for other use cases you'd like to see, please send them along.

Use case: internal financial controls

Speaking of use cases--and I'll continue to speak of them quite often--internal financial controls have been a concern since, oh, the Sarbanes-Oxley Act. Here's a video (81 MB, about 20 minutes in length) I just recorded, showing how to address this class of compliance requirements with our technology."

The video shows how you might use the Enterprise Document Manager and the Xythos Drive. I might have shown document capture through the Drive, or using the Ricoh or Captiva connectors we developed. I might have shown how you might build a custom integration between our server and an ERP system. Heck, I could have gone on and on...but you'll get the basic idea from the video. The approach shown combines what customers have already done to address these sorts of requirements, using older versions of our products, with the new options available in Enterprise Document Manager 6.0.

Bill, Joan, and the National Science Foundation

Sometimes, you can't avoid the weather. This weekend was a case in point. I sat down to write a short, serious research note about how to use Xythos Enterprise Document Manager to address National Science Foundation post-grant guidelines.

The weather was just too damn nice. Instead of the usual sort of white paper, I wrote this. It has the basic information in it, but the format is, well, different. I'll write the real version this week, maybe after the weather turns nasty again.

Straight through the browser

We just published a new project, a web UI plug-in that lets you drag and drop files through the browser. The plug-in is fairly simple Java applet. It's beta quality code, so post any issues or questions you have in the discussion thread for this project.

Why is this project significant?

• It's another way for Macintosh users to get content into the Xythos server. We don't yet have a Macintosh version of the Xythos Drive, but many Mac users just want a way to drag and drop files into the server, without necessarily using the Mac OS implementation of WebDAV.
• It's generally useful. As a Windows user, if I'm working through the browser, I don't want to have to drill into the same folder in Microsoft Explorer to upload several files.
• No desktop configuration is involved at all. Except for the browser's Java settings, obviously.

An aside: We've also been experimenting with a button that would automatically open the same folder you're viewing in the web UI. If you're interested in that customization, speak out in the forums.

Feedback? Questions?

One of the references I added to this blog (see the panel to the right) is the e-mail address for product feedback and questions. The forums are a good place for technical questions, but you might have something else you might want to ask. For example:

• I really love/hate [your pet feature here]!
• Are you planning on adding [your favorite feature here]?
• How would I use your products for [your use case here]?
• Do you have a recommendation for [your partner-provided technology here]?

The first two questions in particular are good material for our mailing list, feedback@xythos.com. I get anything sent to it, as do a few other Xythinians who plan, build, or support our technology. Don't be shy--we definitely want to hear from you.

You can never say it often enough...

If you ever want to find the most recent versions of Xythos' products, check out the Support page.

KM 2.0 and Web 2.0

David Weinberger has an interesting article in KMWorld about how knowledge management is following a similar path as the Web:

That's why, in my opinion, KM 2.0 is both a useful phrase and fundamentally different from Web 2.0. KM 2.0 points to Web 2.0-ish phenomena gaining prominence in the KM space: bottom-up, participatory, rapid innovation, more mixing up and mashing up of information. These are all good things, or at least good things to try. But they are truly discontinuous from the paradigmatic versions of KM 1.0, which were all about managing and controlling information environments.

Wow, I couldn't agree more. Blogs, Wikis, photo upload sites, other Web 2.0-ish tools made web publication easier than using some big honkin' web content management system. The same tools, plus a few more, like search, have made made more institutional knowledge available, without making it less manageable.

Another institutional repository sneak peek

Before I publish the institutional repository white paper I mentioned a few posts ago, I thought I'd share some examples of how to configure the Xythos Enterprise Document Manager to model the metadata for an institutional repository. Here are two important links:

• Sample institutional repository metadata (short).
• Complete metadata model for DSpace (longer).

These are XML files that include all the custom properties needed, plus the document classes that incorporate these attributes. To use these files in a Xythos instance, here's what you do:

1. Download one of these files.
2. Go to the admin UI for the server.
3. Under Tools, select XML Migration > Import.
4. Fill out the form. Be sure to check the boxes for both importing metadata and document classes.
5. Click Start.
6. Log into the instance as a user who can apply document classes to directories. If you're using the sample data from the evaluation version of 6.0, log in as DemoRMO/xythos.
7. Add the newly-created document class to a directory. Make sure that it's the default document class for that folder.
8. Upload a file to that directory.

You'll now see that the Xythos web UI requests the institutional repository metadata. What do you do with it, once someone has entered it? That all depends on how you integrate the Xythos server with the institutional repository...which the white paper will explain in depth.

Dropping anchor to the desktop

It's interesting--well, at least to me it is--how strongly the desktop looms in the Internet age. We're not yet living in a world where you can move to any kiosk PC or dumb terminal and access all your applications and content. (Though, to be fair, organiations like Northeastern University have made big, big strides in this direction.)

No matter how long you use hosted applications like Flickr, or access content stored on the other end of an Internet connection, at some point, you need to drop anchor at the desktop. For example, I may need to work on a document while I'm on an airplane. What happens then, if I'm completely dependent on having an Internet connection to stay productive?

In reality, many users are so habituated to working from the desktop. Give them the best web-based application, and they'll still want to double-click on files, make changes, and save them back to wherever they live. Depending on the applications they use, they may not have a choice. As good as Google's spreadsheet program may be, there isn't a Web-based alternative to Adobe PhotoShop for graphic artists.

At the same time, I want, as often as possible, to have the functionality of the hosted application available while I'm working I may like what the application does to automatically preserve earlier drafts or versions of a document.

Of course, people can use the desktop badly. Users may not take care to clean up old content that needs to be deleted. They regularly fill up their e-mail accounts with e-mails crammed with attachments. It would be great if the desktop tools suggested better behavior, or in some cases, actually enforced it.

At the end of the day, the users don't care about the technology. They only care about what it does--such as being able to access my presentation from anywhere in the world.

You've now heard a plain English version of the requirements for the Xythos Drive, our desktop component. We've designed it so that it can...

1. Let people continue working from the desktop.
2. Access features available on the Xythos server (whatever flavor), such as versioning, tickets, and the like.
3. Recommend better desktop habits, such as sending links instead of attachments.
4. Let admins exert some remote control over what features are available, or what may be required (such as the links-instead-of-email behavior).
5. Use technology, such as WebDAV, that support how people work without throwing technological grit in their eyes.

That's why we have invested in the Xythos Drive, and it will remain an important part of our product offerings, including both the installable product and the "software as a service" offering, Xythos On Demand. When you hear Xythinians talk about the Xythos Drive, we have this set of assumptions in mind.

Workflow by any other name...

Since I've spent the last several months talking about our 6.0 release, I've learned how important it is to position the information lifecycle management features correctly. They're not exactly a separate feature, but an adjunct to an existing feature, workflow.

That statement is true at the platform level, since both the "approval and routing" (non-records management) and disposition rule (records management) features are built on the same workflow engine. The statement also applies at the user experience level, within the Enterprise Document Manager 6.0 application. An approval and routing workflow of the Would you please take a look at this? variety is much the same as the Can you please archive or delete this record now? workflow. From the user's perspective, they're both to-do items. Therefore, they both appear in the user's My Tasks section of the web UI.

As we build new workflow enhancements into either part of the system, RM or non-RM, we'll continue to keep the "everything in the same to-do list" model that I'm describing.

Questions about institutional repositories

We've had a lot of questions in the last year about how we fit into institutional repository solutions. How can we contribute content to an application like DSpace? Are there scenarios in which the Xythos server might be the institutional repository? How do the new features in the 6.0 version help, in either case?

I'm working on a white paper outlining some options for including the Xythos server (WebFile Server, Digital Locker, or Enterprise Document Manager) in institutional repositories. Look for an announcement of it here in the next week or two.

Right after that, I'm writing a similar white paper about e-portfolios.

Why JSR-170?

Our 6.0 WebFile Server release adds a JSR-170 layer to the API. The existing API works just fine, and it adds RM functions that correspond to the features in the Enterprise Document Manager product. So why a JSR-170 layer?

Our intent was to help developers re-use their knowledge of an API across multiple systems--and not just ours. In this first release, the API is read-only (a.k.a. "level I support" for the standard). In a short time, we'll be publishing the level II, read/write API.