Digital Learnings in Sitecore & Cloud

In a Content Hub implementation you might often need to produce multiple different size of an image that you can link to from external locations. One way to do think in Content Hub would be to create multiple renditions and create public links to them, however there might be cases where you want a bit more control over which assets you create these links to and when in the lifecycle of your content you do this. In this case another useful functionality of Content Hub is the ability to apply conversions directly on public links. Within the UI you see that there a number of options for controlling the public link output: However if you want to control this programatically you will need to interact with the underlying entity record. Looking at the entity record for a public link, you see that this information is captured in a Property called ConversionConfiguration . However the content of this property is a JSON string -- so how do you interact with it from code? ...

We are now well and truly in the age of the API, however I feel that there is still a lot of confusion about the best patterns to put in place in how to structure APIs,  There are a number of competing patterns with some overlap and plenty of trade-offs, particularly in the space of building digital systems where the MACH alliance  is gaining momentum.  Some of the patterns you might have heard of include Microservices, Backends-for-Frontends (BFF) and domain services. I personally prefer to think about structuring APIs in terms of the different types of logic the a system composes of and how this impacts the trade-off between pace of change/innovation compared to reuse and stability.  These two forces are in constant tension in enterprise level development, and is well captured in Gartner's  Pace Layered Architecture  concept. Layers of logic I like to categorise the logic implemented a system into four different layers, as shows in the diagram below. ...

So has been a long time between drinks for my blogging activities! I thought I'd try to get back in the swing by capturing some of the learnings from our current roll-out of Sitecore's Content Hub platform. Content Hub is a pretty neat product, providing really good Digital Asset Management (DAM) capabilities along with MRM and what is called Product Content Management (PCM) which provides a light PIM capability. I think where it really shines however is in it's Content Marketing Platform (CMP) module. Perhaps more about that a little later. If you are used to deploying a platform like Sitecore XP where you have access to the product binaries to dotPeek at, and get really detailed logs, debugging issues within Content Hub can be a bit of a laborious exercise. As a SaaS platform you only get the documentation (which although decent is never as detailed as you need it to be) and some fairly high level error logging. The system is very configurable too, which gives you p...

In my last couple of posts I've talked about when to choose a multi-site versus a multi-instance pattern for deploying Sitecore, and how we approach delivering Sitecore platforms using feature based modular development . In this post I'm going to take a look at the sorts of issues that arise when large global organisations start to look at rolling out digital platforms, and how some we can leverage some of the points that we've covered in the last couple of posts as a part of our approach to designing a Sitecore based digital platform architecture that addresses them. Tyrannies of global size Large organisations hosting a number of different websites are often confronted by some competing forces which lead them to ask about whether they should have multiple sites in a single or multiple Sitecore instances.  These are usually related to the following requirements which address different types of web presence for different parts of a business: We have different site...

Deloitte Digital have been delivering enterprise digital platforms with Sitecore for over 6 years, and I think it is fair to say that we've learnt a lot during the dozens of projects we've delivered in that time. Yesterday we announced the open source release of our Deloitte Digital Atlas framework for Sitecore. Atlas is the underlying framework we use to deliver all our Sitecore implementations, providing a consistent set of tools and practices for accelerating high quality multi-site ready Sitecore platforms based on what we have learned across many years of enterprise Sitecore project delivery. Some of the features included are: "ORM" Sitecore fields mapper (including support for Experience Editor and also mapping non-Sitecore items) Extensible caching and logging frameworks integrated with Sitecore events Dynamic placeholder support Multi-site workflow and data source management We hope you find it useful, and even choose to contribute back to make i...

A modern digital platform doesn't just get built and then sit serving content pages for years without any changes or updates. Any system where you aren't continuously updating it to meet the needs of the business quickly becomes a legacy system, and other uncontrolled "micro-sites" will start popping up in other places (and all the FXM in the world can't make up for that!). The counterpoint to this however is that constant uncontrolled change to any system can result in a big ball of mud .  When your digital platform is a key organisational asset this might get even worse when you have multiple development teams on multiple releases or across multiple vendors all working on the system at once.  Even when delivering in a single stream using Agile principles your solution can get messy without a clear underlying architecture "skeleton" to which you can add meat. Sitecore's support for modular page composition through placeholders and modules pro...

I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec...