Johannesburg, 11 Jul 2018
A number of large organisations are exploring ways to understand and realise the value of Web APIs and micro-service architecture. Organisations struggle consistently with determining how to define optimal boundaries between their micro-services.
This is a known problem in the industry that has unfortunately not been adequately addressed. Much has been written about the value of cohesive services and the power of bounded contexts, yet there appears to be a void in guidance on how to identify these aspects practically, says Michael Brink, CA Southern Africa solution strategist.
One reason for this is that the people trying to determine service boundaries are usually technologists who inherently tend to look for a technological solution. However, domain expertise is required when defining cohesive, capability-aligned service boundaries. Fundamentally, this should be a modelling exercise that is independent of whatever technology is implemented under the covers. Even organisations that have consciously taken a technology-agnostic modelling approach have struggled with the process of defining service boundaries.
This has happened, in part, because the most popular software modelling methodologies often have implementation bias. For example, domain-driven design (DDD) has a bent towards object-oriented programming and UML has a data modelling perspective. Additionally, there is no industry consensus on how a micro-service system model should be depicted visually, what components should be shown, how relationships should be represented, what terminology should be used, let alone any tooling in the space.
Still, all hope is not lost. Some DDD concepts, most notably the idea of "bounded contexts", have gained popularity and started an industry conversation on service boundary definition. Importantly, the higher-level abstractions in the DDD methodology, such as domains, sub-domains, bounded contexts, aggregates, and context maps, are technology-agnostic and model-centric.
Since the accepted approach to understanding a system is to focus on the relationship between the system and its components, we need not go deeper than the context map if we want a basic representation of a micro-service system. So, perhaps we can use the DDD context map as a starting point for visually representing a system of micro-services.
Even at the context-mapping level, a large organisation's complete system of services would be incomprehensible. So, in order to make the context map useful, it is important to have a framework for the context map itself. This could be the decomposition of a particular monolithic application or the service interactions of a particular initiative. The only way to coherently build a large organisation's system of micro-services is to do so piece by piece, context by context. Along the way, these contexts can be combined to project the complete picture, if such a picture is even needed.
Banking
Consider a large retail bank that is looking to introduce customer-centric services in order to meet its strategic goals for customer retention. It would like to offer a new customer-centric payment solution that will allow clients to make purchases based on their total relationship with the bank, their accounts, investments, assets, and interaction patterns, rather than basing the authorisation decision on the balance of one specific account.
Retail banking is an inherently complex business domain. There are interrelationships between entities like customers, products and servicing channels (branches, online banking, point of sale), as well as mandatory regulations related to financial transparency and data privacy. Therefore, although the idea behind this new payments service is intuitive, it presents a complex problem space.
Where do you start?
Following the DDD approach loosely, we can start by breaking the retail banking domain down into sub-domains. As a starting point, and following the inevitability of Conway's Law*, we can start with the organisational units that make up retail banking and are relevant to the customer-centric payments solution.
These include:
Self-service banking: Applications that support self-service banking channels (such as mobile, Web, ATM and point of sale) will be needed to both set up and execute customer-centric payments.
Customer and card management: Applications for customer information, customer authentication, and card-based authorisations are most closely aligned with the new payments service.
Deposit accounts: Systems of record and origination for deposit accounts (checking, savings) house information needed to authorise and fulfil customer-centric payments.
Retail lending and credit: Systems of record and origination for lending products (eg, personal line of credit) and credit cards also house information needed to authorise and fulfil customer-centric payments.
Mortgages: Systems of record and origination for mortgages include information that can help the customer-centric payments solution make authorisation decisions.
Investment banking: Although not part of retail banking, customers' investments with the bank will be considered in the future for the customer-centric payments solution.
This gives us a starting point to think about how to classify the services needed to create the customer-centric payments solution. The self-service banking and customer and card management sub-domains are highlighted, since they have already been identified as the key sub-domains for the solution. Using the DDD notion of "linguistic boundaries", there are clearly some bounded contexts that emerge from the sub-domains.
So let's explore the contexts that emerge from the sub-domains.
Within self-service banking there are two distinct bounded contexts that come into play. The Web banking channel shares a common language with the mobile banking channel, since they both offer a high-touch customer experience and the applications supporting the mobile channel were built by and share components with the Web channel. Let's call this context "online banking". Point of sale, on the other hand, has a distinct language which is centred more on device management and merchant relationships. We will call this "point of sale".
Customer and card management is even more divided. Core customer information, including the authoritative list of the bank's customers, their contact information and their product holdings, forms one distinct vocabulary, which we will call the "customer information bounded" context. Another distinct language is used to describe card functions, which are primarily tied to payments activity. This is the "consumer payments and transactions" context. Lastly, there is a "customer identity" context focused exclusively on customer security and access control.
The product sub-domains are not as critical to this payments solution, but it is notable that the retail lending and credit sub-domain breaks down into separate PLC accounts and credit card contexts.
Having established the bounded contexts, we can now think about what services and service consumers will make sense within them. As mentioned earlier, online banking has two service consumers: the online banking Web app and the mobile banking app. The new payment solution will also be consumed by message requests received through POS networks from the point of sale context.
The customer identity context must provide a customer authentication service in order to ensure only appropriate requesters are able to access the new payments service. The customer information context contains the cross-reference between customer and product holdings, so it follows that a core customer information service is needed to supply this data for the new payments solution.
In addition to this, tracking customer fiscal activity, the financial events related to their product holdings, will be useful in making authorisation decisions. Therefore, a customer activity analysis service can be created within the customer information context.
The consumer payments and transactions context is where the core services will be built for the new customer-centric payments solution. To start, customers need a way of signing up for the new offering and setting their account and product preferences. For this purpose, a customer-centric payments management service is introduced.
For non-functional reasons, such as performance, security and availability, we will create a separate service for authorising payments, called the Customer-Centric Payments Authorisation Service. Lastly, since the posting of transactions to customer accounts can be posted later than the authorisation decision, we will create a transaction posting service that is decoupled from the authorisation service.
For the product sub-domains, we will only refer to a single eponymous service per bounded context. For example, the deposit accounts context simply contains a single deposit account service.
The last step in this design process is to annotate the interactions that will take place between services. In fact, one might want to model the interactions between bounded contexts in order to tease out the individual services, but, for the sake of overlaying the visuals, we will depict this step last. Illustrating all possible interactions at this stage would be visually confusing, so we will only focus on some key ones that will help us to understand how the system will function. Here are some examples:
* A customer uses the online banking Web app to sign up and set his/her preferences for the new payments solution through the customer-centric payments management service.
* The customer-centric payments management service retrieves the customer's product portfolio from the customer information service.
* The customer activity analysis service builds a customer financial profile using information from the product systems.
* The customer executes a customer-centric payment through the mobile banking app, which calls the customer-centric payments authorisation service.
* The customer-centric payments authorisation service in turn builds an authorisation profile using information from the customer-centric payments management service and the customer activity analysis service.
* Once authorised, the payment is forwarded to the transaction posting service for completion, which then calls the appropriate product service.
There are a few important points to note about this system of micro-services. First of all, do not assume that each of these interactions will take place in real-time when servicing the end-user activity. For example, although the customer-centric authorisation service needs information from a few other services, an event-based approach combined with caching could be used to ensure its processing is self-contained in order to service the customer's authorisation request in real-time.
Secondly, an anti-corruption layer (ACL) can be established between bounded contexts in order to provide loose semantic coupling. Finally, you'll note that, although this is a fairly complex picture, there are no implementation details. In other words, this model could be implemented using many different technologies, including languages, hosting environments and network protocols.
Ultimately, the intent of this system design process is to help take a best guess on how to define service boundaries for micro-services within a complex solution. Hopefully, the approach described here will both establish a good initial model for the services as well as making it easier to redraw the service boundaries down the road.
* Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that "organisations which design systems... are constrained to produce designs which are copies of the communication structures of these organisations".
Biography: Michael Brink, Solution Strategist, CA Southern Africa
Michael Brink is a Solution Strategist at CA Southern Africa. Brink is a 20-year veteran of the technology industry, with a proven track record of success in delivering transformative technology to the marketplace. He started his career as technical leader, principle consultant and architect at various financial institutions and ICT service providers before joining CA in 2012 as solution and enterprise architect.
As advisor of solution strategy for continuous delivery, Brink is responsible for driving the value of the CA Continuous Delivery portfolio across the local market and to ensure the delivery strategy for CA Southern Africa is aligned to solutions that help customers increase their business agility, unlock digital growth opportunities and fast-track their digital transformation journey. E-mail: Michael.Brink@CAafrica.co.za
Share