The CMS Story: Why You ll Want to Implement CMS in Your Environment

The CMS Story: Why You'll Want to Implement CMS in Your Environment

When Web sites were being initially developed and published on the Internet, the designers of these sites were driven primarily by the need for the sites to be attractive and to hold the viewers' interest. They were right, of course, but we soon learned that sites had to be more than attractive. They also needed to be easy to navigate and offer timely, accurate information that was relevant to the site visitor.

This was difficult to achieve because information was static on Web sites. In fact, many sites were little more than glorified company brochures. The information presented in these sites was the same for every visitor, making personalization of the site impossible. Hence, we were faced with trying to build sites that contained information that would be relevant to a wide audience and yet meet the needs of multiple, distinct audiences.

In addition, updating static information was expensive because of the coding efforts of creating each page. And common workflows that were used to update existing data in these sites were cumbersome and not able to quickly react to changing conditions.

The upshot of all these factors was that the promise of the Internet becoming the delivery vector for commerce did not meet expectations. What we learned was that if we were going to use Web applications and the Internet for commerce in any serious manner, these problems we've outlined here needed to be addressed and solved from both a development and an infrastructure viewpoint. What was needed was a new way to conceptualize and deliver content on Web sites.

What CMS represents is a new way of conceptualizing Web sites. Instead of being primarily concerned about the design of the Web site, we are now most concerned about the content of the Web site. In other words, by using CMS, we can develop and deliver content-driven Web sites instead of design-driven sites. This is a fundamental shift in how we think about Web sites.

Content-driven Web sites address the challenge of frequent changes to the site content by separating the design of the site from the content of the site. This approach enables the design and the content to be created and managed separately. More to the point, your Web designers and graphics people can concentrate on what they do best: developing great site designs from both a navigational and a visual perspective. On the other hand, your business people can concentrate on what they do best: developing great content for your customers and other interested parties. There is no need for your business users to learn about the site design, and the reverse is true too: Your site developers have no need to learn about the business content that will appear on your site.

The advantages to this separation are multiple:

• Workflow is simplified because business users can create, approve, and manage content without needing to understand one whit of site design.

• Site designs can be customized for every type of content.

• Content can be changed quickly to meet changing business needs and goals.

• Workflows can be customized for different parts of the site, avoiding a one-size-fits-all workflow.

Obviously, content-driven Web sites are more difficult to secure than design-driven Web sites. With a traditional Web site, you had to concern yourself with who had access to the site over the Internet and from within your own organization. With a content-driven Web site, you'll need to be concerned about giving different levels of permissions to those within your organization who will have different roles in developing and delivering content on your Web site. Rights can be granted or denied to users based on the role that user has for the site. Content-driven Web sites will require more administrative effort, but this effort is more than offset by the efficiencies gained through the use of CMS.