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
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
- 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.
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
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?
The post Belief #7 Best architectures keep together what is common and separate what is not appeared first on Architecture Therapy.