Sitecore Best Practices: Information Architecture

The Sitecore Best Practice Blogs ( obsolete this blog post.

This post about information architecture is one in a series of blog posts listing Sitecore Best Practices. Not all of these are specific to Sitecore, and in no specific order:

  • When defining requirements, focus on information architecture, which includes data template and standard values definitions including workflow, layout details, and insert options, the content tree, and other relations between items.
  • For performance and usability, attempt to implement balanced tree, where most items have a few children, some items have dozens of children, few items have hundreds of children, and no items have thousands of children. Avoid data structures that could require presentation or other components to iterate over large numbers of items to perform common tasks. Consider performance usability when opening a file system directory that contains hundreds of entries – it becomes impossible to find anything.
  • Avoid information architectures based on specific technologies. Don’t base data structures on what makes sense to the developer; ensure that data structures makes sense to users and result in friendly URLs.
  • Consider first implementing presentation wireframes to develop a foundation and evaluate presentation options, and then add more complex data types, markup, functionality, languages, and applications.
  • When defining information architecture, try to use security inheritance.
  • Separate data into fields as much as possible without affecting performance and usability.
  • Implement repeating fields as multi-select lists, child items, using an iframe field, custom editor, or custom field type to edit an XML field value.
  • Store relational data that does not require CMS services such as versioning, translation, publishing, and workflow in a relational database, not in Sitecore.
  • If the number of fields affects performance, consider replacing fields with child items.
  • Use data template inheritance unless the data source or another field property varies by template.
  • Create descendant templates with no fields when standard values differ in different uses of a single data structure.
  • Consider Multi-line Text fields instead of RTE fields whenever possible.
  • When defining item structures, consider locking, workflow, and security.

Related resources:

Next in the Sitecore Best Practices blog series: Presentation, Coding, and Configuration.

This entry was posted in Obsolete. Bookmark the permalink.

7 Responses to Sitecore Best Practices: Information Architecture

  1. Jukka-Pekka says:

    Very good points John. I would add also to organize templates, renderings in component or section named folders, if working on multisites its good to think about site specific structure as well. This way you can reuse them and updates to future releases is easier. Fewer templates is not necessary good thing. Templates are "free" make many data templates and inherit, its good way to make exceptions in presentation test="@template = \’xx\’"

  2. Jukka-Pekka says:

    I am not sure if I understand this: "Store relational data that does not require CMS services such as versioning, translation, publishing, and workflow in a relational database, not in Sitecore." could you please elaborate it a bit? Example?

  3. John says:

    As an example of relational data, online shopping sites processes orders. Orders are relational – an order relates to a customer, multiple lines relate to an order, each line refers to a product number, and so forth. I don\’t see a natural hierarchy for order data that couldn\’t result in an item containing thousands of children. You can store relational data in Sitecore, but because this data doesn\’t use CMS services, just store it in a database like you would for a standalone ASP.NET application. In fact, publishing orders data from the Master to publishing targets could be a problem, because you might want to access test orders data in content delivery but a separate orders store from content delivery, and publishing wouldn\’t allow that. Plus, you would have to write the orders back to Master from the content delivery servers, which is possible but raises a few challenges. If you instead use a database for the orders, content management and content delivery (and even development) can connect to the same orders database (or different databases, as needed), you can integrate the orders database into other systems without introducing dependencies on Sitecore APIs, etc. Think also about the test environment and testing the code – eliminating the Sitecore dependency helps. Note also that systems secure order data at a user level – this might also indicate things not to store in Sitecore (for example, use security providers for user profile properties). Think also about migrating order management from Sitecore to another platform if you ever wanted to make such a crazy switch. Basically, if the only CMS service you use the data for is rendering (not versioning, translation, anonymous/everyone/role-level security, publishing (separation of production from pre-production), workflow, etc.), or if content management and content delivery need to access different data sets (not different versions of one data set, but entirely different data sets), then you might consider a database for that data.

  4. John says:

    test orders data in content [management] but a separate [production] orders store from content delivery

  5. John says:

    In addition to CMS services, using Sitecore instead of direct access to a relational database also provides a user interface for each data type (defined by the data template and shown in the Content Editor).

  6. Unknown says:

    My blog on content tree design may also be a useful reference here: It hasn\’t been updated recently, but the information will still be relevant to those who are new to Sitecore.

  7. Pingback: Sitecore Webinar: Template Architecture - NewGuid.Net

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s