Clean Architecture. Why it matters?

While reading Robert C.Martin, Clean Architecture book, I came across a lot of real-world scenarios where productivity of code vs revenue gets stagnant over few releases of the product. From the business point of view, you want to make sure that you are getting the most value for your buck for the stakeholders.

In the book, Robert mentioned a case study for a real estate company which over the years their productivity remains constant (after 8 releases or so) and the cost to maintain the code multiplied by 10 times. So, that means if you started with $1 Million budget, then now you are shelving $10 Million with less or minimal throughput.

So, what went wrong here?

Let’s look closely with some graphs (credit: Robert C.Martin’s book)

Graph 1:

As you can see that in this graph, we are seeing the sheer scale of engineering staff dramatically increases over the course of time. By 8th release, your staff is almost tenfold as compared to release 2. Not good!

Graph 2:

In graph 2, by the time you are at 8th release the growth of the code reaches a stagnant value. Clearly, something is not right.

Graph 3:

What really scary here is the cost and with every release its growing exponentially. Boy! Upper management is not going to love it. As Robert put it, this looks like a signature of mess.

Graph 4:

This is what developer sees. They started out with 100% productivity, but with every release, it went down.

Graph 5:

This is what executives see. You can calculate what is going on their minds…Phew!


Have you heard a saying “slow and steady wins the race”? Similar to this saying what happened here. Developers usually get into the game of developing without giving a good thought as to how to architect a better solution.

IMHO every architect of any project should take time to think and articulate as which of the designs will be better for the project. It is more to just coding! I firmly believe in clean architecture.

until next time…


Blockchain – Understanding the concept.

In this world, the businesses are moving forward with the seamless transaction structure. Whether you want to call out the airline or housing….or wherever transaction happens, you need some kind of seamless processing. That’s where blockchain technology comes in. The blockchain is not something new. Back in 1999, the file-sharing network Napster made it easy to share audio files on a hybrid P2P network. That file-sharing network did more than just share music files: It allowed all users to retain copies of those shared files such that a single digital asset resulted in a limitless number of perfect copies across a global network.

This structure has been coined years ago and the reason why we are hearing about it now so much is of course Bitcoin. ENTER THE BITCOIN WORLD!

In 2009, a new kind of infrastructure mined 50 digital coins and recorded them on a public ledger that’s replicated on a decentralized P2P network of interconnected computers. The remarkable thing about this blockchain is that it lacks any sort of trust authority or governance to validate each transaction. Everything is in public. Understanding how to engineer a public blockchain requires knowledge of cryptographic hashes, public key cryptography (PKC), binary hash chains (Merkle trees, in particular), and consensus algorithms. I’ll briefly review these concepts, and then I’ll show that a blockchain is a hash chain that contains a hash chain of transactions. Once you grasp this nested-hash-chain concept, you’ll understand blockchain technology’s fundamental design.

I will write more regarding different Cryptographic, Public & Binary algorithms in my later post.

What are the business benefits of blockchain?

In legacy business networks, all participants maintain their own ledgers with duplication and discrepancies that result in disputes, increased settlement times, and the need for intermediaries with their associated overhead costs. However, by using blockchain-based shared ledgers, where transactions cannot be altered once validated by consensus and written to the ledger, businesses can save time and costs while reducing risks.

Blockchain consensus mechanisms provide the benefits of a consolidated, consistent dataset with reduced errors, near-real-time reference data, and the flexibility for participants to change the descriptions of the assets they own.

Because no one participating member owns the source of origin for information contained in the shared ledger, blockchain technologies lead to increased trust and integrity in the flow of transaction information among the participating members.

Immutability mechanisms of blockchain technologies lead to lowered cost of audit and regulatory compliance with improved transparency. And because contracts being executed on business networks using blockchain technologies are automated and final, businesses benefit from increased speed of execution, reduced costs, and less risk, all of which enables businesses to build new revenue streams to interact with clients.

I do believe that when we had WWW back in the day, this technology advancement revolutionized the way how we work now. Blockchain will be the next -> WWW.

300+ Personalization Rules – What to do with Sitecore Caching?

As we all know Sitecore provides us caching out of the box. Call it, Prefetch, Data, HTML, Item and so forth…You know what I am talking about. Sitecorians.. 🙂

This article mainly talks about how we can better improve our caching strategy in our projects/solutions especially when you have about 300+ Sitecore personalization rules. Have you had a chance to tackle a problem like this before?

Recently, I came across a problem where the page load (the response time from the server was too slow). I don’t actually recall what is the exact number, but let’s say it wasn’t up to the par. And with about 300 or more personalization rules (OOB, of course) the page was showing us bad results.

So, we started digging stuff. From, debug from XP to figuring out in chrome dev tools. We could not find what was the issue.

There was one catch though! The 300+ rules that we have. With 1-10, the page was rendering fine, but 300? C’mon! There has to be a better way, right?

In our components, we were using external calls with setting up the JSON data coming back in Application Cache. So, all the external calls where getting set in Application Cache. It was set to 500MB and expiration of 240 minutes. We also avoided any call to the DBs or any APIs directly. Everything is stored in Application Cache.

One of the advantages of using Application Cache is if you host Sitecore in Azure, it will use Redis for the same purpose. So, you don’t have to utilize Redis externally. It will be picked up Redis.

This was our base class in Foundation Layer:

public Boolean SetCache(String xCacheKey, T xCacheObj, int xcacheDurationInMinutes = 0)
 Boolean bIsSuccess = false;
 if (xcacheDurationInMinutes.Equals(0))
 xcacheDurationInMinutes = _cacheExpirationTimeInMinutes;
 if (!_cache.InnerCache.ContainsKey(xCacheKey))
 _cache.InnerCache.Add(xCacheKey, xCacheObj, TimeSpan.FromMinutes(xcacheDurationInMinutes));

return bIsSuccess;

And this is how we are calling from one of the classes from Foundation layer:

public TestForCache()
// Check if the API results are available in Cache.
string cacheKey = Settings.GetSetting(Constants.MyCache);
if (!string.IsNullOrWhiteSpace(cacheKey))
cacheKey += "_" + Sitecore.Context.Language;
// If the result is available in cache, return the result
var cacheResult = CacheManager.CacheManagerInstance.GetCache(cacheKey);
if (cacheResult != null)
return cacheResult;
// Continue since no cache exists.
var lang = (string.Compare(Sitecore.Context.Language.Name, Constants.ES_US, true) == 0) ? Settings.GetSetting(Constants.LanguageEspanol) : Settings.GetSetting(Constants.LanguageEnglish);
var result = ServiceHelper.GetJsonResult(Settings.GetSetting(Constants.CacheKeyAPI) + lang);
// Set API results in Cache
if (!string.IsNullOrWhiteSpace(cacheKey))
CacheManager.CacheManagerInstance.SetCache(cacheKey, result);
return result;


As you can see how we are calling the storing all the cache operations from Base to the calling functions. This decreased our TTFB (time to first byte) and the first-page load response is much much faster.

Hope you will get something out of this post 🙂

Why you need Helix in your solution?

While back, I created a poll on whether if you prefer Helix vs. Non-Helix approach to the solution and most of you had an inclination towards creating a scalable, yet modular structure with Helix principles. The term Helix was coined long time ago which means decoupling of the projects (simple!). In the dictionary, it goes something like this:

“an object having a three-dimensional shape like that of a wire wound uniformly in a single layer around a cylinder or cone, as in a corkscrew or spiral staircase.”

Think you got the gist? No? Alright, moving on…


For the solutions that I have implemented on Helix, these are my findings. Hope you share and provide your thoughts as well:

1. Clean: Now, when I say clean, it doesn’t mean that cleaning your house or anything, but to able to scope out the code in a breath of time. Clean n Clear (not the face wash) solutions were always part of solution designing from the dawn of software development. Every person who is involved in software will tell you to make their projects clean and easy to understand. That is why I highly recommend the book Clean Code: A Handbook of Agile Software Craftsmanship: Robert C. Martin: 9780132350884: Books This book really shines the way how you design classes, functions, variables, etc.

Helix focuses on this. To make solution clean and easily identifiable.

2. Scalable: For any project that you want to do in software life cycle, you always want to make it scalable. Which means, it can extend or grow. In Sitecore terms, it means are you thinking of extending the solution to accept any multisite capabilities, outside caching strategy, external logging mechanism, language providers, 3rd party integrations, etc. Helix principles provide a way to extend your classes, functions, projects in a single solution.

3. Faster time to market: Anytime in any software application, you have to change something, build something, roll-off, bug fixes as quickly as possible and make it live. With Helix, it is easy to take care of requests like these. Everything is modular and flexible. Need to find and fix the bug = check! Need to extend some classes from Sitecore Kernel library = Check! It’s not as easy as it sounds (but you get the point).

4. Technical Roadblocks: How many times you have seen in the old software age that whether a class is too extended and is written in a millions line of code? Can you read it? Can you interpret what’s being written? Its hard, I get it. Technical roadblocks, or sometimes I say “Bad Code Written”, occurred a lot of times in our lives where we are stuck and cannot go anywhere. Either we have to start from scratch or…? I don’t have any other solution to this. With Helix, there are no technical roadblocks. Everything is scalable and easy to read. Making architecting fun!

5. Modular: Did I mention Modular in previous points? I don’t think so. Here it is: Having a modular structure always help to define which projects can be called as separate. One important thing to notice here is that not all the components you see on the page are features/modules. But, one key thing to note is that they are always acting as a separate entity. That is the power of calling them modular. If you have a Navigation, make it a separate project. If you have a Hero Carousel, make it a separate project.

In a nutshell, I think for every project, there are customizable solutions. But, at the core, it can all remain the same.

Well..these are the main points that I thought which make Helix easy to deal with and my life too  In the next, I will provide a tech whitepaper on a recent project we did using Sitecore 9 and SXA.

More to come…

Helix Principles Architecture: Part 2

How to setup your project for front-end developers.

In my last post, I have mentioned some thoughts on how to create a simple solution structure using Helix Principles. In this post, I would like to drill down a bit further. We will talk about where to store your CSS/JS for every feature and how to store them in your solution.

We are living in a totally different space where you have all the dedicated team around yourself to provide you the HTML/CSS/JS files. If you look at the Habitat site and solution structure, you will see that all of the assets are stored under Theming. Basically, Habitat provides us a single instance of the project to store all the required CSS/JS.

However, if you are working with a team of frontend developers, they will be checking out the whole solution along with Habitat.Theming project. They will be working daily on that project or at least setting up a gulp builds to create a main.css or any .css files.


There has to be a better way, right? After all, we are geeks. Our job is to make it better.

In my experience, I have created all the features under the website project under project folder. Something like this:


As you can see that for the frontend developers, all they have to check-in the files in this project itself. They can focus on the features listed here and push all the HTML/CSS/JS in. In this way, they are focused on one project only. So, does for the fonts for common and for each website:


Some of you might argue that why don’t we create a separate project for it? You can do it, but it will create another dependency on the project itself. For the website project, all the assets live at one place (even the default HTML file).

Let me know what will you change and how I make it better?

#sitecore #helix

Helix Principles Architecture: Part 1

Setting up your solution structure.

Nowadays there is a new facade of Helix principles and how to implement a solution based on it. Just to give you a brief, this is up and coming in Sitecore solution structure. The basics are these:

  1. Look at your website and broke it down to components (I am sure by now what I mean by components).
  2. These are going to be your features in the Helix solution architecture. However, there will be different views for this feature. So for example, if you have a Navigation, then this navigation can have:
    1. Primary.cshtml
    2. Secondary.cshtml
    3. Breadcrumb.cshtml
    4. Visual:
    5. 2017-05-17_1253
    6. You get the gist! Right? Good! Moving on…
  3. Now you have to look at the solution and decide what will go in Foundation Folder. Like this: 2017-05-17_1253
  4. As you can see there is a LocalDataSource project in which all the dependencies are listed which pertains to access the DB: Pipelines, Getting Item, ItemExtensions, you get it.
  5. Basically, you need to figure out what are the different way you can conglomerate various data points into one.
  6. Foundation layer does not suppose to change frequently. Heck! Why would you change the logical structure of getting the item from Sitecore DB?
  7. Lastly, there is a project folder which consists of all your sites. Even if you are creating one Sitecore site, it is a good practice to have a common site as your base site and a separate site. In this image, you will see the Common &Habitat project layout structure:

2017-05-17_1253   2017-05-17_1253

To wrap is up (been a long day), Helix setup might take some thinking to do and what really you want to achieve. But at the end of the day, it is a modular & clean architecture.


Sitecore DB Tweak

Some simple adjustments to the configuration of SQL Server can greatly improve the performance of the database environment.  Keep in mind that some of these settings may impact the backup approach you employ for MS SQL.

  1. Set the compatibility level to SQL Server 2008 (100) to take advantage of the latest optimizations.
  2. Ensure the auto-close property is set to false. This ensures that a page will only make one connection.
  3. Ensure the auto shrink property is set to false to avoid costly dynamic resizing.
  4. Ensure the recovery model is set to simple to avoid the high overhead of transaction logs.