Documentum and FileNet – users and groups

This is a story about how design decisions can make your life really hard on the long run.

As a short technical info…

Documentum has groups, roles (actually groups with “tagged” as roles) and users.
Groups can be defined inside Documentum itself or taken from an LDAP source. Mixed.
Roles are not much different, you can use roles and groups interchangeably for the most time.
Users can be defined inside Documentum, taken from LDAP or mapped to OS users.

FileNet knows about groups, roles and users.
Groups and users are always from the LDAP (ActiveDirectory). Only. Replicated from.
Roles are strictly tied to the features exposed in the standard UI (Workplace).

Both Documentum and FileNet have permission sets with some templating features.

And now ask yourself how many times did you need to “group” together users in your CM solution. Aiming to enable one user access to some data just by adding him to the proper group.
Quite frequently, didn’t you?

In FileNet this means the group must exist in LDAP and users must be in that group in LDAP. Not in the DMS system. Oops! Here comes PITA! You need to call IT to create the group (usually manually) and add users in it. You can’t do it directly through a DMS API or admin interface.

As I understand it, somewhere in the design time for FileNet, somebody took the decision “we’ll take all our users and groups from the LDAP”. After all.. LDAP is where users and groups should be, isn’t it? By this decision they actually limited the flexibility of the platform for solutions and imposed a great deal of stress on the real world solution builders.

In the real world you don’t have all your business groups in LDAP. At least not in the majority of organizations. Also, the LDAP structure is generally managed by IT not by the business. Sure, we have “identity solutions” on the market but this is still a long way from having it implemented and properly used.

Sorry FileNet, but this round goes to Documentum.

On folders, search and CMS systems

1,5 years later UPDATE: another nice summary: http://gadgetopia.com/post/8290

 

…. original post….

I was surprised by the level of debate generated by “folders”, “search” and what they mean for a Content Management System. As far as I’ve noticed, there was an AIIM blog post kicking the folders, then Pie defended them. Then… some Twitter chatter sparkled (see @pmonks and @piewords), a rebuttal post and a new explanatory argumentation post. And I’m sure I missed some.

I haven’t seen something similar since the “Is WordPress a CMS” topic. 🙂

Where am I standing after about 10 years of CMS systems, some 100+ enterprise projects and a significant level of gray/pulled hair?

In a decent to huge (E)CM platform/solution….

1. Folders must not be something you need to think of when building the solution.

The CMS platform should not mandate you to “tell me in what folder do you want to put this document”. It should be an option you take because it means something to you not because the technical architecture asks you to.

I’m speaking of “folders” from the user perspective, not from the OS/underlying architecture of the CMS. The latter must be a completely disconnected feature (but should exist in its own, also).

2. Search is fundamentally important

But it has so many facets (pun intended). I remember a session with a high ranking technical officer from EMC which said “we have never realized until now how important search is”. This was about 4 years ago, but many years after the “maturity” of the EMC Documentum platform. And Search was just beginning to be understood.

Search is one of the very few ways you actually get to use the content you manage. And usually the most important one.

In my world search means:

– to be able to navigate through a clear taxonomy and
– to be able to do a simple search (so called “Google search”) and
– to be able to do an advanced search (the dreadful UI in which you pick criterias and construct your query) and
– to be able to  explore the repository (aka faceted search, metadata driven navigation…). Guided but not forced onto a path and…

Folders can be either shown as a representation of the clear taxonomy or the manifestation of the facets (think “breadcrumb”). In some crazy systems folders were saved searches (ApplicationXtender anyone?).

See? Folders and search can really get along…

In my recent solution designs I almost always use all of the 4 methods above to empower the user. When one is not used is simply because the business needs and technical needs don’t require it.

3. Metadata needs to be used at maximmum

You can’t have enough of it (mainly because users will not enter it and automatically extracting it’s still in infancy). Thinking the most adequate classification schema for your content is close to art. Must be enough to do the search and other logic (eg: retention, processing) but not too much so it becomes a burden on users so they will avoid it.

4. You need to build trust

One particular reason users are navigating and not searching (traditional search) is because they have learned not to trust completely the search results. Did the system return all I asked for? Do I ask correctly? Was the metadata entered precisely as I need it?

Somehow users trust more a folder structure. Or a faceted navigation. They feel the results are more precise. The mind is at peace. That’s why sometimes you need to mask the “search” in a different form (eg: “see related…”, “auto-complete”, “suggestions”).

Notice that I never talked about “search” as in “search technology”. As a user I don’t care if beneath the UI its a SQL mammoth or a FAST/Lucene/younameit search engine. For the sake of this discussion you shouldn’t care also.

Can we go now? Thanks.