Playbook Case Studies

Company A:

To devise their enterprise integration strategy, Company A gathers a core group of stakeholders (product owners, business analysts, architecture, development, and project management) to discuss the project. The business team rattles through their requirements, such as increased productivity for employees by reducing the number of systems they were required to touch, and reducing call center hits by offering more self-service capabilities for customers and more. The discussion quickly becomes highly technical and tactical, focusing primarily on the tech teams sharing in-depth systems knowledge, identifying and defining the constructs needed (such as identity, authentication, authorization, and directories), as well as governance, policy, and legal constraints.

The team ends their first meeting by setting up a variety of follow-up meetings to discuss implementation timelines and roadmaps. However, there is no clear consensus on what the enterprise integration platform is intended to accomplish, other than “getting systems to talk to each other.” Without determining the business logic, their ad hoc approach focuses solely on short-term integration needs, rather than long-term solution effectiveness.

Many months (and hundreds of meetings) later, Company A managed to connect their existing systems. Although the services platform allowed systems to finally “talk to one another,” these layers of middleware remained disconnected from any business logic. The core team connected each system without optimizing the business’s’ touchpoints within the ecosystem, and thus, ended-up backed into a corner on many of the approaches taken. The architecture was left with chronic problems, unable to support business agility, provide ongoing flexibility, and lacking the services needed to manage business logic. They eventually created a middleware—for their middleware.

Company B:

Alternatively, Company B takes a different approach. They start with their core stakeholder group (product owners, business analysts, architecture, development, project management) but this team also includes a UX Strategist. As with Company A, the business team hopes the integration will increase productivity for employees by reducing the amount of systems users are required to touch. However, Company B also wants to extend functionality to their remote mobile workforce, as well as reduce call center hits by offering more self-service capabilities for their customers.

Company B’s architects know which systems hold which kind of data but are unclear how this data should be used to satisfy these businesses requirements. Then, the UX Strategist begins to ask the kinds of questions that paint a picture of how the end-game involves their users. How would it improve the customer/end-user’s journey? What would they see? What would they be able to do differently?

It becomes clear to each stakeholder that they each have a different expectation of what could be accomplished and delivered. Thus, the teams decide to focus first on defining the scope and business logic they are trying to target—meaning, the objectives that the enterprise integration platform is intended to accomplish. They start by developing an inventory of the teams, customers, products, and systems involved and then plan out a research and scope phase. Then, the UX team takes swift action.

[cue the action-themed background music]

Working with a variety of stakeholders, to conduct a variety of research activities, such as site visits, interviews, analytics, and data dumps. Their activities focus specifically on answering three critical details for the core team:

1. What is the current state of affairs (and all of its challenges)?
2. How is the platform intended to be used?
3. What is the ideal customer/end-user journey, including priorities?

During this phase, the UX team identifies a myriad of broken and ill-defined business processes that have spawned a stream of workarounds for users. Some more critical than others, these issues can cause a major headache for any business. For example, they discover a common practice of exporting customer’s Personally Identifiable Information (PII) to third-party applications for management and sharing via email. They uncover six additional and unnecessary third-party applications—apps that in essence, perform identical functions, each within their own vacuum. The UX team also reveals several monolithic legacy systems that house large stores of outdated information from an old company acquisition (only 10% of the data was still applicable to the current business). Finally, the team pinpoints critical gaps in the data needed to connect account management and customer self-service records with technician data from the field.

In the end, the UX team’s findings help level-set business expectations by raising awareness of just how much employee productivity is being impacted by disconnected and inefficient business processes, as opposed to technology-driven issues. The core team was also able to begin defining what the business logic looks like and how the middleware should support it. Finally, the team was able to efficiently prioritize the roadmap because the UX Team’s visualization of the critical business areas and processes supported by the integration.