The Ideal Technical Architecture for Experience Delivery at Scale

My recent blog posts have tackled the role of marketing in delivering customer experiences and the proper balance of organizational centralization/decentralization necessary to effectively deliver them. Now, let’s address key aspects of technical architecture that ideally support the delivery of superior Web Experience Management, or WEM.

Marketing cannot (and should not) own the complete customer lifecycle. The future of customer experiences will remain distributed among marketing, sales, customer service and support teams, but will be forced to become more integrated by design. This means that marketing has the opportunity to influence the design of great experiences at the later steps in customer journey, without having to assume full ownership.

Today’s mature marketing organization has developed core sets of expertise and core types of technology with which to deliver better web experiences. Core technologies like WEM enable marketing teams to apply their core expertise to best effect. To wit:

 

WEM suite architectures can cause chaos

The balance of centralization and decentralization is hard to get right. That’s why the first generation of WEM has tried to force marketing departments to pick a lane. The architectures of suites such as Adobe and Drupal require a centralized model – where a single project implementation team creates every digital experience the organization delivers.

As we’ve examined, taking a centralized approach leads to bottlenecks because it requires a lot of heavy lifting by IT. When an organization has lots of customer experiences to deliver, the WEM suite model breaks down completely. When 50 developers want to release simultaneously into these environments, the results are colliding code, version control issues, instability, poor performance... in other words, total chaos.

As a result, companies using the WEM suites often spin up separate instances of the system to support various web and mobile site projects – without sharing common services, data or design. Being forced to decentralize your site development efforts to speed things up leads to huge costs, choppy quality, lack of collaboration, brand incoherence and ultimately, inconsistent customer experiences.
Many suite vendors now offer hosted software-as-a-service (SaaS) options for customers; but deploying Adobe, Sitecore or Acquia in the cloud doesn’t solve any of their underlying architectural deficiencies.

 

6 key criteria of a more balanced WEM architecture

A centralized, open platform for WEM maintains balance. It allows all customer experience constituencies – marketing, sales, service or support – to autonomously share the assets, design, data and frameworks that marketing teams create. Meanwhile, the IT organization is still able to control the system’s performance, security and compliance functions.

According to Forrester, organizations that decentralize the creation of digital experiences in this way are said to have reached a higher level of digital marketing maturity.

Here are 6 characteristics of technical architecture that engender a more flexible, scalable WEM system:

1. Ability to unify user experiences. Websites alone can’t address every digital touchpoint on the complete customer lifecycle. Customers interact with companies via portals, applications and mobile apps as well. WEM systems that allow user experience (UX) design, models and components to be exported and shared easily with other teams and projects can deliver more consistently branded digital experiences to customers.
2. Support for multi-site management. Today’s enterprises maintain hundreds if not thousands of websites for divisions, regions or brands addressing multiple markets. Solutions built for a global distribution model can scale up to support unified management of all of an organization’s web properties from a common platform. Frequently organizations are most forced to decentralize development projects when the WEM system has weak support for multi-site management.
3. Open interoperability. Looking back at the list of core marketing technologies above, no one vendor can supply an end-to-end solution for every marketing content and data function (no matter what they promise). The need to integrate is a fact of life. A WEM platform with open interoperability makes this problem manageable or even solvable – because content and data can be served from virtually any third-party source, via a single point of integration, to enrich any/every web or mobile experience. All projects can share access via the platform’s common APIs.
4. A “low-code” or “no code” environment. Low-code development platforms are designed to enable rapid creation, quick setup and deployment of applications with a minimum of traditionally complex coding.  A “low code” WEM platform allows front-end developers with simple scripting skills to develop new web/mobile experiences fast. No need for a full stack application developer to write and test complex code or worry about application performance and stability. The integration is done with only a few lines of code, simple API calls or drag/drop of pre-formatted HTML/CSS. This means that implementation teams and partners don’t need specialized skills to get their site projects live – a key requirement to enable brands or regions to be more autonomous.
5. Support for parallel development. Truly distributed customer experience delivery allows many teams to be working on projects simultaneously. Any WEM platform promising multi-site delivery must be capable of handling parallel project development and deployment without requiring centralized code management and merge. Distributed development teams mean in-house or agency, international or regional, or line of business marketing efforts that need to share assets or data. In a parallel development model, components, content and code can be shared or “branched”. Configurations or customizations can be made project-by-project without complicating maintenance. Typically, this has been possible only on a true multi-tenant platform.
6. An elastic computing framework. To support hundreds of projects going live on a platform, scalability is an absolute requirement. Traditional infrastructures handle this by beefing up capacity to anticipate any possible traffic burst or performance requirement. The results are high costs and complexity.  In cloud computing, elasticity is defined as the degree to which a system is able to adapt and match availability of resources in direct proportion to changes in workload. Services are provisioning and released automatically. Simply put, elastic platforms can handle the pressure.  It’s capable of massive scale. Shared components take care of capacity, performance, uptime, upgrades, security, compliance, disaster recovery… so once the system is live; it stays live. Because services are provisioned in the cloud, maintenance becomes a non-issue for the IT department, saving precious cost and resources.