I was really excited when I first heard that Sitecore was taking a stance on an architecture standard.  Over the years Sitecore developers would deep dive into the tool but really had no guidelines for best approach to actually building a site.  Over the years I have been with many different companies and have seen many variations to a “best practice standard”.  In some cases even adhering to a standard put in place by the business who had little knowledge of Sitecore.  Just that “this was their standard” for all development.  Some things worked great and some not so much.  We would take what we learned and apply the positives in our next project.

When Sitecore first released Helix guidelines and their demo site Habitat, I reviewed both.  At first I was a little taken back by it all.  I thought this was a standard that was rather rigid and would really not fit in the real world.  This was cleared up at last years MVP Summit.  Sitecore developers explained that Helix and Habitat are loose guidelines to get everyone communicating in the same way.  That you take what makes sense and go with it.  This made a lot of sense to me.

Earlier this year I was fortunate to sign on to a project that was designed at the base to follow the Helix standard.  Now that we are on the end of this successful implementation I thought it was a good time to share my perspective.

The part that really sets the stage for a Helix implementation is its layers.  You can read about the official usage in the Helix documentation.  Here is my simplified understanding of the three layers:

• Project – This is where site specific stuff lives.  Main layouts, css, and js.
• Feature – Anything and everything that you could identify as a module.  It could be navigation, a generic content page, or some complex search filter.  Basically if you want it to be reusable with different sites, this is where you put it.
• Foundation – Sitecore environment and global elements.  If you modify something inside Sitecore you put it here.  If you have something that could be referenced by multiple features or projects like a connection to a third party service or helper classes you put it here.

Now in theory this is a really good design.  In the real world I found that there can be a couple pitfalls to watch out for.  *Insert gratuitous meme to keep you interested.

Feature allows you to place modules in a position to be reusable.  This is great, but how often is one mega menu navigation going to be reusable in many sites?  Maybe your client has a very standard approach to their sites and this will fit well.  But what happens when you get into a situation where designers design a new mega menu that requires a strict html display to fit a javascript transition?  What if different departments want to handle navigation in different ways?  Where one needs to control each navigation element in a data source while another just wants pages to display dynamically as they publish?

These concerns question the re-usability of features and ultimately naming.  Probably the biggest pitfall you will find here outside of actually having to develop a new feature is naming.  If you start your first navigation with project name: Navigation, controller: NavController, view: navigation.cshtml.. then you may find yourself in a bit of a dilemma 6 months later when you are naming site 2’s new feature.  It would be advisable to make your naming conventions very specific or maybe go as far as bringing something to the project layer.

The second issue I have found is with finding that happy medium between foundation and feature.  Especially if you have multiple developers on a project who might not have the big picture, but just their segment.  For example, if you have a data layer class or models for a searching module, you might enclose it all in the feature project.  However it might come about that another feature is dependent on this data / items as well.  In this case you have to make a decision if you go through the process of moving to foundation or recreating.  Referencing another feature breaks the concept of Helix.

Ultimately having a good game plan of what goes in foundation and what goes in feature ahead of time is really important.  But having that foresight to hit every scenario might not be 100% .  In the case of a data layer that bridges the item to code, it probably makes sense to dedicate a foundation project to this.

Finally this approach does bring up concerns of portability.  It doesn’t happen very often, especially with Sitecore model supporting multiple sites in one instance.  But there is times, possibly business requirements, where one site lives completely independent on its own server.

A project centrist model makes this transition easier to make.  The project is contained.  You move it and you manage it as a separate entity.  In the case of Helix you now have to move foundation / feature with it and every time an update is made to these projects you have to also implement with the independent server.  In hindsight the most ideal situation is that is to just start this independent site off on its own separate Helix model.  But hindsight assumes that the plan was in place to do this in the beginning.

In summary I think the Helix guidelines are great!  The biggest reason for this is the ability to transform the industry into a like minded thought behind architecture.  Being able to sign on to an existing project and understanding how the architecture flows already is a huge time saver.  But understanding that its not a rigid guideline and watching out for pitfalls are important.  Start with Helix and adjust it to what you know works and what the project needs!

• Architecture
• Sitecore