Thursday, March 20, 2008

Why JSR 170?

The Java Content Repository API (JSR-170) is an attempt to standardize an API that can be used for accessing a content repository.

Various CMSs from different vendors have been on the market for quite some time, and all of these CMSs ship their own version of a content repository. The problem is, each CMS vendor provides its own API for interacting with the content repository shipped with that vendor's CMS. This is a problem for the application developer, since he has to learn a particular vendor's API and potentially tie up his code with one particular CMS implementation.

JSR-170 tries to solve this problem by standardizing the API that should be used for connecting to any content repository. With JCR-170, you develop code by only using the javax.jcr.* classes and interfaces. This should be able to work with any JSR-170 compliant content repository.

You can think about JSR-170 as a JDBC-like API for content repositories, allowing you to develop your program independently of any particular content repository implementation. At runtime, you can configure this program to work either with a natively JSR-170 compliant content repository (e.g., Communique or Apache Jackrabbit) if your repository is not natively JSR-170 compliant (e.g., Documentum or Vignette), then you can use some kind of repository-specific JSR-170 driver that takes care of converting your JSR-170 method calls to repository-specific method calls.

The JCR-170 API has different advantages for different stakeholders in content repository space.

Developers do not have to spend time learning each vendor's repository-specific API. Instead, once she is comfortable with JSR-170, a developer should be able to work with any JSR-170 compliant content repository. In the past, developers had to make choice between a CMS with great features and poor development tools, or one with great development tools but poor features. Now that the interface between content repository and CMS applications is standardized, you can choose the best choices from both worlds.
Corporations won't have to face problem of vendor lock-in. More commonly, many corporations have more than one CMS either because different departments choose to use different CMSs in the past, or because some acquired company used a different CMS system. In the past, corporations spent a lot of money getting these different systems to interact with each other. With JSR-170, they can be assured that same application will work with all CMSs.
CMS vendors were forced to develop and maintain their own content repository implementations, which meant lots of infrastructure code. Now they can leave development of the content repository to some other vendor and concentrate more on their core competency: developing CMS applications.

Read more...

Portal Content Management

Organizations need to provide timely, relevant information to customers, partners, and employees anywhere in the world, to meet today's business requirements. Some of the hurdles that the organizations face in achieving this are IT bottlenecks, information getting lost, irrelevant and outdated information. If these problems are not looked at properly, then this will lead to escalating costs and ... erode customer satisfaction which will be a great loss for the organization. One good solution for all these problems is to create and deliver highly relevant content on a portal.

Companies can deploy a unified content and portal infrastructure to meet its business goals. This infrastructure should have tools that can unify content and infrastructure between portals to provide a consistent user experience and tools that can empower non-technical users within the organization to create, manage, and publish their own information to enterprise portals. In addition, the tools enable distribution of trusted, up-to-date, and accurate information to support multiple portal initiatives including partner extranets, and employee intranets and add content intelligence to increase the relevance and targeting of information for end users.

Problems that arise due to IT bottlenecks in the content contribution process and problems due to administrative overhead in the portal publishing process can be solved by empowering non-technical business users to contribute content to the portal. When you need to provide a unique infrastructure for the portals of partners, employers, and customers, you can unify the content and content infrastructure between portals to provide a consistent user experience. When end users need to access multiple applications and repositories for all of their content, content across enterprise applications can be integrated and delivered to accessed portals. Portal content management solutions not only empower non-technical users to within your organization to create and publish their own portal content but also ensures that the information published is relevant and personalized to serve multiple portal audiences

Some of the key benefits of portal content management include the ability to manage more content assets at lower cost, publish portal content faster and improves the reach of relevant content to the appropriate audiences. In addition, portal content management also empowers non-technical users to easily publish content on their own, increase online collaboration with partners or customers, and achieves better, faster integration of content via integrations with enterprise applications.

Portal content management software provide a simple, web-based user interface for creating and publishing content to portals, to empower non-technical, line-of-business users to create, manage, and publish their own content. The Portal content management software also provides a powerful navigation system for editing and updating content within the portal. Portal content management solutions ensure that only relevant content is delivered to each audience based on an enterprise taxonomy that drives content tagging and categorization for creation and powerful attribute search within the portal. This ensures that the content and metadata published are mapped to personalization rules created and deployed in the enterprise portal.

Powerful attribute finders of Portal content management software enable end users to easily locate content within the enterprise taxonomy that is exposed as intuitive, browseable categories in the enterprise portal. The enterprise content management platform of Portal content management software provide robust enterprise content management services such as workflow, versioning, lifecycle management, and security. Enterprise integration services provided by Portal content management solutions enable easy integration of transactional data from enterprise applications such as ERP, CRM, etc.

Read more...

Thursday, March 6, 2008

Web Services in Content Management

What is Web Services?

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format.
Web Services is another form of an RPC based communications, not completely unlike CORBA or COM+ but its platform neutral.

Steps to implement Web Services

- The service directory is a central place where clients of a web service can query for a published Web Services.
- After clients find the service, the clients have to know how to interact with the service.
Therefore, we need something explaining how to perform operations against a web services. The description will also explain the operations and message format.
- The Service Message is what the client creates to send to the web service to perform an operation.
- Lastly, there is the communication protocol to interact with the service.

Current CMS Functionality

- Library Services
Library services are similar to a library catalog system. It allows certain people to view, check out, review, view meta data, and track version of content.
- Categorization
Most CMS products allow the warehousing of classification terms for the classifying of assets. Then the CMS will store the terms in the library system as meta data.
- Search
This is the mechanism that allows the users to find CMS assets.
- Distribution
This is where many of the products on the market differ. Some product deploys content, to a file system. Others can deploy content to a database. Yet some others can replicate content to a proprietary caching system. Then of course some products perform a mixture of the previous.
- Workflow
Most products have some sort of workflow sub system to allow content creators and managers to implement some sort of business process around their CMS assets. Here some products have a very robust workflow engine and others have very simple engines.
- Transformation
Lastly, most content management systems allow for transformations of content. Either converts XML content to HTML, standard office application files to PDF, or video files to jpegs, and many other transformations.

How can Web Services improve CMS?

In today's business world, enterprise content is a corporation's secret weapon -- and Achilles heel. Corporate records and information, including e-mail are being seen as assets that need to be managed and mined for information.

But there's a downside to all that enterprise content as well. Increasing regulatory requirements for financial reporting, managing health care records, keeping e-mail and more places big burdens on corporations.

To solve the problem, enterprises turn to content management systems. Increasingly, vendors are turning to Web services as the glue that holds content management systems together and that ties them into the rest of the enterprise.

Let's imagine that CMS services can be exposed to other applications through a Web Services interface. The illustration above shows some of the methods that could be made available to other applications, either to invoke within the CMS, or to utilize for content outside the CMS repository.

Consider this scenario. Your company regularly releases new products, both to its e-catalog and out to its distributor channel. Upon doing so, you need to deploy content related to those products to various websites. Using a services-oriented architecture, your company's product data management or e-commerce systems could activate the CMS distribution service to push particular content into production (even related content outside the CMS) when certain products get released. If that's too automatic a business process, the workflow service could be triggered instead, to activate an approval process.

This is possible today in a few of the more developed CMS products that have packaged up their APIs as Web Services interfaces.

Read more...

Wednesday, February 27, 2008

Steps to select a CMS product

These are suggested steps to research Content Management System options for your organization, large or small. They can take you from knowing nothing about CMS to final vendor and product selection. Even if you are replacing a CMS with a new tool, you should follow these steps in the CMS lifecycle.

If you are a larger organization you will probably hire consultants to do some or all of these steps for you. Just insist that they document how they covered each step of the way, and get them to put the results in your hands.



Step 1. Organize Your Content. This means getting the staff who now manage your content to inventory and structure it. It needs to be categorized and labelled, arranged well for navigation, and perhaps indexed and abstracted to support searching. You will probably need an Information Architect, but be aware your current website may be an excellent first draft for your content architecture. If you don't know the content workflow (who's doing what, what some call your business processes) beforehand, a CMS is more likely to be a problem than a CM solution.

Step 2. Search The Web. This is the least expensive step and the most powerful. And once you learn what is out there, you will use it over and over in the steps below. The CMS Review site attempts to list all the valuable places on the web with information about content management.

Step 3. Books and Articles. Articles are free, books range from $20 to just under a hundred dollars. If you bought them all, it would still be a tiny investment compared to most consulting fees and the license fees for any proprietary CMS. You will need the time to read them, or assign a couple of trusted people to read them and be your advisors.

Step 4. Vendor-neutral Consultants. You can hire top industry experts, like Bob Boiko, Tony Byrne, JoAnn Hackos, Gerry McGovern, James Robertson, or Ann Rockley, for a few thousand dollars. They can provide a day-long seminar for the key people in your organization who will be your CM team. If you have completed step 3, this step will be twice as valuable, because you will understand better the necessary jargon and technical terms of the industry. You will get much more out of the seminar and consulting advice if you are prepared.

Step 5. Magazines. Advertising in the magazines is an indicator of companies that are strong at the moment, and may be more valuable than many articles in the magazine. They can help you narrow the range of vendors. Annual subscriptions are $50 to $100 or more, but you might buy single issues of all of them to see who is advertising prominently.

Step 6. Industry Analyst Reports. These range from a few hundred dollars to $1000 or more. They will assess company viability and also technology trends that point to newer CM techniques and CMS tools that implement them. Be aware that some analysts may have strategic relationships with large CMS vendors, professional service agencies, and with information technology consultants.

Step 7. Trade Shows. No single content management trade show is a must for all the industry players, but they provide a chance for you to talk to the companies and see demonstrations of their latest products. Speakers will often provide an overview of the technology you are considering. Costs are usually several hundred dollars, and if you travel you could spend thousands of dollars for a 3-day show.

Step 8. Vendors. Directly approaching the vendors costs only your time. They will want to contact you, perhaps sending a sales engineering team. Remember that this adds greatly to the cost of their products. If their sales team only closes one sale in 10 prospects, then your purchase must recover the cost of the nine failures. So try to postpone their sales calls until after step 11 or 12.

Step 9. Vendor-specific Consultants. Once you have an idea of possible vendors, you should use consultants who know those products very well. They may be suggested to you by the vendors. You can also find them on the CMS mailing lists. It is quite possible to take this step before approaching the vendors themselves. Reputable consulting firms who have experience installing more than one product may guide you to the ones best suited to your needs, but be aware that they may earn significnat fees or commissions from the vendors. Hourly and daily consultant rates vary greatly, and some may expect the bulk of their fees to come from the installation, training, and rollout phase as they work alongside the vendor to get your system launched.

Step 10. Needs Analysis/Specifications Document and Request for Proposals. Your consultant will have been through this and can prepare your custom version. Chapter 16 of Bob Boiko's book ($35) is a comprehensive checklist you can use to assemble your own specifications, and there are requirements checklists in the appendices of books by Ann Rockley and JoAnn Hackos. Boiko's CMS Planner ($300) and James Robertson's Requirements Toolkit ($550) will provide tools and templates to work through the process. Robertson's Internet Roadmap ($130) is a fine tool that charts five parallel processes from business strategy to final CMS selection. Our Features List is another resource.

Step 11. Demonstration Systems. Whether it's a canned online demo, or an interactive "sandbox" (where you can upload your own content for testing), these are free opportunities to learn the interface and toolset you may be living with for some years. You should get the people now managing your content to test drive the system, instantiating your content workflow, and get their "buy-in" to its capabilities.

Step 12. First cut. You should limit the number of systems to two to five at most.

Step 13. Prototype Sites with Your Content. Serious vendors who make the cut will probably agree to build you a prototype site with some of your content running. If it is a really high-end system, they may want to be paid for this step. If you are looking at seven-figure license fees, these charges may be justified. Far too many companies have invested millions of dollars in a CMS that went unused once the content managers realized its limitations. If you can afford it, this step should include stress and performance testing to make sure it can handle your traffic levels.

Step 14. Timetables and Milestone Agreements. These will vary with the size of your organization, the amount of content to be managed, whether it is a migration of existing content or a new build, etc. You should ask the vendors and consultants to provide examples of timetables for similar installations. Take these timetables seriously. Many failures are traceable to lack of realism in assessing the time and energy needed to bring up a CMS.

Step 15. Final Selection. You are nearly there. Just remember that choosing the right CMS cannot be done from any number of its (claimed) features. A CMS is right and the features are real when your organization is using it every day. A CMS is only 20% purchased software and hardware. It is 80% the process of people using the tools to implement a content management strategy.

Read more...

Thursday, February 7, 2008

Primary Responsibilities of a CMS Developer

Content Management System Web Developer

Primary responsibilities include:

1. Build components within the Content Management System (CMS) to ensure future scalability, clustering and reliability.
2. Coding Java Server Pages (JSP) using custom tag libraries.
3. Independently explore and develop the internal architecture and design of the CMS without direct daily supervision.

4. Responsible for the full project lifecycle from initial specifications to designing, developing, testing, migration to production and post production support.
5. Work very closely with the technical and web design leads.
6. Work with other staff members to provide training and support for using the CMS by content authors, editors, and approvers from throughout the institution.

Read more...