Make your model extensible, maintainable, and adaptable

Extensibility

Check what would be necessary and what would break if you tried to:

1. Add new elements/items/types
2. Change the order of elements/items/types
3. Change the names of elements/items/types
4. Change the structures of elements/items/types
5. Delete elements/items/types

Note down issues and other findings in a shared space where stakeholders can address the shortcomings as part of ongoing improvements. Incorporate this into your yearly maintenance. Addressing extensibility is tricky, as it involves ongoing content model changes, which should ideally be automatically reflected on your channel front ends. If possible, draft a specification on how the front end should be handling content model changes, which you’ve identified in the previous steps. Focus at least on the most important use cases. The front ends shouldn’t break if:

• You add items or elements
• You don’t fill out elements that don’t have validation setup
• You change the order of elements
• You change the name (not codename) of elements

Ideally, in other cases, the front ends should fail gracefully, and you should be notified of these occurrences automatically if possible. This is, of course, something developers are responsible for, but it first needs to be brought to their attention. To make your content model as extensible as possible, consider using and over-using content type snippets. Snippets allow you to essentially inherit a set of elements, guidelines, and validation associated with these elements. If you decide to change anything related to those fields, the change will be reflected everywhere they’re used. You can also add elements and extend your content model pretty easily that way. If you keep your hierarchy flat, 2–3 levels deep, you can still add a joining M:N relationship to connect content items that were previously thought of as unrelated.

Maintainability

Set up yearly content model reviews where you check how certain content types are used. This can be a joint effort together with content audits. Content audits are maybe even more important than content model reviews, so make sure you perform them regularly. Check if duplicate content is created due to your setup, for example, creating new content instead of reusing existing components. Check if the content pieces with high return on investment (ROI) are well maintained and if you are getting the most out of that content. For example, does it make sense to chunk it further to reuse parts of it elsewhere? Once you create your content model, check if you can simplify your content types and merge the ones that can be merged. Following approaches touched upon in extensibility, such as using content type snippets, will help with maintainability as well. Naming elements according to a predefined pattern will also allow developers to predict codenames in code. Although they can’t rely on it, it is much easier to write code if you have a predictable pattern present. This pattern is then also returned by the JSON, so the content model is easier to interpret. By using snippets, it’s easier to follow these conventions as instead of specifying the fields in multiple locations, you only do it once. Content type snippets also help with the simplification and merging of content types. This helps you keep the number of types low. Try to be as generic with your content types as possible while moving any specifics into the taxonomy of the given type (Article left & Article right vs Article with a taxonomy alignment). These taxonomies and some of the more generic fields might be implemented via snippets.

Adaptability