Separation of concerns
Best-of-breed – part 3
In this series (part 1 / part 2), I have been writing about the merits of best-of-breed, as the middle ground between monoliths and microservices. So far, the subject has been limited to just the scale of the software – how many functions should one unit handle. There is another facet to this, however: which functions should be collected together into one solution.
This problem is referred to as the separation of concerns. Or, more accurately, you should consider the separation of concerns when you face the problem of dividing up all of your requirements into units of software.
If you are not familiar with the term, separation of concerns is the process of extracting functionality relating to different domains into isolated units – as a programmer that could be different modules, functions or classes; as an architect that would be different components of the whole system.
To illustrate this concept and explore why you might want to separate concerns, let’s go through an example. Consider a website that requires you to log in to access its content. This system has at least two concerns: managing content and managing users. Now, if this website has a single database to store all data then it has potentially mixed concerns. How could this manifest as a problem? Well, what if the Asian and European markets are both very important for this site and performance is critical? In that case, the GDPR mandates that the users are stored within the EU but the latency of database calls from Asia to the EU could be a problem. The crux of the issue is that there are conflicting requirements upon the database. One concern (user management) requires that the data is never stored outside of the EU and another concern (content management) requires that the data is replicated between Europe and Asia. Obviously this is an over-simplification but hopefully it illustrates the point.
In that example, the resolution to the conflict is straightforward: use two databases – one for users and one for content. That change exemplifies a separation of concerns in a very literal way. Of course, that could cascade into the application tier or the architecture. For the latter, that would mean having one standalone solution for content management and a separate piece of software for user management.
So, given you have taken the decision to use best-of-breed solutions – not monoliths – the question of where to draw the boundaries between these solutions is forthcoming. To answer that question you need to contrast two factors:
- the benefits of proximity, control and intimate knowledge; vs
- the risk of conflicts arising between two functions in the same black-box
To illustrate the benefits of proximity, consider Identity and Access Management (IAM). These two families of functions are very commonly bundled together because the decision about access is intrinsically based upon the subject’s identity (“you can access this but they can not”). An access management tool can exist independently with an integration to an external identity store but then the management may be more convoluted, latency will slow the system down and, if the integration fails, the whole system will cease to function.
From an architect’s standpoint, the task is not just to cluster functionality into concerns but also focused on identifying functions that should not live together, because of the risks that coupling them expose your organization to. Unfortunately, analysing the risk of a conflict arising is akin to predicting the future. There are a few indicators you can consider, however… Is the function (not system) mission critical? Is the function heavily regulated, therefor subject to unpredicted change? Is the function intrinsically linked to external systems? Is the function intrinsically linked to client-side technologies, browsers, devices? Essentially, will one function need to moved and/or be changed (with some degree of urgency) independently to the rest of the system?
Finally, the vendors you are assessing will clearly have opinions about the correct separations of concerns and should be able to articulate them clearly.
For a true best-of-breed system the same vendors will regularly work with each other in a mutually beneficial and dependent ecosystem. The hallmark of best-of-breed is that the solution sells by word of mouth. That network effect will naturally cause the best software and, crucially, the most sensible integrations to bubble to the top: “We really liked X and it worked great with Y but, to be honest, the integration with Z was a mistake”.
Really, that final point – the Darwinian emergence of a best-of-breed ecosystem – is the crux of this series. It may be a challenging and multifaceted problem to architect a complex solution but a combination of foresight and market-wisdom can be used to mitigate the risks you take on.
In conclusion, the size and situation of your business affect whether you should be using smaller or larger solutions; monoliths are almost never beneficial; and, finally, careful planning – not just for the architectural patterns but also of where the split lies between various concerns in the system – will help you identify best-of-breed solutions that are a good match to your needs.