Architecting an enterprise site.

Imaging you were approached by a client, and asked to build a site from scratch. No arbitrary constraints or legacy systems. What would you do?

My experience, whilst technical to a degree, is more focused on delivery than technology and I have found that the most beneficial way to architect a website that needs regular updates in both functionality and in content is to break the site up into logical segments.


By ensuring that all your data, whether it is content, assets, product information or anything else are consolidated into APIs, you ensure that you have a central "source of truth" on any particular element. You also conceptually move yourself away from hard coding or assuming a particular piece of information will only be used in a particular place. My theory is always that you should be able to use any piece of information in any location, application or situation you desire. Creativity starts when you give yourself the freedom to use everything you have, not rework to accommodate every constraint.

Single point of truth

An additional advantage of using an API to provide content is you have a single point of truth for your data. You know that if you are seeing a discrepancy between application A and application B that the issue will be one of caching or other temporary storage of information, not that there is a flaw in the transmission of that information. APIs mean you can trust your information. Anyone who has worked in software for a few years knows the pain of changing "@ Generic Software Company 2013" to "@ Generic Software Company 2014" on the first of January becuase data that should be, almost by definition, data driven, is hard coded into the pages.

Sharing data

One important reason to build APIs is that it means you can make that same information available wherever you need to. You are never in a situation where you have to retype, re-implement or otherwise rebuild the incoming information. You only need to render that information in a way that works for that application. This frees you up for addressing the rendering needs.


So, you have all these wonderful APIs providing you information, but JSON isn't terribly user friendly, even with a nice pretty JSON viewer in front if it (which in itself is a very thin rendering client when you think about it), you need to take that information and display it in a really nice way, elegant and effective, that will impress your end users. So, this is where you create the mechanisms to display that content. Because you have your APIs, you have something that ensures you can render appropriately for a requirement. If you need a separate mobile version (and that's a really sloppy approach when you can build responsively and I don't advise it) or more usefully you need a mobile app or two, you can take that data, and all the reliability it brings and render it in any way that you desire.

Content Management

Like APIs or Rendering, content management should be stand alone, and my personal preference is to separate out "Content" from "data" specifically, editorial or other copy and images away from the product data that drives the site. The CMS you use should output its data to the API, it should not get involved in how the content looks, so much as what the content is, and potentially the classes that wrap that content. Identify an element as a carousel and let the rendering interface show what a carousel looks like, after all, that same content will need a different carousel look on a one column mobile view to a full bleed website.

There are numerous reasons for the CMSs to be stand alone, but first amongst them is that it encourages that separation of rendering and output of data from where the data is located. When content management systems control rendering of the content as well as simply producing them, you are left in a situation that encourages duplication and replication of the same content as it is needed in multiple places. Consider something as simple as address information. By separating out the management of that content and piping it through an API prior to rendering it, you have a single call to get the address data that can be displayed on any of your pages, applications or mobile apps. It also means when your phone number changes, a single change can be relied upon to update all instances of the phone number.

Data vs. Code

The other thing to touch on is the dichotomy of how content and code end up on production. Code should move up a development pipeline. Starting at an integration environment, then a UAT, then a Staging environment before finally going to production. This is because code needs testing, and polishing. Imagine the code is a rough carved piece of wood. Every server in the pipeline is using a finer and finer grade of sandpaper so that when it reaches live, the wood is smooth and polished.

Content or Data however is very different. On the pre-live environments, testers and coders need to be able to enter dummy data, try unusual edge cases and put in content you would not want on production. This is why production content is entered onto the live servers (via a preview function of course) and copied back down the stack.The last thing you want is temporary and testing copy to be pushed up the stack like code and end up on production.