Going Headless: Governing Content & Capabilities
The need for purpose-built marketing capabilities has created a demand for modular backend services, resulting in a move away from monolithic Digital Experience Platform (DXP) solutions. Expectations for Digital Experience (DX) are now greater than ever, and we continue to see growing budgets dedicated to digital transformation. To set our clients up for success, we work with them to provide the most flexibility from the start. This includes orchestrating content from multiple sources as well as leveraging Machine Learning to unlock the value of customer data and drive one-to-one interactions across channels at scale.
Adopting a decoupled architecture lets us combine capabilities from multiple vendors and capabilities developed internally. This gives us the ability to produce solutions tailored to our client's business that can be extended over time as capabilities become available. Single platform DXPs offer predictability by providing best practices around implementation and workflows. The finite set of capabilities, however, that make a DXP predictable becomes an obstacle as needs evolve.
Decoupled systems help solve some of the limitations of the single-platform approach. Combining backend services allows organizations to compose the best-of-breed solutions tailored to their needs. But tailored fit and adaptability provided by decoupling systems create the need for additional governance since we lose the guardrails that we get with a single-system solution.
When we say headless, decoupled, or composable, we are talking about business capabilities delivered through APIs that can be combined into larger solutions. Moving to a composable architecture brings power and flexibility, but also requires a more API-centric mindset, and in many cases, a new way of doing things therefore we need to approach it as a program for it to scale. If we look at large-scale adoption, here are things to consider as you get going:
- Have business goals and sponsorship;
- Start with a strategic pilot;
- Identify a team(s) with proper skills and augment where necessary;
- Design the Experience Architecture;
- Have a Design System;
- Establish Experience Operations.
Define Your Goals
You will need to clearly define a set of goals around headless and the business value they unlock. Goals should be easy to understand and ideally have a value and be bound by a cost and date, something like, "The improved user experience delivered by decoupling systems will increase conversion by 3 percent during holiday peak." Whether it's capabilities, cost, and/or agility, get it out there. It will serve as a general reference and provide plans to demonstrate value in early releases.
The move to a decoupled system will impact how departments collaborate, and communicating goals clearly across the organization is key to getting the alignment needed for success. Leadership needs to buy into the broad vision early and understand the near-term goals to provide the support required to make the project successful.
A headless program will span multiple teams and will most certainly face some initial headwinds. Aligning on the long-term aspirational vision, some achievable short-term goals, timing, and the value you’re looking to bring to the business will help leaders embrace the program and help teams understand how it will impact them.
You will be explaining things often and to a variety of audiences. We recommend using clear language that is accessible to all levels. Having shared goals defined, understood, and supported by leadership will get the buy-in needed to succeed and avoid many headaches.
Run a Pilot Program
A successful pilot simplifies messaging by quickly demonstrating value, building the trust needed to unlock the budgets for more significant initiatives. A well-designed pilot avoids the institutional headwinds common to high-visibility projects by acting as the reference model for introducing new processes and capabilities.
Making the pilot low-friction and showing tangible results provides valuable evidence needed for internal stakeholders to buy-in. A well-designed pilot illustrates the story around the tools, gets adjacent teams thinking about their use cases, and avoids getting people too caught up in technical details. Make it something you can deliver in less than a quarter.
In contrast, more significant initiatives have more organizational inertia to overcome and get more political. When taking a monolithic or a hybrid approach, where we weave headless features into a preexisting system, we increase the institutional complexity, slowing progress and introducing risk. By starting with a successful high-visibility pilot, you demystify the tools which reduce stress and prepare the organization for some of the operational change associated with updated workflows.
Assemble a Team
There is no out-of-the-box for headless. The primary team will start to establish the standard practices around decoupled systems and support them through enablement. That will require experienced business and technical leads with a clear vision defined by business goals and the resources to deliver the vision with fidelity.
The initial team will be responsible for architecting and delivering the pilot and the vision for expansion. A decoupled architecture requires heightened collaboration between creative and technical departments. Therefore, the primary team will need to have the right cross-functional hard and soft skills to bridge any communication gaps. As the project evolves out of the pilot phase, units that can operate autonomously will start working more closely as a shared core model gets established.
It is essential to have the right mix of institutional knowledge and experience to hit the ground running. A standard solution is to set up hybrid teams using both internal and external resources. Use consultants to act as guides for the initial phases. Experience is critical, use contracted talent to augment your internal team as they develop expertise on the platforms and best practices.
Also, contract resources to smooth any spike in resources needed to launch the initiative. Individual product vendors can provide excellent guidance within their platform. Still, their expertise and worldview remain skewed to their product, so they are not incentivized to guide the high-level architecture.
Define your Taxonomy and Experience Architecture
Content is the fundamental building block of a composable architecture. We need a structured approach to content in order to drive successful journeys. The taxonomy formalizes how we classify and catalog content. By standardizing the types of content and structure, we can work at scale. The taxonomy gives us the structure to define metadata which simplifies content management and provides the hooks needed to deliver connected cross-channel experiences, personalization, and machine learning, across touchpoints and business units. A well-crafted taxonomy gives us the hooks we will need to introduce the advanced features the business is asking for.
Experience Architecture articulates the user journeys we need to deliver and acts as a guide for mapping personalized content. We have to account for evolving content and data sources like UGC, search, analytics, customer data, machine learning, and an array of personalization engines which will be combined to deliver contextual experiences across channels.
We have the content and signals to design highly personalized customer experiences. But we need to account for the business user experience. There need to be well-defined processes and interfaces for business users or journey creation will become a bottleneck. An optimal authoring experience is intuitive and designed around how the business operates, allowing team members to do routine tasks independently without hopping between systems. The internal authoring experience that manages interactions with back-end systems needs to be defined in a way that remains intuitive. The Experience Architecture and taxonomy give us what we need to define the high-level architecture that can evolve as our marketing capabilities grow over time.
Establish Design System
Design Systems unlock the communication between marketing and engineering. To deliver personalized content, marketing needs to deliver more content faster. Creative has a different cadence than engineering, which becomes a point of contention. A solid design system that embraces the principles of Atomic Design provides a vocabulary that abstracts content creation from the engineering needed to deliver it.
A complete design system lets the marketing folks design, author, and publish across channels without the help of a developer. But more importantly, it provides a framework for marketing to request enhancements using a common language. It then allows engineering to develop the enhancements with technical rigor in a reusable way that integrates with company data and personalization platforms. Finally, the design system establishes the vocabulary that engineering can work with to build, support, and evolve the tools marketing uses all day.
Source: Design Systems 101, Nielsen Norman Group
Experience Operations: How We Deliver Experiences at Scale
Experience Operations (XOps) streamlines the operational tasks required to deliver experiences with better velocity and stability. Analogous to DevOps, XOps is a set of processes that optimize the reliable deployment of new and updated experiences by combining QA and Operations with content creation.
With a defined experience architecture and design system, we have a blueprint for building journeys and their associated experiences. But we need processes that give business users' ability to access capabilities and assemble experiences regardless of the mix of content services available. We also need to provide creatives the agility to design experiences while fostering creativity and experimentation.
As the platform scales with the business, we need to maintain delivery and authoring usability. We need an architecture that can grow as our audience grows while delivering complex experiences during peak traffic. We also need a simple and powerful authoring experience to serve many business users with minimal enablement.
Using Packaged Business Capabilities (PBC), we can break monolithic systems into logical blocks of composable elements that can pivot to the needs of the business and gracefully scale. In addition, building content and experience pipelines simplify and accelerate production by automating testing and deployment at the experience level. And finally, by breaking functionality into smaller business-specific components, we can build continuous integration and continuous deployment (CI/CD) tools that bring speed and reliability.
Composable Architecture Offers a Competitive Advantage
Successfully implementing a composable architecture offers a competitive advantage by adding capabilities, increasing marketing agility, and unlocking creativity. Moving to a decoupled architecture can be complex, but with a bit of planning and solid communication, it is possible to demonstrate value quickly. Most importantly, it unlocks customer value by providing the best-in-class user experience they deserve.
