Documentum underneath SharePoint?

I’m sick and tired of this discussion.SharePoint and Documentum integrated together

Every once in a while I see a new post / comment / topic /spam around how great would be to have SharePoint as a UI or for collaborative content and to use Documentum “in the back end” as the repository of choice for compliance, bpm, records or whatever other “complex ECM” thingie. I don’t list the last 10 seen this year already in order not to offend their authors.

We’re talking about this for many years already. More than 3, I think. Do you see it happening? Not. Otherwise the discussion would not be “how great would it be” instead of “look how great it is”.

Will it happen? Probably not, and this is my take on “why”.

I’m talking about the “true” integration, in which the content lives and can be manipulated in both systems. In a business scenario, not just in OOTB “platform” features.

Think “security” for a moment. This is one major pain the integration must solve. Synchronizing the both worlds would be an awful task.

Think business rules (pervasively to be applied in both systems). Yes, there are BRMS products out there, but the large majority of ECM customes don’t have any such thing.

Think associated information bypassing the boundaries of the system (eg. annotations made in one platform to be available on the other).

Who needs to solve this problem? The f.cking solution provider. ECM is not installing itself (contrary to some belief, especially in the ShP world).

What’s the incentive to the solution provider to make an integration so complex and using two very different kind of technical resources? Nada, usually. The provider will focus to deliver a solution with a minimal pool of resources and with the less possible risk factor. Microsoft + EMC in the same boat, with no or very little experience/knowledge on how this goes in reality? This generates risk+++

What’s the incentive to the business owner to ask for this? Only to justify the purchase from both license goliaths. There is hardly a true business case around it. What can be done in ShP can also be done in Dctm and vice-versa with mostly the same cost. It’s a “political decision” where to do it, actually. Or a decision simply taken by someone in the team and swallowed by the rest.

So, while the community (mainly the technical area, let’s face it) dreams about pink elephants, the business oriented SI/… selects one platform and implements the solution on it. If forced, it can move content around from Dctm to SharePoint and back… but that’s not integration… is it?

Sure, it’s nice and handy to have an RBS connector for Documentum. Or to have some webparts exposing various Documentum features. But this is all we can get and apart for some simple use-cases, they’re… oh well… simplistic.

Implementing the content download feature in web applications

Recently I twitted on the idea that some ECM applications can’t even do a file download “right”, much less more esoteric features like social interaction enablement. Although that twit was a bit of a rant, it is fundamented by the fact that I’ve encoutered several applications (Webtop being one) in which downloading a file is sometimes a (technical) challenge and fails unexpectantly. But I digress…

As life always has a way of coming back at you.. the next day I’ve noticed a support issue on my team in which one of our customers complained that if it tries to download a dynamically generated file then a blank browser window appears and remains open. The download was ok, but the window was annoying. On IE6 only.

Want to bet what we were ready to say to the customer? “It’s IE6’s fault! Get rid of it or change a certain setting to make it work (which setting… nobody knows)”. Some call that the Russel Crowe move.

Remembering what I’ve just said publicly to the world and wanted to not be in the same category with the “ECM dudes which can’t implement a file download right”, I looked into the problem myself.

It’s a simple thing: downloading a secured file (dynamically generated or not, doesn’t matter).

Given the behaviour, my bet was that the team has done something like a javascript snippet with and that on the request the server returned actually a file to be downloaded not a web page. Firefox and IE7+ probably detect that the newly created window is useless and close it (or never create it in the first place). But IE6 is actually doing what you asked for.

Fired up Charles, looked into the app…. by the way, it’s an IceFaces app, which somehow will help my conclusion of the post. What I see there is exactly what was expected.

The application had a HTML button on it with some JavaScript code behind (coming through the IceFaces intricate ways) which did a wonderful with target _blank. The URL of the window was actually a servlet which returned the content stream. Isn’t that cute?

So, I advised the team to go back to the old school ways of putting that URL into a HTML <A> tag and get it over with.

Strange thing happened: the team decided to try and still use Javascript (yes, we love Buttons very much) and try location.href in order to direct the browser into downloading the file. This approach worked in IE6. Tada! But in IE8 for example it generated one of the famous yellow warning bars on top of the page (yes, the one a user will for sure ignore or dismiss bluntly) saying “This website tries to download a file. Allow it? If yes, please right click, jump though 7 hoops, hold you breath 5 seconds, refresh the page and click on the button again. Thank you”.

So location.href does not work either (although it has that interesting result, I always wondered how that was done…now I know).

What about the old school <A HREF=””> tag? Yes, that works. Flawlessly. Simple, clean and nice.

PS: if someone wishes to see a “button” not a text link, just enclose a IMG, border=0 with A. Add CSS to simulate on hover changes and be done with it (sorry to say such trivial things, but I think it helps).

Ok, so here is how to properly (in my opinion) implement a file download action:

– use <A> and target it to the URL of a server side script/servlet/something which returns the content

– the server side should return something like this:

Cache-Control: max-age=0

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Content-Type: application/octect-stream;charset=UTF-8

Content-Disposition: attachment; filename=”blah blah blah.xls”

A few “thumb” rules here:

– Always put Content-Type response header before Content-Disposition header. Some browsers have a problem with a reversed order.

– the filename must be enclosed in quotes. If you don’t, some (most) browsers will not display the proper name of the file to be dowloaded

– be careful of the spaces, colons and quotes int the content-disposition header. they matter

– in IE6 the content-disposition header can’t be too large

Some reading to be done to understand the above:

Read here:

And here:

And here:

And here:

And here:

I hope this helps. And please, dev guyz & galz… don’t follow the easy path of web frameworks (eg. IceFaces) on all counts. Going back to the roots is not that bad and keeps your software resilient.

Building an intranet portal on SharePoint 2010

Our intranet was merely a SharePoint 2007 installation with several document libraries and lists and some random department sites. The look and feel was pure OOTB SP. So, some months ago we came up with this crazy idea of changing the status quo and building a new and real intranet portal.

We did this by starting an internal project. I don’t know how internal projects happen in your organization, but as I’ve seen my fair share until now I’m guessing it’s not much difference. An internal project is always “least pirority” for almost everyone involved. And it’s hard to change this as they are not perceived of generating any money (vs. any external customer).

With this in mind, we’ve set it up. Marketing was the project owner, somehow together with HR (“internal communication” is handled by Marketing in our world). We had a project manager / project sponsor (me). Each business division and department had a unique representant in the project, forming the full team of about 25. And there was also a core project team of about 6 (IT, content, design, strategy) to do the main work.

Here you can find some of my lessons learned from this project.

1. Make sure you know the organization

The person who leads the project need to know and understand the organization in & out. Building an intranet in which you aim to touch all departments, and generate valuable information for anyone in the company is a very complex undertaking. Especially if the company is quite large with multiple business lines and agile in day to day operations.

If the PM does not have this knowledge (say, s/he’s new to the company) then there must be a key project champion in the team which has it. And they must work very well together.

We scored very well on this. I’m with the company for many years now.

2. Decide and move along

We had a big team (imagine having status meetings with 15-20 people, some from management). You can safely assume that if 2 persons are involved, they will have 3 opinions. So, decisions need to be made by somebody and followed through afterwards.

3. Prepare the organization and communicate progress

The intranet has impact on almost all organization members. They must be informed that a new one is coming and expectations set correctly. This is also a motivator down the line to keep the project running and progressing, otherwise people will start wondering what happened.

4. Always keep an eye on the value to be provided

When building an intranet you will encounter many things which can or should be done. Always keep focus on the value (best is to make a checklist) which you aim to provide to the organization. Eg: enable people search, help people find their way through procedures, show the news, enable corporate wide communications, provide links to all relevant apps, provide a valuable search service (enterprise search with facets is a must in today’s day and age), integrate app XYZ…

It’s easy to sidetrack to building more and more web pages with content which would most likely mean nothing to 90% of the organization but is cool or nice for 5%.

5. Identity

The intranet should have an identity of its own. And must have a coherent design. Coherent with the company identity guide (if you have one, please tell me you do). My opinion is that it helps the portal to have a name of its own. It makes people adopt it better, imo.

6. Content

An intranet is nothing without content. If one can make do without fancy “Web 2.0” stuff, it cannot succeed with an intranet without content. Users come to the intranet portal (voluntarily) for at least these reasons: find info about a person, find info about a department (eg: find what that department role is in the organization and who to contact from there), find document templates for day to day operation…

So, plan to allocate around 70% of the effort to the content creation part. Recognize that content cannot be generated by 2-3 persons, but needs to have this task distributed alongside all department representants. Make sure each of the department representant has the authority from the department head to collect and present the related content (this is a must, since sometimes departments will nominate juniors for this task).

How you organize the team to build the content in preparation for the portal, it’s up to you. One of the simplest ways is to make them collect the content in word / xls / ppt documents and put them in a folder structure resembling the final portal structure. Not so fancy, but easy to understand and do. And can be done in parallel with the technical implementation of the portal.

Please don’t forget the existing content (which may lay in the old portal, some fileserver…). It needs to be migrated. Plan, monitor and act. As in any migration… test test test.

7. Structure

Define a portal structure. This is where everyone should brainstorm to and then one needs to make a decision. Try to follow these guides: any somehow relevant piece of information must be no more than 2 clicks away from the main page, the main page must be clean and small, similar organization units must have almost identical portal structure (if someone enters a department/project/division/… page, it should see mostly the same sections as in other departments/projects/division/…).

8. Functionality – get a grip on technology. Early.

You can spend a lot of time building content and imagining the portal structure, but nothing will prepare you completely for the moment you face “the technology”. People who make content don’t really know what the technology can do for them. Even IT doesn’t know, believe me (we’re talking about SharePoint 2010 here).

We did it like this: define the structure and a design prototype. In these discussions the SharePoint specialists are involved also (even if the talk is mainly about business content and rules). Afterwards, put up a playground SP install, build some content templates, page layouts (based on the design), basic navigation structure… and let the content authors loose! You will find at least 5-6 of them (from 20+) who are eager to try and don’t mind that they will need to re-post the content several times. In this manner you will start to define your content editing and presentation rules. Ah, by the way: train the poor content editors before you leave them in ShP. A few hours of informal training will do wonders for the project.

When this playground time is done, you can gather all business representants, show them the intranet prototype, discuss the content rules and tell them to go to work: move their already prepared content into SP.

9. Have a passionate technology guy/gal

Only the SharePoint 2010 expert will know what he/she can do with it. The  IT in general will not know.  Why do you care? Because if you just treat SP as “yet another portal tech” you’ll end up with a dull intranet. SP has some great features but you need to know about them and use them in the business context.

So, make sure the IT guy responsible with implementing it is a heavy supporter of the project idea and wishes to innovate. Make sure he participates in all the project meetings and listen to the business explore ideas and requirements. You may need to pull him from the comfort corner where IT staff likes to stay, but it will be for the good of all.

10. Make sure you know what happens after go live

So now you’ve done it. You just created a living thing, under daily scrutiny from all the company employees.

Please make sure it works well (plan and act with IT to have proper maintenance and helpdesk in place) and provides continuous value (define responsible for recurring tasks to update the content, put in place procedures to add new information when certain things happen).


So,  what’s this got to do with SharePoint 2010?

Well, we did it with SP 2010. I must say, I find it not very well-rounded. It serves the purpose but has some idiosyncrasies of its own.

Some good things:

  • integration for the FAST engine – makes wonders for reviving that old search feature you had in the portal and about which everyone bitched about.
  • my sites – gives employees a space to describe themselves
  • content editing – with the proper templates in place, business owners can understand it and work with it ok

Some bad things:

  • layout limitations – you have to go though many hoops to apply a not ordinary design. Or you need to make concessions on the design
  • mobile access – terrible. On iPhone/Android/RIM…. almost forget it. IPad is tolerable (since it’s a full browser exprience more or less) but still doesn’t always work properly

Am I happy with how it went? Yes.

Did it cost an arm and a leg? No.

Can it be done better? Much better.

Would I recommend SP 2010 for an intranet portal? If your IT is Microsoft oriented and has in-house SharePoint skills – yes. Otherwise, it’s a long story.