In the previous articles (Build Requirements Around Real Journeys and Design for Real People) we have explored the application of customer journeys to market analysis and requirements development. In this last article of the series we will discuss a method to use the customer journeys in enterprise architecture.
End to end requirements cycle
If we look at the previously proposed process end to end, it starts with the customer journey. The journey is mapped to the internal business processes, systems, and data sources. For both the customer facing and internal parts of the journey user stories are created to document the gaps between the as-is and to-be states - effectively form the backlog for the change. For each story, acceptance criteria are prepared in a way that enforces the expected behavior in the system. Ideally, those should be the scenarios that are likely to appear on the real life journeys and not the hypothetical future scenarios. These scenarios when implemented and tested feed back to the journey and underlying layers changing them as the new functionality is introduced.
The end to end cycle of experience driven development
Those familiar with the concept of enterprise architecture will notice some familiar notes here. Let us explore them further
Enterprise architecture through the lens of experience
According to the BABOK(r) Guide, an enterprise architecture is “A description of the business processes, information technology, people, operations, information, and projects of an enterprise and the relationships between them.” [1] An organization’s enterprise architecture generally describes how the business operates as a whole and defines the solution environment requirements. It also helps specify exactly which platform or other attribute of the environment is required for a particular solution.
The key challenge when defining an architecture of this scale is how to scope it. A project to build the architecture from scratch can last for months if not years in a large enterprise. Moreover, once built the architecture becomes obsolete really fast without proper updates and maintenance, which can cost a lot.
So businesses need to find a way to make this effort focused and to achieve a measurable ROI on these activities. Tailoring architecture slices to customer journeys is a way of achieving it.
Make architecture focused
The above mentioned process of end-to-end requirements development implies building an enterprise architecture blueprint in order to identify the requirements correctly. However, the nature of the process makes the blueprint focused exclusively on elements that are directly related to a single customer journey.
When performing market analysis and defining the journeys, an important step is to prioritize things accordingly. First step of prioritization is to define the customer personas or segments, that are of value or interest for the business. These may be the key target audience for the product or service, or they may be the most challenging segments (e.g. people likely to churn), so a business initiative can be focused on smoothing the experience for these people and reducing the likelihood of unwanted events.
When the key personas or customer segments are defined, the journeys can be prioritized next. The same user can have multiple potential journeys that interact with the business. They can come from a targeted acquisition campaign or discover the service organically. They may have a positive or negative previous experience with this type of services, etc.. Just like it is important to prioritize the customer types, it is important to prioritize the journeys for those customers.
Once those decisions are made, it is clear which customer journey the business is working with. This is when an enterprise architecture bit can be added into the picture. From the touch-points on the customer journey, an analyst can identify which internal processes, people and systems support them. In addition to these, the analyst can identify all the projects and initiatives that happen in the business in parallel, which may affect the journey. All of these data together forms a view of the enterprise architecture, focused around a specific prioritized journey. As the journey is considered to be of priority for the business, the elements identified during this exercise automatically become a priority. This is how a defined customer journey maps help build a focused slice of the architecture and help prioritize architectural effort.
Such architecture slices are often referred to as “service blueprints”.[2]
A great summary of what a service blueprint does is given by the Nielsen Norman Group: “Service blueprints are companions to customer-journey maps: they help organizations see the big picture of how a service is implemented by the company and used by the customers. They pinpoint dependencies between employee-facing and customer-facing processes in the same visualization and are instrumental in identifying pain points, optimizing complex interactions, and ultimately saving money for the organization and improving the experience for its customers.” [3]
Quantify ROI on architecture
It is always hard to calculate the return on investment when it comes to enterprise architecture work. Making the architecture customer centric simplifies this process.
Service blueprints help discover weaknesses in the businesses. Behind any unhappy customer there is a broken business process - the blueprint will help identify which processes lead to undesired results. It will also help to scope initiatives to improve those elements of the architecture that underperform. At the same time, as the elements are tied to experiences, it is easy to allocate business KPIs to them.
For example, let us imagine the data analysis shows our customers often abandon online checkout process at payment stage. The abandon rate is 75% on this stage. From the user interviews we have learnt that the payment form looks and feels external to the website, so people perceive it to be a scam. Building a service blueprint we identify the systems involved in the process. We may find out that the reason we cannot customize the payment screen is that it is a third party payment portal, so we don’t have much control over it. Even though it cannot be customized visually, there might be a reason why this solution was selected. E.g. it may integrate nicely with downstream systems as a part of the business process. To resolve the problem, we may decide to change the process so the integration is not so important, or replace the payment system with another tool that satisfies both needs, or decide to bring this functionality in house. Introducing changes to this architecture will result in direct change in customer’s behavior, bringing the abandon rate down. This change in customer behavior can be directly attributed to a new architecture decision, which can form a part of ROI calculations for architecture.
A similar process works with new opportunities that are identified on the customer journey. An opportunity needs a measurement or set of measurements to be assigned, so that the business can make a decision whether an initiative was successful. These KPIs will bring commercial flavor to architecture activities, as it will make it clear why an enterprise architecture is being considered and which outcomes it is aimed to achieve.
It is important a business (or customer’s) KPIs are allocated to elements of your blueprint. This helps build a better system of internal metrics that measure the quality of the architecture, as those can be derived from the customers’ level. This traceability helps keep the decisions focused on the valuable outcomes, and also supports the decision making process with real data rather than employees' opinions. As we have discussed in the previous article, decisions based on real evidence help solve real problems and avoid building products that no one dreams about!
How do we build a service blueprint?
In a nutshell, building a service blueprint consists of the following steps:
- Identify the customers
- Examine the customers’ perspective of the service (customer journey)
- Identify the internal participants of the service (employees, technology and other actors supporting the journey)
- Link related activities and elements together
- Define and measure business KPIs for customer journey steps
- Translate those KPIs into internal metrics and make data driven decisions
Follow these steps, and you will elevate your enterprise architecture practice to a new level.
Links:
- A Guide To The Business Analysis Body Of Knowledge ®, Version 3, International Institute of Business Analysis, 2015
- https://www.interaction-design.org/literature/article/service-blueprints-communicating-the-design-of-services
- https://www.nngroup.com/articles/service-blueprints-definition/
Author: Igor Arkhipov, Business Analysis Practice Manager
Igor holds Master of Business Informatics degree specializing in Business Process Modeling and Optimisation. Igor has broad experience as a Business Analyst and a BA Team Manager in the fields of software development, e-commerce and quality management. Igor’s current role is a BA practice manager at Isobar Australia.