What is the best way to integrate a content management system with a portal, or for that matter what if you want to “content-enable” a separate application? There are a number of different approaches and depending on the portal, the application or the content management system any of them might be correct for the situation. I find however that there are a number of fundamental rules that should be followed when evaluating an approach.
Who Are You Working For?
Before we talk about the details, we need to understand why we are doing what we’re doing. For me that starts out with defining who we’re doing what for. So when implementing a web content managment system, even one without an external integration requirement, who is the primary customer? If you’re thinking the end users or consumers of the site, you’re wrong. End users are of course important, but as an implementor the primary customer is actually the content contributors. The often overlook contributor is the first person that should be considered with every requirement or approach. The reason of course is that a content management implementation is not about implementing a web site, it’s about implementing a tool that allows content contributors to implement and manage a web site.
So what are we looking for in a good contributor-oriented approach?
- The process should be as simple and straightforward as possible. Obviously that’s a subjective statement; one person’s simple could also be Lotus Notes. Contributors vary in skill level and functionality differs with requirements; what we’re striving for though is not necessarily a process that is so simple a child could do it, but one which allows contributors to work as easily and efficiently as possible.
- Contributors should not need outside assistance or coordination with other groups to contribute content and post it to the site(portal/ external application). This is a huge no no. If the contributors need to call developers to move content or have it appear on the site, there’s a huge obstacle to adoption in the way. Unfortunately this is often one of the first compromises that often happen when integrating with an external application.
- The basic features of web contribution should be available; images, hyperlinks and basic formatting(bold, underline, italic, bullets, etc) are going to be expected. If have the discussion forums out there support indenting..you’re probably going to need that feature too.
- Contributors should feel confident that they cannot break their site. Ideally this means they should not have access to tools or formatting which can break the look and feel of the site. Workflows should be used to provide an approval process. We’re looking to empower contributors and ironically nothing breeds creativity like boundaries. If they feel like they can do no harm, they are more likely to take advantage of the tool.
If you look through that list what you’ll find are some pretty basic requirements for any web content management system. Every CMS from the Drupal to UCM to Ektron has those basic features and then some, but what if we surface that content through a portal or another application? How many features will contributors loose right off the bat?
Checklist? Checkmate…
To sum up what we’re trying to do, the overall the goal is to encourage content contribution by empowering contributors. That’s a goal in every CMS project, but when an external portal/application is included we also need to provide the fundamental contribution features of a CMS in that remote portal or application.
That doesn’t mean just editing text in the portal either. Contribution is not just about a bunch of words, it’s also about images and tying all that information together with links. Contributors do not care if it’s a portal, a content management system, a custom site or a magic flashy box. There are certain fundamental features that are expected and there will be dissatisfaction and lack of adoption if they are not there. It’s not the contributors faults either…their customers(the end users) have come to expect images and links in what they read. If it’s boring, hard-to-follow content, why bother reading it? And if no one is reading it, why keep contributing it? And then of course what good was that expensive content management project, if no one is going to contribute?
How do we know if we have a good strategy though? There are a couple of questions I’ve put together which I think help assess a strategy and at the very least identify it’s strengths and weaknesses.
1. Describe the process for adding and/or editing a page in the integrated environment. Can the contributor do it on their own(ignoring any workflow)? Do they need access more than one system to post a single page of content? If they can’t(do it on their own) or they have to(access more than one system), you might want to head back to the drawing table. Those are enthusiasm killers for contributors.
2. How will images be contributed and delivered? Images can be a major pain. If you’re contributing them in a WYSIWYG editor, typically they head to the CMS or an external repository. References to images in content need to be preserved, re-written or proxied. What path will you take and and why?
3. How will links between pages work? This is usually the question that sends us back to the drawing board. If you are surfacing content from a CMS on to a portal, how do you link to another page on the portal while using the CMS’s editor? Relative links are sometimes an options, as are tokens. It’s important to have a solid approach though as when you are referencing items in two different systems things can get very confusing quickly leaving the site with many broken links.
Even though we’re dealing with some fundamental features, believe it or not once you introduce that separate application very few implementations would get an A+ on all three areas. At work we’ve taken over some less than successful projects and the #1 problem is not that the site or portal don’t deliver content well, it’s that no one can effectively contribute. It’s only three general questions to drive a discussion, but I’ve found them to be a very effective check list for separating good ideas from bad ones.
Manifesto or Just Manifest?
The goal of this post is to set up and explain my mindset and strategy for several integration examples on how to approach a portal integration with a CMS(ok they are all UCM/WebCenter examples). In looking at some of the planned posts, it was clear that they might not makes all that much sense without setting the stage first.

Loading ...
Manifesto on Content Management in Portals and Applications
What is the best way to integrate a content management system with a portal, or for that matter what if you want to “content-enable” a separate application? There are a number of different approaches and depending on the portal, the application or the content management system any of them might be correct for the situation. I find however that there are a number of fundamental rules that should be followed when evaluating an approach.
Who Are You Working For?
Before we talk about the details, we need to understand why we are doing what we’re doing. For me that starts out with defining who we’re doing what for. So when implementing a web content managment system, even one without an external integration requirement, who is the primary customer? If you’re thinking the end users or consumers of the site, you’re wrong. End users are of course important, but as an implementor the primary customer is actually the content contributors. The often overlook contributor is the first person that should be considered with every requirement or approach. The reason of course is that a content management implementation is not about implementing a web site, it’s about implementing a tool that allows content contributors to implement and manage a web site.
So what are we looking for in a good contributor-oriented approach?
If you look through that list what you’ll find are some pretty basic requirements for any web content management system. Every CMS from the Drupal to UCM to Ektron has those basic features and then some, but what if we surface that content through a portal or another application? How many features will contributors loose right off the bat?
Checklist? Checkmate…
To sum up what we’re trying to do, the overall the goal is to encourage content contribution by empowering contributors. That’s a goal in every CMS project, but when an external portal/application is included we also need to provide the fundamental contribution features of a CMS in that remote portal or application.
That doesn’t mean just editing text in the portal either. Contribution is not just about a bunch of words, it’s also about images and tying all that information together with links. Contributors do not care if it’s a portal, a content management system, a custom site or a magic flashy box. There are certain fundamental features that are expected and there will be dissatisfaction and lack of adoption if they are not there. It’s not the contributors faults either…their customers(the end users) have come to expect images and links in what they read. If it’s boring, hard-to-follow content, why bother reading it? And if no one is reading it, why keep contributing it? And then of course what good was that expensive content management project, if no one is going to contribute?
How do we know if we have a good strategy though? There are a couple of questions I’ve put together which I think help assess a strategy and at the very least identify it’s strengths and weaknesses.
1. Describe the process for adding and/or editing a page in the integrated environment. Can the contributor do it on their own(ignoring any workflow)? Do they need access more than one system to post a single page of content? If they can’t(do it on their own) or they have to(access more than one system), you might want to head back to the drawing table. Those are enthusiasm killers for contributors.
2. How will images be contributed and delivered? Images can be a major pain. If you’re contributing them in a WYSIWYG editor, typically they head to the CMS or an external repository. References to images in content need to be preserved, re-written or proxied. What path will you take and and why?
3. How will links between pages work? This is usually the question that sends us back to the drawing board. If you are surfacing content from a CMS on to a portal, how do you link to another page on the portal while using the CMS’s editor? Relative links are sometimes an options, as are tokens. It’s important to have a solid approach though as when you are referencing items in two different systems things can get very confusing quickly leaving the site with many broken links.
Even though we’re dealing with some fundamental features, believe it or not once you introduce that separate application very few implementations would get an A+ on all three areas. At work we’ve taken over some less than successful projects and the #1 problem is not that the site or portal don’t deliver content well, it’s that no one can effectively contribute. It’s only three general questions to drive a discussion, but I’ve found them to be a very effective check list for separating good ideas from bad ones.
Manifesto or Just Manifest?
The goal of this post is to set up and explain my mindset and strategy for several integration examples on how to approach a portal integration with a CMS(ok they are all UCM/WebCenter examples). In looking at some of the planned posts, it was clear that they might not makes all that much sense without setting the stage first.