Home > Articles > Web Development > Content Management Systems

Overview of Content Management

📄 Contents

  1. From Prototype to Enterprise
  2. Terminology
  3. Universality of Assets
This article by Russell Nakano tells the story of a team that manages a web property and shows how the assets evolve over several years from an exploratory prototyping effort into an enterprise-critical business operation. The story highlights the core issues of content management. As it unfolds, it highlights the core issues of content management via commentary to illustrate how each issue originates, and to point out the approach that the team takes to overcome the challenge.
This article is excerpted from Russell Nakano’s book Web Content Management: A Collaborative Approach, published by Addison Wesley.
Like this article? We recommend

It’s been a hard day’s night, And I’ve been working like a dog.

—John Lennon and Paul

From Prototype to Enterprise

It has been a wild four years. Rita’s original idea was to build a web site in her spare time to improve the wooden suggestion box outside her company’s lunchroom. Over the years, the penciled suggestions on scraps of paper yielded insightful ways to improve product quality, manufacturing efficiency, and employee morale, to name a few. The suggestions bypassed the traditional chain of command, and although the suggestions were almost always anonymous, Rita’s group tirelessly made special efforts to respond seriously to each one. Perhaps the reason the aging wooden receptacle led to the changes that it did was the immediacy of the follow-ups. Paradoxically, her group had never been formally charged with being the keepers of the suggestion box. It just seemed to be the right thing to do. Rita herself could not have predicted the events that would follow.

2 A.M. Software

It is 1996, and the Internet Age has dawned. No one in the company recalls where the idea came from, but perhaps it doesn’t matter. Why not augment the wooden suggestion box with a web site? That way, employees outside that immediate location can participate as well. Rita takes on the challenge during evenings and weekends. She refers to it as "2 A.M. software."

As a skunkworks project, word of the web site’s existence spreads by word of mouth and internal email. The suggestion box web site enjoys a steadily increasing flow of visitors. At first, visitors from other company locations visit to see firsthand how the democracy of ideas within that humble support facility can lead to tangible improvements. Soon thereafter, suggestions from other sites begin trickling in. Many of the suggestions pertain to company-wide operations.

Rita is the sole part-time web developer on the project. Just before leaving for an out-of-town conference, she demonstrates a prototype to a group of product managers to explain the value of the suggestion system. The product managers offer many suggestions to improve the usability of the interface. After returning from the out-of-town conference, Rita dives into implementing their recommendations.

Without the usual distracting chatter of phone conversations filling the air, Rita adds the pull-down menus to the entry page surprisingly easily. She likes the way that her new menus remove the visual clutter from the page. Eager to show off the new interface, she asks a colleague to try it out. When he tries it, Rita realizes that she hadn’t tested her changes with the Netscape browser. They notice that her menus don’t erase properly. Because she hasn’t tested regularly with different browsers, some new code that she recently added is the likely culprit. But which change is it?

The one-week hiatus renders Rita’s recollection about the web site internals hazy. She needs help recalling what worked and what didn’t work when she last did the demo. Luckily, Rita versioned the entire source tree of the demo web site before leaving on her trip. She’s able to difference the files to figure out what changes are candidates for the browser sensitivity that she seems to have induced by her recent changes.

Web site versioning plays a crucial role in the web development process. It is essential to periodically capture known snapshots of the web site, as we see in Rita’s early efforts with the web site. Snapshots serve several purposes. First, with a known snapshot of the web site, a developer can roll back to a known good copy of the web site. Second, if the web site or a section of it becomes hopelessly broken, a developer needs to be able to selectively pick assets to revert to. An asset is an electronic artifact that embodies intellectual property of an organization. Having a known working set of web assets lets a developer proceed to make changes with the assurance that there’s always the ability to compare to a working copy for ongoing development. Finally, a working copy can be used as a reference copy, to discern what changed and what didn’t. Typically, only a small fraction of a set of files changes from one day or week to the next, which makes having a reference working copy of a web site invaluable for locating the changes that led to a problem. The core issue of site versioning typically arises distinctly early in a web site’s life cycle.

The Pioneers

The team expands to four members. Rita is now the web architect, an informal leader of her band of renegades. They soon find themselves doing independent tasks. Sandy is the lead quality assurance engineer whose primary goal is to build a test harness for the business logic embedded in the web application. She has also volunteered to prototype the online help system. Max is the CGI developer, and he is converting the text file–based suggestion repository to use the corporate-standard commercial database. James is the interface designer, and he explores ways to simplify the interface.

It is Tuesday. James breezes past the unattended reception desk. He hears a few clattering keyboards from the early risers in the office. As he settles into his cubicle, he listens to the reassuring sound of the coffee maker gurgling the morning’s first pot of coffee. James reloads the page that he changed yesterday before he went home.

"What happened to my changes?" James cries out, as he throws his hands into the air. He rechecks the URL to verify that he’s indeed pointing at the right location. The reality sinks in. Someone has overwritten his changes with other changes last night. James gets to his feet. He silently paces the aisle.

Later that day, after much wrangling, the team decides to adopt a practice that gives each developer separate areas to do their work. James does his best to re-create his changes from memory.

Two months pass. The team works 18 hours per day 7 days per week to prepare for its presentation to a corporate Internet task force. To build the team’s pitch, Rita gathers recent examples of business improvements that gathered momentum from their web site. She hopes to solicit support from the high-level executives charged with selecting and funding a promising set of web initiatives identified by the Internet task force.

James has numerous changes to the homepage file, index.html, and to the first-level pages, such as suggest.html, to deliver the promise of his slick new user interface. Max has changes, too. Although he has been working independently and in relative isolation on his database subsystem, it is now time to integrate that code into the homepage and first-level pages as well.

They hammer out an integration plan on Friday after their weekly status meeting, but when 2 A.M. Sunday morning comes around, Max finds that James hasn’t completed the changes that they agreed to. Either James has forgotten or his progress was delayed. Unfortunately, when Max snoops around in the directories on James’s development machine, he sees various versions of half-completed sets of pages. Max is stuck. He has to either make guesses about what James intended to do or call James at home. He relishes neither option. He had intended to finish his integration Saturday night because he promised to help with his niece’s sleepover birthday party on Sunday.

We see the issue of managing concurrent changes coming to the fore when the group reaches four members. Because each person is off doing different projects, and especially because of the nature of web technologies, they hit a "web-wall." This is the point in the life cycle of a web site when the combination of number of developers, the number of assets, and the pace of development exceeds the ability for informal coordination mechanisms to adequately do the job.

The Tornado

Named a finalist by the Internet task force, the team gains additional funding and grows to 20. The pace of change outstrips the ability of any single person to keep track of changes. As of August 1998, the team is tackling the following projects:

  1. Converting to template UI for rebranding

  2. Writing scripts to regenerate UI

  3. Implementing a better help system

  4. Reimplementing form entry based on templates

  5. Building a client portal

Each project involves a cross-functional team of two to four developers. The project to regenerate the template-based user interface has a scripting component, an HTML component, and a user interface design aspect. Keeping track of any one of these projects taken on its own would be difficult enough, but keeping track of any two of these projects simultaneously is beyond the grasp of a single person. All five projects taken together require major infrastructure assistance.

In August, James leads a three-person project to convert to a template-based user interface for branding purposes. The release date is near, and the team is deeply involved in testing. Meanwhile, Joe leads a two-person team getting started on implementing the help system. The help team feels strongly about checking in partial releases of their subsystem. Because they have the suggestion system itself to receive client feedback on their help system, they feel that the potential gains outweigh the risks. The help team has content that has been approved and is ready to send to production. On the day before that, the template team plans to have their subsystem ready.

Project completion skew occurs as the team grows to a point that individuals are doing different things and multiple groups each have a different project focus. In other words, each project is coping with contributors on a project who are working on diverse activities, and each project alone has a need to develop, integrate, test, and review their work before their project can be integrated into the live web site. Inevitably, projects run concurrently, and they don’t all finish at the same time. One project might be getting underway while another project prepares to wrap up its work. There needs to be a way to keep the work separate.

This problem became especially acute for Rita’s group when James and Joe led separate projects. The changes from one project interfered with the other. Because they hadn’t introduced separate edit areas, some of the unfinished changes for the branding project mixed in with the finished changes for the new help system. The mixture of finished and unfinished work proved problematic.

Joe works with the marketing department to build a weekly news section of the web site. For the first few weeks, Joe moves the weekly updates to the production site himself every Saturday at midnight. When that becomes tiresome, he and James agree to share duties on alternate weeks. It gets worse when the marketing department decided to push changes more frequently, now three times per week: a Monday edition, a midweek edition, and a weekend edition of the newsletter. Both of them agree that they need a more automated system. One day over lunch, they wish for a system that will deploy precisely the assets that they specify, at a predetermined time, and to notify them by pager if the automated system encounters errors.

Deployment comprises the processes and practices by which web assets that have been reviewed and approved are copied from a development environment to a production environment. The goal of a deployment infrastructure is to copy assets to the production server into the right location at the appropriate time. Assets no longer on the development side are deleted from the production side.

An important organizational underpinning of a deployment infrastructure is the "release agreement," which binds the development and production groups into a social contract. Content and application developers agree to approve and formally submit any asset to be deployed, and production server administrators agree to use only released assets on a production server. In a well-designed deployment infrastructure, only someone who is authorized to initiate a deployment job does so. A well-designed deployment infrastructure copies assets into production with minimal or no effort, with full control, notification, and the ability to roll back to a known-good version.

Rita’s gang needs an efficient and reliable deployment mechanism almost from the very beginning. Although moving a handful of files to production is simple when taken in isolation, the small overworked staff soon finds itself buried in small trivial tasks that nonetheless are prone to error. It becomes especially difficult when the person copying the files isn’t the one who made the changes and, therefore, isn’t familiar with the files.

With multiple editions of the newsletter per week, and the increased visitor volume, a misstep in the handling of the numerous content sources is bound to happen. Sure enough, it happens at a particularly inopportune time. The company brass had quietly begun investigating the feasibility of selling the web operation to outside buyers, or alternatively, to conduct a public offering. Therefore, it is especially embarrassing that the lead article on a Monday edition of the newsletter misspells the company name of a new partner company. Worse still, it incorrectly identifies the job titles of three of that company’s executives.

Workflow is the process by which people collaborate to develop assets within a content-management system. This issue becomes important when several people collaborate on a job where wait time is a significant proportion of the total job time and where patterns of interaction are repeated frequently. Workflow improves productivity by minimizing the wait time between successive steps, and it automates the business logic of an organization.

One important benefit of workflow is its ability to automate routing, review, and approval of jobs. A second benefit is the ability to enforce a formal business process, as the web operation becomes larger. This advantage becomes especially important when the operation spans different departments.

Rita’s group introduces a formal workflow system after the misspelling fiasco in the online newsletter feature article. The rapid growth in the staff justifies investing in a workflow solution because it ensures that each set of changes has had proper review and approval.

Go Dot-com

Rita’s department spins out as an independent corporation in April 1999. The marketers adopt a dot-com name, ezSuggestionBox.com. Previously they were a division of a small manufacturing company building educational aids for K–12 and the higher education markets. Now they are an independent 100-plus person company. Their customer base is growing, and they have seven major initiatives moving at web speed simultaneously. The industry analysts refer to them as an "application service provider" in the untapped higher-education market segment. Inside the company, they realize that their growth and ultimate survival as a standalone company rest on their ability to continually enhance and extend their service offering, while maintaining their 24x7 uptime promise.

Some of the company’s initiatives immediately change the current web site. For example, without advance notice, the marketing group decides to insert a series of banners on the homepage calling attention to an improved notification service. Other initiatives move at a more deliberate pace, such as the ongoing effort to completely replace the homegrown script-based notification system with a commercial product from a third-party vendor.

Each banner project goes from conception to assignment, to implementation, to review, and to approval within four hours, through the rollout of the new service. But the integration of the commercial notification engine takes six weeks. Neither change can afford to wait for the other.

The issue of long-term versus short-term projects becomes important when there’s a long-term web development effort going on concurrently with short-term changes to a web site. The essential point is that there are changes for the long-term branch that overlap with changes for the short term, and the changes cannot go to production together. For this reason, the development efforts are split apart and done separately.

Rita’s gang encounters the challenge of managing what essentially amounts to two distinctly different web properties. On one hand, there is an ongoing sequence of short-term changes to insert a new banner on the homepage, for which each takes only a few hours to go from implementation to approval. On the other hand, the deeper and more pervasive changes to integrate the third-party notification system take weeks to complete. The solution to this problem involves setting up separate "branches" of development, where each branch corresponds to a logically independent web site.

As the scope of the web operation expands, corporate marketing plays a larger role in directly creating content or sponsoring the creation of content by outside contributors, known as stringers. Nina, the corporate marketing manager, is an example of an inside contributor. When she assembles a press release, she focuses on the market positioning spin, the strategic sprinkling of third-party endorsements contained within the press release, and the go-live date of the release. At the same time, she defers to the art director’s guidance on the layout of the press release detail pages on the corporate site. The same goes for the choice of font for the title on the press release summary page. Most of all, Nina appreciates that previously written press releases will be automatically reformatted to the current design rules.

Separating content from presentation is also known as templating. The assets that comprise a web site must be factored in a way that allows many members of the web team to make changes concurrently. A content contributor is someone whose domain of responsibility focuses on the information content within a web site. Another department or group typically holds responsibility for determining the form of the presentation of the content. Because a large organization finds it essential to separate content from presentation, it centralizes art direction decisions, while it decentralizes content creation. This separation becomes more pronounced as an organization grows.

This is exactly what we see in this story. Nina, the corporate marketing manager, focuses on creating content. Divorcing the content from presentation lets her reuse content in many different situations, some of which was not anticipated when she created the content. For example, another manager uses a one-sentence summary of her piece as a caption on a promotional graphic. For Rita, the key is to design a content-capture framework that maximizes the opportunities for the content to be reused over its lifetime.

By the middle of 2000, ezSuggestionBox.com expands its operations worldwide. Two regional development centers operate out of Boston and Chicago. To satisfy the customer traffic, production web farms operate in San Jose, Boston, Chicago, and London. The total asset base has grown to 500,000 web assets. Multiple content servers, geographically dispersed, host the assets.

The issue of handling very large-scale web sites arises when web operations spread over development locations around the world, or when the volume of web assets exceeds the capacity of a single server to handle. Scalability of the software and hardware infrastructure is an essential consideration, regardless of the particular choice of technology.

In the case of ezSuggestionBox.com, the developers find the need to distribute assets among several content-management servers when their operations expand into regional development centers. They reap the benefits of each development center using a common infrastructure for content management and the basic framework extending to handle future growth in assets.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020