Have you ever wondered, what the grand old principle of separating concerns really means? There are many concerns! Yet in our mind separating concerns is imperative for creating simple and flexible architectures.
Let’s have a look at the following example:
Someone in my organisation suggest that we solve our data sourcing problems by having all data needed by our business domain into a big data base (or Operational Data Store, Data Hub, Operational Data Lake etc.). Then our applications wouldn’t need to source the same data twice, and we can optimise the data for our usage. While we are at it, why don’t we also put our own data into a big database. Then our consumers can go get what they need. It’s intriguing, right? We have technologies to handle this kind of architectures, so what’s wrong with it? In our view the architecture is based on the wrong concerns.
What concerns is this “big database” architecture based on? Perhaps data availability and data accessibility and certainly an attempt to not do the same sourcing again and again. These may very well be, what we want to optimize the architecture towards. But how do we deal with data ownership, data quality, data integrity and flexibility for change? Having all data together can give easy accessibility but not be flexible for change. In fact, we often optimize one aspect at the expense of another. So where should we look first?
We believe that the best architectures use business purpose as the primary concerns for separation. This means that you focus on finding business functionality solving single business purposes, before you consider other concerns. More specifically best architectures define atomic and non-overlapping elements of business as well as their relationships and orchestrations.
This tenet is very closely related to the much discussed “how big is a service” in the service-oriented architecture approach and for microservices. So in our view a “micro service” is primarily sized according to fulfilling one single business purpose and not according to how many lines of code, if it fits in our head, if it is covered by the same project or could go into the same technical platform etc. The thinking here is also along the same lines as strategic Domain Driven Design and Snowman architecture.
In fact we believe there is an order in which we should consider different types of concerns.
- Firstly, we seek to optimise our architecture according to unique and non-overlapping Business Purposes. Thus, solving each business problem only once and allowing for separate funding, separate priority, clear business ownership and release lifecycle. This enables flexibility for reuse and changes in business models.
- Secondly, we optimise our architecture according to use of Common Purposes. Thus, avoiding to re-invent (and re-implement) all the common functionalities, e.g. document generation, archiving, signing, authentication and authorisation, these are split out to lower and more generic parts of the architecture.
- Thirdly, we optimise our use of Infrastructure and Technology. Thus, being cost-effective by investing in the minimum set of future proof technologies that perform, scale, and are flexible to meet our needs, and ensuring the competencies needed to operate the solutions.
Let’s now consider our example of one big “data-base to solve all needs”. This would be a typical example of starting by optimizing our architecture from the Infrastructure and Technology perspective. In our experience such solutions often lack a clear business ownership and new features are placed there without proper governance. As a result, documentation deteriorates and eventually it becomes unclear who is using data and for what leading to security and compliance issues. Also, data quality issues are corrected in the solution and not at the source leading to inconsistencies when consolidating data across the enterprise. Finally, some of the consuming applications end up integrating to the source-systems anyway because they need not only to read data, but also to create or update data in other systems. So, what sounded like a brilliant idea often result in solution that tend to become very complex leading to long lead time for changes.
How do you then do it the right way? Well, welcome to a career-long education in understanding the business you serve! This is not a matter of mathematics, but one of learning what can successfully be common in your business and what need to be different. So, basically you need to understand the business, before you apply the technology.
Do you recognize any of this from your organization?