In a previous whitepaper Architecting omni-channel experiences for the enterprise consumer, we looked at the factors that influence the need for enterprise systems to meet the expectations of employees when it comes to interacting with corporate services across channels or devices. Now we’ll dive deeper into what’s needed to achieve an ideal end state and the additional opportunities that may provide. How close are you to the ideal state of data repositories, performance and content readiness?

IT departments in Fortune 1000 companies are working hard to embrace the new generation of expectations around having consumer-grade experiences on all their devices in the workplace. It’s no longer sufficient to simply support multiple devices – now consumers and enterprise constituents are looking at how well the transitions are handled when moving from one channel or device to another. Managing these transitions well is the defining characteristic of an omni-channel experience, and evolving existing multi-channel capabilities into truly omni-channel experiences is the new priority within the enterprise.

Similar to the push to support multi-channel, we’re seeing that the consumer space is continuing to outpace the enterprise when it comes to omni-channel implementations. Why can’t we get there faster? What takes so long? Technology experts within these companies will be quick to characterize the complexities that their enterprise solutions have to deal with as being greater than those in the consumer space. There is some truth to that, given the number and variety of heterogeneous technology stacks, custom applications, out-of-the-box applications, on premise, in the cloud, etc., it can be daunting to think about creating a harmonized experience if it means touching all of these pieces of technology. So how can we help align and inform an omni-channel project’s planning assumptions with those important perspectives? How can IT leaders make sure they’re laying the right groundwork to enable a current or future omni-channel solution? We can start by first making sure we understand the problem and goals of an omni-channel experience. Then we can consider some of the foundational enablers that are critical for an omni-channel solution. These enablers can serve as a checklist to assess readiness and identify potential challenges ahead.

Architecting the transition

Delivering an omni-channel experience requires that you think of the solution as one cohesive interaction that spans several points of access. It’s not a web site, plus a mobile site, plus an app. It’s a single experience and it needs to feel like one. Implementing these seamless solutions isn’t just a question of design philosophy, though. It requires architecture and smart application logic to ensure smooth transitions.

In the past, web applications had a “short-term memory” – you could expect a certain level of continuity within a given browser session, but once you closed your browser (or your session expired if you happened to be a bit too slow to complete a task) that experience was over. The next time you visited the site you were essentially starting over.

An omni-channel experience seeks to avoid this short term memory problem and overcome the limited scope of a browser session. These solutions need to support a much broader idea than a single session on a single browser or device. In order to support this, new application architectures and data models are required. Ephemeral browser sessions give way to persistent user profiles. These “experience” profiles should provide a mechanism to offer user information in a way that makes it easily accessible from all points.

Architects and developers need to carefully assess how to best support the design of those transitions that will be unique for each user journey and deliberately cared for in software.  For example, managers begin a human resource management system (HRMS) transaction on their tablet, but need help, so they transition to the desktop and go to the help section.  The solution may call for that help section to leverage the user experience profile to know that the manager has recently interacted with the HRMS and offer contextual help content, and / or offer to pick up the transaction where it was left off.  These types of detections need deliberate care, as part of a stated journey to be supported.  Anticipating which transitions the solution will need to support and what it will take to support them is a critical aspect of the architecture effort.

Rethinking data silos

Many enterprises continue to manage data in silos and only merge information into a warehouse for reporting purposes.  Many multi-channel and omni-channel solutions benefit from the efficiency and performance of merging otherwise disparate data into a central repository.   It’s sensible to think about leveraging the benefits of data consolidation that support a reporting warehouse (e.g., data aggregation and relation across disparate sources), and additionally consider data needed to support the front-end presentation needs of the omni-channel solution.  Database administrators need to anticipate the need to balance data that is consolidated for this use, adding management requirements, with data that continues to be sourced.

Equally important is whether the information is factored in a way that’s aligned with the solution.  It’s ideal to optimize the data for presentation as called for in the user interface (UI) of the solution.  For example, if a manager dashboard shows a count of how many employees report to that manager have upcoming vacation time in the next two weeks, it could be computationally expensive to query the repository for each page request, resulting in delays in page rendering.  Instead, when vacation time is updated, the data could be pre-calculated and stored in the repository for each of a manager’s employees. As with any application, performance is critical to a good experience.  In an omni-channel solution, performance will be quickly compared across channels, and any differences will be highly noticeable.

Movement of data through the ecosystem

The identification of key transitions is an important exercise when designing an omni-channel solution.  In most cases, these transitions will involve the same or related data being displayed or even changed as the user moves between channels.  Implementation teams need to understand what data is shown on either side of the transition and ensure its accuracy across channels.  Is the data captured in a different silo depending on the channel?  Do changes in the data need to be propagated to other systems or repositories in order to appear updated on another device?  Very often, existing extract, transform and load (ETL) methods that were built to solve a reporting need are simply inadequate to service the near-real-time nature of omni-channel transitions.

Managing the freshness of data across channels is not just important for a satisfying end-user experience.  It also impacts design.  If the implementation details dictate that there can be stale data across any channel, designers need to come up with ways to express that to the end-user, who knows nothing of the back-end architecture.  Sensibly introducing that variability and content into the screen design to react to latency is sometimes a serious challenge.

Instead of simply increasing the frequency of ETL processes to move data quickly from one repository to another, IT organizations may consider a “message”-based approach.  This is where different systems notify each other of changes via a message queue as soon as the change occurs.  This approach is attractive because both the sending and receiving systems process these changes at their own speed and convenience and only work when something happens.  Under normal circumstances this can result in a somewhat real-time experience, but performance may vary, especially under heavy load.

To eliminate delays, two approaches may be considered.  First, and perhaps most obvious, is to re-architect the data store such that all related channels can leverage the same repository.  While ideal, in some cases this may not be feasible, especially if the solution calls for combining data across otherwise heterogeneous systems.

Another attractive option, which can reduce or eliminate latency across channels, is to develop and create a direct application programming interface (API) into each repository.  The APIs will be well documented and optimized for consumption by the platform servicing the omni-channel solution, first and foremost.  Typically, the performance considerations behind such an API are similar to those of support for an end-user interface.  In many cases, capacity-planning efforts discover that there is no “extra load” on the system due to API usage, because the same functional scenarios are supported, and are simply using the API instead, so the net impact on performance is near zero.

Business rules that may be built into the legacy presentation layer of an application must also be safeguarded.  When creating a new API to a repository, care must be taken not bypass those business rules, particularly if they involve pushing data into the repository. In some cases, that may involve re-developing those same rules and baking them into the new API.  Ideally, the business rules that reside in the presentation layer are better leveraged once refactored into a more general data access layer, which can then be shared by any and all interfaces to the repository.

Content considerations

Consistency is key when it comes to omni-channel content.  Branding, UI elements, art and photography assets, all serve to give the end user a sense of continuity as they transition between channels during a single journey.  Legacy content management systems (CMS) may be challenged to stay aligned with the requirements of an omni-channel solution.  Authors need to provide consistent-yet-tailored content so that the transition across channels does not present a jarring experience or inconsistent language and terminology.  The role of the CMS as the cross-channel content repository should not be underestimated, and the authoring experience cared for as deliberately as the end-user experience.  Having various and distributed content management systems increases the burden on content authors, who play an important role in managing transitions through content.  A single authoring environment, with clear lines-of-sight to the journey being supported, serves to encourage this consistency and enable sensible transitions.  Ideas of Adaptive Content should be leveraged wherever possible to enable authors to operate in an environment that’s aligned with the holistic experience of the solution, and not just one channel at a time.

Adaptive Content in the Enterprise:  Challenges & Opportunities

Are you ready?

We discussed some of the key architectural characteristics that are important for any large-scale enterprise application, but are particularly relevant when enabling an omni-channel solution made up of multiple repositories, CMSs, application platforms, devices, and channels.  We anticipated how omni-channel transitions could shine a light on data performance and latency expectations.  We highlighted the need to consider the impact of multi-channel and adaptive content on an existing CMS so that it is not left as an afterthought.  While these are just a few areas to consider, they lie at the core of any omni-channel solution’s architecture.  If you’re anticipating or designing such a solution, evaluating your current architecture through these lenses should help you determine if you’re ready.