Sitecore Architecture Best Practices – Part 2: An Approach to Choosing The Right Sitecore Architecture Design Pattern
This blog post is part of the Sitecore Architecture series, where I discuss my personal approach to tackling Sitecore Solution Architecture and deciding on what pattern to follow. This article is especially important for architects and developers in general, as the decisions made in the early stages of the architecture design are of the most importance and will determine whether your flagship Sitecore code will sink or swim.
The Problem with Sitecore Framework Base Solutions
This is an interesting topic for me. I love beginning new Sitecore projects from scratch, gathering requirements, going through the design phase, planning and finally launching Visual Studio to lay the foundation for what will become another great Sitecore solution! This is the sort of feeling I used to get in my sys admin days when I reinstalled operating systems on computers – new fresh start, clean and untouched, yet full of potential. When an architect creates each solution, then defines projects within, coding practices, design patterns and so forth, she lays out the foundation, the base of the “house” to be, which is a great responsibility, since as we already know, the house is only as strong as it’s foundation.
Many architects I have come to know that work with Sitecore try to come up with a universal solution design pattern. Sort of a one size fits all approach. They focus on reusable strategies, designs, generalizing their code as much as possible (sometimes to the point where it’s so generic – it’s unusable). As a result many have their own Sitecore frameworks, prebuilt foundations, base site templates and alike. This makes sense from a certain angle, these architects want to spend less time doing the so called “busy work” and want to focus on decisions more important from their perspective. I however, disagree.
I was also once in the same boat – trying to generalize every piece of code, trying to componentize everything down to the closet in my bedroom, but I found that’s not always the best idea; I found myself in fact wasting more time trying to follow the unnecessarily complex patterns rather than focusing on the task at hand. As an architect, I feel that it is my responsibility to make things simple, easily maintainable, extendable, upgradable, easily understood, and align with the future goals of the business and level of knowledge of the internal development department, if one would be taking over the website (the last two seem to be overlooked very frequently).
Unfortunately, there is no such solution yet that can accommodate all these requirements – if the solution is very generic, well componentized and easily maintainable, it is most likely very hard. On the other hand we have overly simplified solutions that contain closely coupled code, which is a nightmare to maintain. This reminds me of a sign I once saw at a local business store – “We can make things well, quickly, and cheaply; however, you must only choose two.” This is very true, if we think about it, and applies to all aspects of development as well – what’s quick and cheap cannot be of good quality, things done quickly and well cannot be cheap, and it would usually take a long time do something well for cheap.
Keeping this in mind here are the problems that I have run into after a several years of Sitecore development trying to create framework like solution design patterns:
- Sitecore is a very dynamic CMS, where updates come out every few months now, introducing improved ways of doing things. What this means is that our framework solution must always be maintained to support the latest versions of Sitecore, which can become a can of worms.
- Base Framework Solutions never hit all of my requirements for a great solution design. They tend to be either overly generic, making them very hard to learn, or too heavy carrying too much irrelevant code, or just simply not align with the business goals and the knowledge of the developers who will be taking over the maintenance or future development.
This may of course sound very relevant to the type of Sitecore projects that I had a chance to work on; however, I would again have to argue this as well. I’ve personally worked on wide variety of Sitecore implementations – from small “minimal viable product” setups where the goal was to get a simple version of a website up for a small business, to large and insanely scaled websites squeezing everything possible and beyond out of Sitecore platform and .NET in general. What I have found is even when I was using a framework-like universal solution design and felt great about it being flexible enough to accommodate any scope creeps that clients would through at us – when it came time to train their IT team on the implementation, they stared at the Solution Explorer like deer at headlights. The complexity was just astounding. Well that would not be a problem, if the same team got to further support the project, you might say, right? Well, as we’ve covered above, Sitecore continuously improves its APIs, thus when having to maintain several projects running on different versions of the Sitecore, we would have to decide to whether keep doing things the old way for new versions, sacrificing quality, performance and many other reasons for which Sitecore introduced the new APIs, or create multiple versions of the “framework sites” that would accommodate each one. In the latter scenario, we usually cannot justify updating the entire library to support all the new APIs that the new Sitecore version provides, so more often than not it only gets updated partially. So, in the end we end up with a large number of these “Frankenstein” libraries that don’t support any Sitecore version fully, just because they are so bloated.
Keep your libraries lean then, you say? Well, then we are back to complex componentized solutions that no one wants to learn. In fact what’ve noticed is that developers working in very complex solution without comprehending everything that went into it, become worse at their job. Once they’ve given up on completely learning the architecture, they tend to not even follow some of the best practices they would have otherwise followed in a normal-complexity solution they are used to working in. It is sort of a Bermuda Triangle – all developers start up with good intentions, they try to understand the solution structure and the thought process that went into its design, however, after some time they give up due its unreasonable complexity. When they get a request for a code change, they try to fit their knowledge and experience into this overly complex solution, and at first it may seem to work. However, overtime, without properly following the established architecture design patterns, the solution becomes complex, and developers realizing that even their best practices are not working here; so they end up resorting to “just getting things done” type of attitude, which is the Kryptonite for all large implementations.
The Best Sitecore Solution Architecture Design Pattern in my Book
As you can see, I find it very hard to balance fulfilling all of the requirements for a good Sitecore solution design pattern with universal framework setups. So what’s my approach? Well, and this is why I always get excited about starting a new solution – I build a house from the ground up. Yes, starting with opening Visual Studio -> New -> Project …etc. I of course end up reusing and even just importing some code and projects from previously developed solutions and keep a few utility classes that are just handy and Sitecore version agnostic, however, all that is done only when absolutely needed. Only then I feel as I have enough control over the solution to customize it in a way that would fit all of the requirements for this specific project. Choosing quality over quantity – I make sure that every Sitecore solution that I design takes into account all of the requirements gathered from the discovery phase, from talking to the client’s IT department, from gauging their level of development knowledge, future business goals…etc. This way each solution aligns perfectly with each client, business, and stakeholders – and really, that is the most important thing in my book!
Another benefit I see to starting each solution from scratch is it promotes learning. Every time you go to New->Project or New->Class in visual studio, you subconsciously ask yourself – is what I’m doing truly the best way possible to do this? With a custom solution, you are not locked into any predefined patterns, giving architects and developers freedom to explore new and better ways of coding, which in turn keeps the job interesting for them and always delivers the best possible solution to the client. I don’t have one favorite solution design pattern, I create one for each project using the best development practices, latest technologies and industry standards.
That’s all nice and dandy, you say with a skeptical look, but what about your internal talent? They would then have to relearn a new solution design pattern with every new project, unnecessarily increasing the cost of each implementation that cannot always be passed on to the client (putting a consultant hat on). We mitigate this problem by creating a set of project design patterns that everyone is expected to be familiar with; we don’t create foundation projects for them, but we thoroughly document them. We bring requirements gathered during the discovery phase to the table, then decide which design pattern practices would best fit for this particular case.
There is of course an increase in bringing a new developer from the outside and teaching all of the design patterns, however, once learned – it is smooth sailing from there on. As far as the cost of training and additional research involved, some of it can be worked into the project budget, mitigating the financial risk, at the end of the day after we take away all of the tricks clients use to get the most for their money, when this strategy is explained to the client – very few ever say, “well, we really don’t want to pay a bit extra for getting a top quality product”. Sitecore clients are businesses, more often than not – medium to large with long term goals for implementation, thus, quality and maintainability rank high on their shopping lists.
Sitecore Solution Architecture Best Practices are Ever Evolving
Overall, this is the approach that I have found working best for me with the clients and technology available now – creating a custom solution for each project and bringing in reusable components and code on need basis. As time goes on this may change, which is expected and welcomed! Someone once said, if “I had the same views on life twenty years ago as I do now, I would have wasted twenty years of my life.” I strongly believe in continuous learning and improving, thus, I believe this is the best possible option for me to continuously deliver the best possible solutions to clients nowadays. With that said, I am sure everyone reading this article would have their own perspective on Sitecore architecture designs patterns based on their own experience, thus, I welcome any comments, arguments, and suggestions anyone may have on this. I would especially appreciate good arguments, they allow me to discover new perspectives, which helps me make better decisions in the future.
Now that we have discussed the approach and the thinking behind creating a solution architecture for our Sitecore project, what’s next? Well, next is we need to define the patterns we would like to follow in our solution – simple prototype, component-based, classic MVC, the use of onion architecture…etc. I personally love reading books on coding practices and architecture, continuously updating my toolset (would recommend all readers to do the same), thus, I have a predefined set of patterns I like using that I have found work best with Sitecore projects. In the next posts of the Sitecore Architecture series, I will go over the patterns I follow daily, in return I encourage everyone to comment with theirs, after all we are all here to learn!
You must log in to post a comment.