I can visualise my new digitised customer journey but how do I develop a solution?

Once a new customer experience has been designed, tested, and refined, the next step is to develop the technology infrastructure to support it. To prevent unnecessary complexity, the new build should be as architecturally flexible as possible - incorporating reusable components and services or deploying the same functionality across multiple channels—while taking care not to jeopardise the performance of existing systems. 

Integrating new processes with legacy systems in a cost-efficient way is a challenge most companies face when they digitise their customer journeys. One bank adopted a systematic approach that involved first asking whether a new interface was really needed and then determining the most efficient integration approach. It found it could make trade-offs in design - such as reducing data requirements to enable existing interfaces to be used - that would cut costs and improve the speed of delivery. Where new interfaces were required, the bank used a range of techniques from screen-scraping and robotics to agile building methods. 

Many banks’ IT development is overseen by architecture and infrastructure review boards that require extensive documentation and long lead times. Moreover, standards for deployment often call for multiple testing groups and management bodies to sign off on code. These processes were originally designed to protect banks against rework, security issues, and systems failures at a time when releases were infrequent. Paradoxically, such safeguards can now have the opposite effect, increasing the time it takes to fix problems when things go wrong. For agile delivery, banks need to move toward fully automated testing and deployment, using DevOps tools to allow for frequent smaller releases. Properly implemented, this approach should mitigate risk. 

At another bank, IT projects routinely took four to six months to go from concept to development, and three to four months to go from development to production. To speed up delivery, the CTO embedded an enterprise architect in the lab on a full-time basis. Not only did this reduce the four-month concept-to-development phase to four weeks, it also improved the quality of the results, delivering a customer-onboarding workflow based on service-oriented architecture and with multiple reused and reusable components. For instance, when the team proposed developing a new service to bring customer details from source systems to the website, the enterprise architect suggested reusing a similar service that was already bringing customer data to tellers. Time was also saved from the development-to-production phase by conducting quality assurance and user-acceptance testing during program-development cycles, or sprints, rather than after development. In another innovation, the team used an automated deployment tool to eliminate the need to align release dates across multiple changes. This made the bank nimbler at IT development and helped it move closer to continuous deployment, where code is deployed in production as soon as it has been tested and approved by the business owner. 

© McKinsey and Company