In a comment responding to Part 1 of my conversation with Forrester analyst Mark Grannan, Arjan van Rooijen, the chief evangelist with customer experience management platform provider SDL, said, “I strongly believe practitioners need to transform their practices to meet the demands of a digital era.”

Technology is not something that is happening to us, like a thunderstorm or a sinkhole or a presidential debate. It's the set of tools we use to communicate. The tools we choose — and the way we choose to use them — directly affects what we appear to be saying.

The complexity of fulfilling the demands that van Rooijen referenced should not be a problem with which we force customers to wrestle.

(Editor's Note: Mark Grannan will be speaking at CMSWire's DX Summit 2015 conference on Nov. 3 in Chicago.)

Abstract Terms

Grannan spoke with me about the idea of single systems of record, organized in such a way that the information they produce may be consumable through multiple means. Yet the method of that consumption is concealed from the systems.

In the parlance of software architecture (which, I admit, is more my native turf), the thing we use to conceal complexity from a system that is consuming services is called an abstraction layer.

The Forrester analyst suggests that individual processes, such as loan applications and approval and customer case management, can be integrated into workflows that lead directly to a singular system of record.

But the software upon which organizations rely today tends not to be structured in terms of consumable workflows.

They were never designed to be integrated. Furthermore, some of them were intentionally designed to never be integrated, as a way for their vendors to maintain their customers’ exclusive reliance upon them.

You would think that re-architecting systems around abstracted integration would require replacing some of these old, compartmentalized, task-focused engines.

“I think the notion of ripping those out or replacing them... I would like to stop that line of thinking,” said Grannan, “and start it with abstracting from that legacy complexity, by embracing a more core services mentality, backed up with a core services architecture.”

That’s not exactly self-explanatory, so I’ll break it down:

An API has become the tool with which services in a computing system cross over a layer of abstraction. We still call the players in this scheme “client” and “server.”

A client requests data in some particular format using an API call. The server responds either with the data or some signal expressing why it cannot comply.

A client may request that an operation be performed, or what software developers call a method. The server responds with the result of that request, either success or failure.

In a reversal of the typical order of events, a server may push an event to a client. If the client is “listening” for such an event, it may act upon the receipt of it.

These are limited syntaxes, but it’s surprising how the exchanges of data between a server and client can usually all be delegated to one of these categories.

Retrofit

A core services architecture rests upon the ideal that all data exchanges between applications in a system, can be either engineered or retrofitted for this model.

The retrofit process involves “legacy” applications, some of which predate the use of the word “applications” to describe customer-facing programs.

Making applications communicate that were never designed to communicate — or, again in software parlance, making them perform “as-a-service” — often involves the creation of a kind of proxy that represents the legacy application in API exchanges.

“Whether it’s an API management platform or some kind of SOA discussion, or maybe a BPM engine,” said Grannan, “there needs to be something that says, ‘I don’t care what the front end is, this is the standardized service.’

“If it’s retail,” he continued, “the service could be around submitting the order, shipping the order — these are standardized, repeatable services that are now consumed by the front end, in whatever format that’s going to be.  Now we can manage the front end and the back end independently.”

Enterprise architects (EA) will continue managing and guiding legacy applications, Grannan explained, slowly evolving and modernizing them over time.  But product managers and line-of-business managers, and in some cases marketing teams, will coalesce with IT to support the front ends — the parts of the applications with which customers directly interact.

Learning Opportunities

Now, we have to be careful here because it may sound like all we’re doing is demolishing existing silo walls to make room for new ones.

What’s important, first and foremost, is that these divisions of labor to which Grannan refers are immaterial to the customer. There is not a customer order department, a customer complaint resolution department, a customer suggestion fulfillment department and a separate, self-service kiosk to address the needs of customers confused by the vast number of departments there appears to be.

The organization provides one face to its customers, and adjusts the appearance of that face to fit whatever device the customer happens to be using at the time. It’s really all one channel, just multiple formats.

The Solidity of Flexibility

Grannan sees the opportunities for this fundamental re-architecture of services to be accomplished with the aid of an enterprise service bus platform, or an API management service such as Apigee, so long as it provides the necessary flexibility and abstraction capabilities to enable flexible front-ends.

By “flexible” here, Grannan means the acceptance that no single digital delivery channel will ever be permanent. Adaptation is the everyday order of business.

The flexibility of this delivery must become a principle in itself, he advocates, not just a topic left open for others to work out for themselves.  Marketing, sales, e-commerce, and IT should all be resolved never to treat the means with which they communicate with customers as fixed in stone.

However, by extracting the back end from the front end — the core service from the delivery mechanism — the way organizations manage their systems of record never has to be re-architected simply because the way the Web works changed.

“These technologies are adopted with a singular use case, or set of use cases, in mind,” he said, “and they’re built and executed that way. And if you look at it with that narrow lens, they’re a success.”

But the action of canceling a stock trade, for instance, should be perceived by the organization at some core level as one type of operation, regardless of whether it’s performed on the telephone (a 20th century device used for voice communication), through a smartphone, a tablet, a PC, a retail kiosk or an HDTV.

When business processes are designed around the employees hired to process them, then they become segmented, bifurcated, and unnecessarily compartmentalized.  And an entire, colossal integration scheme needs to be conjured for fusing all of them into a single form.

Data warehouses, in most organizations and institutions where they are used, are either mostly or entirely devoted to this kind of alchemy.

“Then that value, that success, goes out the window,” says Grannan, “because you didn’t solve for the customer’s experience. You solved for a process, for replacing a legacy technology with a new, slightly better technology.”

Call to Action

This November 3 and 4, at the W Hotel City Center in Chicago, CMSWire will sponsor two solid days of all-out discussion and introspection on the topics related to digital customer experience delivery.

DX Summit 2015 will feature Forrester’s Mark Grannan, plus numerous other industry leaders in the DX space including:Tony Byrne, founder and CEO of Real Story Group; Tami Cannizzaro, senior director, Marketing at eBay; Bruno Herrmann, director of Globalization at The Nielsen Company;Deb Lavoy, founder and CEO of Narrative Builders; digital strategist Meghan Walsh; and Melissa Webster, VP, Content and Digital Media Tech at International Data Corporation (IDC).

Here's where you have an opportunity to integrate with the world of customer experience, and not in an abstract way.  We hope to see you there.

For More Information:

Title image by Wil Stewart.