Overview¶

When building or redesigning a website, teams often hear the phrases "content architecture" and "content model." These phrases mean more than knowing what content is on the site. We define "content architecture" as organizing information that is meaningful and intuitive for site and platform users. We define "content modeling" as documenting the different types of content, and the content's fields, categorization, and taxonomies. This requires figuring out what content you need on your site, and how that content should be built within the website or platform.

A content architecture document will contain each type of content needed on the site, details of all the elements and components of each type, and how each content type is related to the others.

Content architecture is important for several different user groups:

• Content administrators: These users will be entering content into the system, so it is important that the content model is intuitive and consistent.
• Designers: Designers need to ensure that the content model contains all of the content and functionality listed in the designs. However, designers may need to iterate and update their designs to reflect any decisions or changes made in the content modeling process. The content model may contain content that is or is not visible to end users Hence the importance of having a clear model.
• Developers: Developers use the content model to configure the content management system. If the developer ds not have a content model or is given an incomplete content model, he or she will have to configure the CMS based on what he or she knows. This approach could lead to more complexity for both the end user and the content administrator, as well as lead to technical debt and additional development. 

The Process of Defining a Content Architecture¶

Drupal s ease of use means that content architects can add multiple fields to content types and entities with a few clicks of a mouse. As a result, some content models are overly complicated. A well-defined content architecture sets the development team up to build out the structure that best and most efficiently supports the company s business goals and functionality. Follow the steps below to create the most effective content architecture for your project.

Step 1: Create a Content Inventory¶

The first step in developing any content architecture involves performing a content inventory. A content inventory, which is a list of all content on the site, will not only assist in determining what content should be on the new site, but also in determining how content should be categorized and how it should be presented to site users. This process will also help determine content that is needed for the site, yet does not presently exist. The effort of formalizing an expected content inventory will facilitate project planning around workflow.

A content inventory should do the following:

• Every piece of content to determine its purpose.
• Document critical content details including content status:
  • Navigation Level
  • Title
  • URL
  • File Format
  • Author
  • Tags
  • Media Items (related images, videos)
  • Note which fields are optional versus required
  • Note dependencies related to specific content
• Determine the content's status related to the site/platform build or redesign:
  • Remove - content that should be removed
  • Rewrite - content that should be rewritten or edited
  • Move (to) - content that should be moved from where it lives now
  • Split (into) - content that should be split into multiple pieces of content
  • Create - content that should be newly created

Step 2: Create an Editorial Calendar¶

After creating a content inventory, you are encouraged to create an editorial calendar. An editorial calendar defines the frequency of content creation, review, separation, or removal (hourly, daily, weekly, monthly, evergreen). The calendar should also list the owner and/or source of each piece of content or content section. 

Some editorial calendars are heavily informed by a customer s marketing campaigns. Consider seasonality, regular events, and special events and how they may impact an editorial calendar. Also consider the timing of legal or other types of reviews in determining lead time or the round-trip time of content in the workflow, from initial alignment to publication.

Step 3: Put it All Together¶

Now that you have a list of content that you want to keep and/or create, it is important to determine how the content fits together on the new site or platform.

The first step is evaluating what types of content should appear on the site. There is not always a one-to-one ratio between content types and content with a specific editorial purpose. Although some content may appear to be disparate or even appear in different places on the site, if the two types of content are similar enough to share many of the same attributes, they may be part of the same content type. However, there are cases where the similarities between the two types of content do not lend themselves to be combined into one content type. The reasons why a developer would not want to combine similar types of content are as follows:

• The presentation of the content needs to be handled differently than the content with which it would be combined

• Content needs to appear in a particular section, such as a blog landing page or in a newsroom

The second step in the process is determining how your content fits together. The development team should ask the following questions:

• Does the content need to be structured? Structured content allows every piece of content in a section to have the same set of attributes. For example, a news article would always have a title, subtitle, source, body, and categories, and there would be distinct fields on the content form for editors to complete. These elements can then be used elsewhere throughout the site to relate content and allow site users to see more content (in lists of news article titles, for example). Structured content also allows users to sort and filter content. By contrast, unstructured content does not have an organized data model and is often one long block of text. Unstructured content is not reusable and users cannot sort and filter on it. Since you have chosen to use a content management system, you are most likely ready to take advantage of the benefits of structured content.
• Does the content need to be reusable? Will it only be used on one page or will it relate to other content? For example, if content is categorized by topic, do blog posts, news items, and events tagged to the same topic need to appear on the same page? It is important to note that content relationships are no longer manual in Drupal, and can be displayed via taxonomy terms/vocabularies, or by audience segment, or other means. However, you need to determine the relationships in advance and configure the content so that it appears where it is expected.
• If this is a platform or multi-site, governance of content and code comes into play, check out our general Governance planning documentation, and our Acquia Site Factory Governance documentation for important things to consider. 

Once the first two steps are complete, the development team needs to determine the attributes for each content type. Content type attributes are the fields that make up the content type, the taxonomy terms/vocabularies, and the metadata. 

It is important to consider the following: 

• Where these attributes will appear on a page.
• Whether they need to be styled differently on various sections of the site.
• Whether the attributes will be reused.
• Whether content needs to be sorted or filtered based on the given fields.
• What the data format should be for each attribute.

Using a content planning tool such as the Drupal Build Specification template assists with content modeling by supporting these activities in content model development. The content model in the context of the natural flow of content creation:

 

Note: Custom entities are single units of structured data that are used for persistent storage of content and configuration information.

You should complete the content inventory and editorial calendar steps upon committing to a redesign. These steps take the longest and inform the remaining tasks in the content architecture and content modeling process, and thus, influence the final timeline and budget for the project. Determining content types, their fields and attributes, and how they will be used across the site is an integral part of the discovery process and is an input to the planning and Phase 0 of the project. Finally, a full assessment of content that is new or edited will help to accurately schedule those efforts as part of the overall effort. 

IMPORTANT: Decisions related to content architecture and content modeling should be made early and often. Because these decisions affect the technical architecture of the application, any significant changes could cause delays in the project and could turn the content architecture and content model into a moving target rather than a defined model with a clear implementation plan.

Migration Recommendations¶

It is vital to think about how the content from your former site fits into your new content model. How has your data structure changed from the former site to your new site, and how can you successfully move content from one site to the next? The steps below outline the process to follow:

1. Set Up a Migration Team¶

The migration team should include:

• A Project Manager to sync the migration with the development schedule.
• A Product Owner to sign off on the migration plan, plus provide a final sign off when migration is complete.
• A Developer who owns the technical details about migration, and can define why each piece of data is used and how, and who performs the migration tasks.
• A Partner Project or Program Manager who is responsible for project coordination between you and your development team(s). The migration team will also include a developer or migration specialist who can assist with migration planning.
• Your DevOps or IT department may need to be consulted or directly involved during migration planning.

2. Review the Content Inventory¶

Review the content inventory for the content marked as delete, and manage that content so it is not unintentionally moved over to the new website or platform. This can be done by un-publishing content that will not be migrated prior to performing migration (as long as the migration script ignores unpublished content), or by making adjustments to migration scripts to ignore unpublished or undesired content.

3. Understand the Data and Start Mapping It¶

A customer needs to review the fields and attributes for their current site and compare them to their new site or platform. Determine what fields and attributes need to be moved and how they map to the content types/entities, fields, and attributes in the new site or platform.

To properly map the data, you may want to use a spreadsheet that can be shared across the team. The spreadsheet should list out the content types and what fields should be migrated. It should also include where the fields and attributes live in the current system, what they are named, where they should live in in the new application, and what they should be called.  If you have unstructured content, this may be more challenging or require more manual work on the part of content creators and editors, since unstructured content can only be machine-migrated to the extent the content follows specific rules.

If you are working with structured content, this process is simpler, and you only need to determine into which new content type/field each field from the old database will be migrated. 

An example of structured content mapping is as follows:

The plan should conclude with a determination of which content types are being migrated manually and which are being migrated programmatically; it may be more appropriate for content types with a minimal amount of content or simple content to be migrated manually, as the effort to script the migration may be similar to doing so manually. 

For migrating content programmatically from Drupal 7 to Drupal 9+, we suggest using Acquia Migrate Accelerate. 

You may also use Drupal's Migrate module. Each content type that is migrated programmatically will need a script. These scripts need to be tested early and often.

4. Dive Into the Details¶

A developer or migration specialist needs to dive into details such as:

• Reviewing the size of the database to determine how many content types there are and how long the data will take to transmit or copy from one source to another.
• Executing a small test migration with the proposed data mapping to determine what issues or inconsistencies may exist. 
• Additionally, it may be necessary to review the security of the data and determine the need for password protection or security certifications.