Enterprise Inheritance and Content Hierarchy
This post is my humble attempt to share what I have discovered from my experience to be a best practice in implementing IA (Information Architecture) and content hierarchy for an enterprise implementing manage sites within a single Sitecore instance.
As this is my first Sitecore blog, not to mention my first blog post ever, please feel free to comment and critique my approach as I attempt to contribute to the incredibly talented Sitecore developer community.
So let’s just jump into it, consider the following scenario: an enterprise has just acquired Sitecore as their CMS platform and wants to strategize on how they should implement IA and content hierarchy so that they maximize reuse and have a Sitecore instance that scales really well.
It is unsurprisingly common for businesses to decide to manage the entire company’s content within a single Sitecore instance and why not, since this is one of the easiest selling points for Sitecore, “Buy a single instance and you can build any many web sites as you want”.
The problem however is, as everyone in the Sitecore community knows, Sitecore installs as a blank slate with a “Home” node indicating it as your Site’s landing page. So intuitively, some eager .Net architects-turned-Sitecore architects tend to design content hierarchy something similar to:
As more experienced Sitecore architects/developers would immediately realize, there are several problems with this approach reusability, duplication of content, difficulty in content authoring, no scalability etc.
So what is the solution? Well it depends. But the general rule should be “Let content structure reflect the company structure”
What about IA? Well take a look at this:
This is where the power of Sitecore lies. A change to the Site’s base template affect’s only the single site’s items. To implement a change to every site in the operating company you simply need to make a change to the operating company’s base template and similarly for change to every site in every op-co simple change the base template of the enterprise.
As this is my first Sitecore blog, not to mention my first blog post ever, please feel free to comment and critique my approach as I attempt to contribute to the incredibly talented Sitecore developer community.
So let’s just jump into it, consider the following scenario: an enterprise has just acquired Sitecore as their CMS platform and wants to strategize on how they should implement IA and content hierarchy so that they maximize reuse and have a Sitecore instance that scales really well.
It is unsurprisingly common for businesses to decide to manage the entire company’s content within a single Sitecore instance and why not, since this is one of the easiest selling points for Sitecore, “Buy a single instance and you can build any many web sites as you want”.
The problem however is, as everyone in the Sitecore community knows, Sitecore installs as a blank slate with a “Home” node indicating it as your Site’s landing page. So intuitively, some eager .Net architects-turned-Sitecore architects tend to design content hierarchy something similar to:
· Site 1
o Home
§ Contact Us
§ Products
§ Services
§ …
o Shared Content
· Site 2
o Home
§ Contact Us
§ Products
§ Services
§ …
o Shared Content
· …
This then follows IA similar to
· Templates
o User Defined
§ Site 1 templates
§ Site 2 templates
· Sublayouts
o Site 1
§ Sublayout 1
§ …
· Layouts
o Site 1
§ Sublayout 1
§ …
As more experienced Sitecore architects/developers would immediately realize, there are several problems with this approach reusability, duplication of content, difficulty in content authoring, no scalability etc.
So what is the solution? Well it depends. But the general rule should be “Let content structure reflect the company structure”
What do I mean by that? Take a look at the following content tree structure
The typical structure here is that an enterprise generally consists of one or more operating companies and each operating company manages its own digital content.
Hence you see the content tree is structured similarly with “Reusable Content” typically housing taxonomy and component items that do not have presentation but can be reused at every level of the enterprise all the way down to an individual site. This way you introduce reusability, avoid duplication of content and keep some level of consistency with content.
Hence you see the content tree is structured similarly with “Reusable Content” typically housing taxonomy and component items that do not have presentation but can be reused at every level of the enterprise all the way down to an individual site. This way you introduce reusability, avoid duplication of content and keep some level of consistency with content.
What about IA? Well take a look at this:
If you ask a developer, he/she would say that this is even more important that content hierarchy as this defines multiple inheritance which is a major feature of Sitecore. The idea here is simple
- Start with creating base templates at the Enterprise level
- Then create base templates for operating company that inherit from Enterprise Base Templates
- Then create Site Base templates that inherit from operating company’s base templates
This is where the power of Sitecore lies. A change to the Site’s base template affect’s only the single site’s items. To implement a change to every site in the operating company you simply need to make a change to the operating company’s base template and similarly for change to every site in every op-co simple change the base template of the enterprise.
A similar approach can be taken for Sublayouts and Renderings to group them by Enterprise, Op-Co and Site.
I think this is a great way to get organized quickly in Sitecore. I hope you use take this approach and make it your own or feel free to suggest a better approach. This may seems very obvious to most but you will be surprised at the number of Sitecore instances out there struggling with scalability and reuse.
Comments
Post a Comment