The recent introduction of PSD2 (Revised Payment Service Directive) has banks navigating the unchartered territories of open banking. A PWC report predicts 71 percent of SMEs and 64 percent of adults will adopt open banking by 2022. The open API economy fosters the development and delivery of products and services through collaboration with third-party entities.
To stay ahead of their competition, banks are adopting the open API model to re-architecture existing applications along their IT transformation journey. The beauty of microservice architecture lies in the freedom of decision making in quickly deploying independent service entities. Some banks such as Fidor and Atom & Starling, are adopting an API-first approach to product development. Their Banking as a Platform (BaaP) redefined traditional banking by leveraging APIs and microservice architecture. The API-first paradigm requires the adoption of technology-agnostic design practice. The approach does not rely on any programming language, technology platforms (SOAP, CRUD, REST etc.) or libraries.
At this juncture, adopting a design thinking approach is helpful to identify and create interactive systems focusing on the users, their needs, and their requirements. Implementing a design thinking approach to microservices architecture is where human-centered design meets development. Consumers are able to interact with baking applications in early stages providing valuable feedback for product development.
The concept of design thinking is relatively new to the banking sector; its implementation brings in new business and cultural challenges that the industry is not used to. Some organizations develop their own microservice design canvas to guide service development. The canvas serves as a tool to help capture critical attributes of a service before the development phase. Taking an outside-in approach, the schema consolidates key insights on consumer tasks, interface requirements, non-functional qualities (security, availability, reliability, scalability etc.), processing logic, data elements, and external service dependencies into its design.
Some banks, like Capital One, have adopted the open banking systems, launching a developer portal (DevExchange) and three open APIs – SwiftID, Rewards, and Credit Offers. SwiftID operates as an easy to integrate two-factor authentication security system, whereas the other API services provide information pertaining to rewards and credit card offers. The idea behind creating the commercial banking platform was to create a tool for next-generation CFOs to simultaneously access, modify and analyze information across channels. Using the microservice design canvas, Capital One was able to align its goals and assimilate design thinking early into their development strategy. The tool helped in dealing with the complexity of distributed software and understanding the evolving microservice boundaries.
But moving from a monolith service to the discrete systems of microservice architecture is not easy. We explore the prominent challenges of design thinking in microservice architecture.
Breaking down the monolith
Banks have been maintaining and operating monolith applications or legacy systems for a long time. Bringing in the microservices architecture is a challenge as it requires an investment of time, money, and a shift in mindset. Compared to the monolith architecture, a microservice architecture breaks down large software projects into inter-communicating modular units through APIs.
Decomposition of a monolithic application can be complex. The first question being on which service should get broken down to an individual service unit. One approach would be to partition the service requirements along business functionality lines. For example, if you have an investment lookup function with multiple calls from other functions, it’s a starting point for breaking it out into its own service.
Thinking like an engineer
Most developers begin building services from an inside-out approach; designing the data layers first and leaving the API design for the end. This approach takes into account the business logic and services it offers but does not look into a user’s needs. The engineering-thinking approach follows a set path of logic for design. Whereas, the design thinking process is a systematic approach to enable creative thinking and solution development. It involves the interaction of diverse personalities and talents towards creating the best solution for the user.
The design thinking process highlights the central role of users/customers and how new products can solve their needs. Using an outside-in design involves real users from the beginning of development to testing various scenarios.
Poor definition of the problem statement
A key part of the design thinking process is defining a clear and focused problem statement. Your problem definition paves the way for ideating and designing APIs. Once an API is released, customers and business units are dependent on its functionality. Changing API functioning after its release cannot be done without disrupting systems. Developers, on the other hand, get stuck in the integration and testing loop, giving them little time to develop new applications.
Due to this, the first parameter of a microservice architecture is to define its functionality – ‘what it should do’, ‘how should the services be split’ etc. Organizations have to decide which microservice approach works for them and supplement it with the correct infrastructure. Some organizations prefer a monolithic core model whereas others prefer a fully-service oriented approach.
Testing in a microservices environment
A business application is made up of multiple microservices interacting with each other. Apart from testing the overall application, developers are required to test each microservice separately. Additional layers of testing and API integrations creates a complex testing process; requiring more quality assurance (QA) engineers and extensive planning. The interdependencies of a microservice make it difficult to ensure full coverage of test cases, especially in lower environments. Indistinct behaviors are harder to predict, validate and monitor on a regular basis.
Organizations have to work on developing a comprehensive approach to their microservice testing environment. Unit tests and integration test take care of coding and integration points of a microservice architecture. They ensure that every piece of code, down to the lowest levels, and entire objects are tested before integrating with other parts of the application.
Conclusion
In the face of changing customer behavior, regulations, and technology, banks are on the lookout for models that will be the ‘Uber of Banking’ for their challenges. Microservices make this possible by their human-centric design API designs. The approach supports the architecture with an agile, scalable, and dynamic service mesh. In this atmosphere, design thinking is proving to be a useful tool to help banks recognize the needs of their users and other stakeholders. For banks willing to experiment with design thinking, partnering with external design support teams and microservice developers can be a start.
