Semprini

Lies, damn lies and statistics

Data Autonomy - BI & Analytics

BI & analytics loves Data Autonomy and event driven architecture. In the operational side of Semantic Hub / Data Mesh, data is already clean and in business form. Data engineering can subscribe to all significant business object changes and metrics can be automatically calculated live. Dimensional modelling also becomes a much simpler process as canonical data is available near real time.

The data engineering and integration teams can become an active part of data governance and data stewardship. Working closely with the business domain SMEs, everyone is on the same page and reporting is simplified.

Data Autonomy - Holistic Data Mesh

Standard event driven integration practice is to take data from a system, transform into a middle model and then transform to each destination. Data Autonomy simply says that while we have the data in the middle form, lets save it.

Each business domain must be free to evolve and mature independently as the view of significant business objects evolves. The data governance group with data stewards and SMEs should be responsible for producing domain aligned data product definitions which are then realized into data products. The features of these data products should cover interfaces and persistence for both operational and analytical data.

Python decorators and testing interplay

A trick for new players, when using decorators to register functions - E.g. a plug-in system.

Since unit testing automatically imports modules when looking for tests, you must remember to import modules using the decorator. If you don't your tests can pass but execution fails.

Also linters don't like importing without directly using as the act of importing the module registers the function but they are still technically 'unused'

Enterprise Microservices

If you have a "microservice" which exposes an API calling a back end system, you don't have a microservice - you have an API. Your API has wisely used some of the concepts of microservice architecture. Microservice architecture is not an integration architecture, it's an application architecture and applications are responsible for business logic. This distinction is important because the beauty of microservice architecture is both technical and behavioural.

However, I'll extend an olive branch to the API people, no doubt aghast by my blasphemy, by calling them "integration microservices".

Integration microservices are fine I guess, but too often they are used, just as integration is often used, to sweep the legacy monster under the carpet so we don't have to see it - out of sight, out of mind. We implement integration microservices containerised, auto-scaling, auto-healing etc, IT management has an orgasm, we all add something to our CVs and the legacy monster waits.