Creating and Delivering Content and Applications - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Information Management

Creating and Delivering Content and Applications

An enterprise content management system does not equal an enterprise portal.

You’ve got a problem: You need to manage and personalize content.

Here’s the background: Your organization publishes content as part of your core mission. You have a publishing process for creating, editing, approving, and ultimately shipping content to some public or private Web site. The challenge about this content? You’ve got a lot of customers — thousands, in fact — and not all of them are interested, or maybe entitled to, all your content. Therefore, you need to personalize that content for security and/or usability. So you begin the search for a solution.

Naturally, you went out to the marketplace and looked at content management system (CMS) offerings. You researched the publishing stuff, bought a solution, and implemented it. You found out that the package was great at the publishing part — the business process, the workflow; letting one group of people create and giving authority to other groups to edit or approve. Your CMS vendor told you that they could handle your personalization. Then you found out through trial and error and frustrating experience that they really don’t. In fact, odds are you have to program it from scratch. Or maybe they told you that their professional services team would be happy to do it — for a fee.

Perhaps, instead, you bought a portal package. You found that it’s great at letting you define the communities and constituencies that consume this content, plus you get the added benefit of being able to present reports and data — dashboards, if you will — from other systems around that content. It lets you secure and personalize the user experience for this content. However, the problem is that the tools to create the content are limited to publishing that content in the portal. What about your public Web site? What about your print materials? Your global content inventory goes far beyond the portal, but the portal’s built-in tools don’t really allow you to create content for those repositories.

Regardless of the solution you chose, what can you do now? How big a mistake have you made and how much will it cost you? Is there a solution that can remedy these challenges? Moreover, how did this happen in the first place? With all the mergers and acquisitions in the Portal and CMS arena, why can’t these tools be more holistic?

The truth of the matter is that most of the mergers in this space took tools with totally different missions and tried to make one side — either the presentation or publication side — more powerful than the other. It’s also true that in order to realize the value of enterprise content management and portals, you may, depending on you and your customers’ requirements, need two packages.

What to Know Before You Buy

Before you buy either a portal or CMS solution, it’s very important to clearly outline what your expectations and business requirements are for these tools:

  • Does your organization sell information, widgets, or both?
  • Does the user experience for your customers in one vertical market resemble others, or does it need to be totally customized?
  • Are your publishing requirements really personalized, or just segmented?

In other words, does John Doe need to be able to indicate his preferences or subscriptions to certain content so that he can effectively sift through that content, or is it enough for John to say that he’s in financial services or aerospace and see all the relevant info accordingly? Also, beyond a single public Web site or intranet property, what are your other publishing targets? Print/PDF? Personalized email newsletters? Wireless devices? XML feeds for your customers to consume in their own formats? What about language variants? Do you re-use the same content in multiple places? Does the experience integrate with an existing ERP or CRM system? Does John need to get an email broadcast about a myriad of content items based on his subject matter interests? These are non-trivial user experiences that need to be designed and documented before you choose your package.

Defining Requirements

Getting specific about the end-user’s experience (or, if you like, “who gets to see what, where, and when”) is always the best way to begin your requirements gathering process. It’s critical to document and cross-reference all of the presentation methods (Web site, portal, print media, etc.) with all of the content and applications that are found on them.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 2
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Remote Work Tops SF, NYC for Most High-Paying Job Openings
Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Flash Poll