This article is inspired by the slightly contrarian view that the lack of buying into an acknowledged platform or ecosystem for your business can become the new norm.

All views are my own and not necessarily those of any organisations whom I am affiliated with.

Let’s start by looking at what a Digital Experience Platform (DXP) is defined as:

“Gartner defines a digital experience platform (DXP) as an integrated set of technologies, based on a common platform, that provides a broad range of audiences with consistent, secure and personalized access to information and applications across many digital touchpoints.  Organizations use DXPs to build, deploy and continually improve websites, portals, mobile and other digital experiences.”


The better part of the last decade has seen a strong focus on all of us being wooed by large scale vendors such as Microsoft and Google to promote the benefits of their respective ecosystems.

The motivations are clear, go all in with a particular vendor in order to unlock synergistic productivity improvements through an integrated, secure platform. Whilst beneficial to many, this approach focuses on increasing the core value of an ecosystem by attempting to add more capabilities and features than the competition.

This vendor mandate can sometimes feel like it’s missing the key point from a user adoption perspective, that is – more is not always more when it comes to features and functions.

The ecosystem paradigm is largely (in my opinion) based on the assumption that end users simply want more tools. But sometimes we simply need a sharper version of what we already have or a decent hammer to drive in some nails we already have without having to buy a nail gun.

Increased choice of tools does not always converge on a better experience and can instead introduce additional confusion and fragmentation + friction of experience.

In parallel to this underlying need, I can’t help but notice the increasing number of new Software as a Service (SaaS) solutions that in the above analogy start to offer some really good hammers.


The new challenge that this shift introduces is how to bring all of these great solutions together into a unified, cross platform experience.

Focusing on the principals of not wanting to swoop in and offer ecosystem specific variants (as this negates the point of best of breed SaaS applications), this new approach demands a shift in traditional thinking of how to expose the best experience for the end users and ultimate consumers of these tools.

The end user end-game is akin to traditional Intranet / modern workplace platforms, but with the strict differentiator that the content and services displayed whilst seamless to the end user are sourced and ultimately curated disparately.

So we could ask ourselves how this paradigm is different from a current trend of an “Intranet in a box”? Well, very….

If we analyse the concept of a box in this context; we open a box and unpack a product that has been created for us. Typically when we order something that is boxed and shipped to us we can define some attributes such as colour or size, however what if we want something slightly different?

We can modify a “boxed” product ourselves, however for this we need specialised knowledge (and a desire to void any warranty) or, we ask the “manufacturer” to make some bespoke changes for us which takes time, money, and further locks us in to this model.

What if we challenged this model by thinking of receiving a box of Lego instead? We have a number of components which are all symbiotic to each other (ref will fit together) but come in different shapes and sizes.

We can buy more bricks as we desire and retrofit them to existing models we have made.

We can even follow some instructions to create a desired model whilst having the flexibility to go off piste or add to a plan without being considered unsupported. The net principal remains the same, we have a framework of components that come together to create our own personal ecosystem.


Looping these concepts together, ecosystem agnostic platforms such as LiveTiles Design can provide the ingredients (bricks) to create your own experience, regardless of where the underlying source information resides.

Following the key principles of an experience platform, these platforms can introduce a layer on top of your existing investment without the need to rework these underlying structures. The resulting experience can be hosted either on existing ecosystems (such as SharePoint) or on cloud (decoupled from an underlying ecosystem), or hybrid between the two.

With or without specialised platforms such as those provided by LiveTiles, the core concept of a DXP that transcends technology is the human element.  How do we surface relevant information to the right people, at the right time, from the right system – and enrich the overall experience.


There are additional use cases for a DXP:

  1. Refresh an existing solution without having to start again
  2. Reduce the time to benefit during migration projects

Solution refresh

To contradict my core observations of best of breed SaaS applications becoming the new normal, there are scenarios where a vendor ecosystem makes sense – such as Microsoft’s Office 365 platform.

Numerous organisations have leveraged the power of SharePoint Online specifically to create an existing “Intranet” or portal for their organisations.

Over time these implementations can feel stale and reside within the DNA or an organisation for many years past their best by date.  The challenge introduced to stakeholders and ultimately those who need to fund a rejuvenation of existing implementations is the realisation of the potential effort involved to unpick many years’ worth of structure, data, and business logic to effectively “start again” just to modernise or refresh the experience.

Enter our new friend and concept of the DXP… Given a DXP is a concept and not specifically a product, you can utilise DXP supported platforms such as LiveTiles to refresh an existing implementation by simply layering a new experience on top of your existing Intranet such as SharePoint.

Using this new DXP to selectively surface existing content such as news and/or documents against all of your existing security and governance controls – you can rapidly introduce a “new” Intranet without the associated heavy lifting of starting again.

An appropriate analogy would be where a department store refreshes their front windows with a new display to something that is engaging, on brand, and ultimately designed to entice punters into the experience (store).

Once you enter the store, items (or content) can revert to the more functional form as you navigate through the store into the various isles.

Migration projects

My final example of how a DXP can be employed is for large scale migration projects, particularly those between specific vendor ecosystems.

If we pause for a moment and focus on one key attribute of a DXP – the ability to decouple the end user experience or presentation of information from the underlying data.

Moving back to a migration example, consider we are moving from Google to Microsoft as part of a wider organisational initiative.

This is no minor undertaking as there are numerous steps involved ranging from identity management, to messaging, to data, to training and so on.  It is not uncommon for these transformational projects to take a number of years to complete.

Traditionally, the plumbing is put in (from a technical perspective) before we then paint the walls with what the end user will experience.

At this point we need to think back to our end users experience and what will be realised during the period of migration.

If the end game is a revised user experience – why not lead with this and pull through the required technologies?

With a DXP mindset you could create the new look and feel of an Intranet or Digital Workplace on the destination environment (e.g. SharePoint Online), create new news items in SharePoint, and simply surface up departmental documents in that context from the existing Google Drive document stores.

From an end user perspective the document location is not always relevant, and when various phases of the migration are completed – you can then modify the DXP to point to the new local repositories instead.

This approach enables users to experience many of the intended benefits up front, in parallel to the heavy lifting of the migration which will ultimately deliver the next phase of benefits associated with a migration business case.


A DXP is a concept that can be applied to shift focus onto how our end users experience and interact with information that is relevant to them.

Whilst many things, it can be seen as a layer that can either be retrofitted to existing solutions, bring disparate solutions and systems together, or create its own platform to act as the initial seed for future integrations.

Leave a Reply

Your email address will not be published. Required fields are marked *