How not to share information across service boundaries in SOA?

Question

We are often told to avoid sharing business data across service boundaries. However, I tend to see the need for a service to access data from a different service.

An example of this would be IT functions needing to access employee position and corporate structure (i.e. the managerial ladder) - this information is typically maintained by HR. Specifically if there is an IT policy that only directors and above are eligible to request certain IT devices if they do not have ones already from the company. In order to enforce this rule, the IT service will need to access HR data as part of its business logic to accept/reject such requests.

The SOA guideline is also not to couple services via request-response communication purely to ask for data.

If data sharing is discouraged across service boundaries, how could other services enforce their dependent business rules on data from another service? For example the request of an IT device cannot be initiated from the HR service.

What is your advice?

Answer 1

We are often told to avoid sharing business data across service boundaries

I don't know who told you this, but is sounds to me like misinterpreting a strategic recommendation how to draw service boundaries (ideally in a way which reduces the need of sharing lots of business data) as some dogma about not sharing any business data.

IMHO this makes not much sense.

When two services both need the same data, then they need to share them - fullstop. Of course, it helps to organize and scale a system by having each piece of data only stored and/or maintained in one place (service), and provide other services only copies of the data they need. Using your example, an HR service maintains and manages employee data, and an IT service just gets a copy of it.

Answer 2

I suspect the real advice is: don't try to draw service boundaries across data flows (and not "avoid sharing business data across service boundaries").

In other words, you start by determining the necessary data flows to support the functionality you want, and you can then draw service boundaries in the gaps (if any).

You don't start by drawing the service boundaries (on what criteria, arbitrarily?), then wondering how on earth you do or don't get data to flow across them.

Implicitly, it seems the very definition of a "service boundary" is a relationship between two services where there is a de facto absence of data flow.

If there is a data flow in one direction, then the sending service can be considered distinct, but the receiving service is now composed of the sending service. The receiving service is treated as having no boundary against the sending service (or existence independent of it), although the sending service continued to have a boundary against the receiving service.

Implicitly now, a "service boundary" is not just a relationship between each and every pair of services, but it's a relationship that has a different nature depending on which side of the relationship it is viewed from (and which way data flows).

If there is a data flow in both directions between supposedly two separate services, then there cannot be a service boundary, and you are in fact dealing with the internals of a single service.

I don't know whether this complicated scheme of services, with their containment and relationships, is useful in general.

With just 4 services in this conceptual model, you have 12 bilateral pairings and thus 24 boundary statuses to keep track of.

I suspect in most businesses, no data is sufficiently isolated that more than one "service" can exist (and such "services" as are claimed to exist, are just fancy ways of describing the parts of one business information system, whose real nature is monolithic and indivisible).

Answer 3

Maybe a perspective that is really important here is data ownership.

I would treat data read(reading data I can't change and don't own), and data write (making changes to the data I own) as two separate contexts.

As for data writing, only the data owner should be able to change it and apply any business rules to that data change. On that aspect, it must be aligned to "Service" boundaries and no other "Service" may have access to change that piece of data.

However, when it comes to data reading, technically, any "Service" or a technical component can read data as long as they don't try to change it or treat it as its own data.

On a technical/implementation level, one might take many different approaches, from publish/subscribe to Provider Patterns to data warehousing and data lakes.

Hope this helps

Answer 4

Before the advent of microservices there was a strict separation between atomic services and orchestration services. These kind of issues (the access of to the HR data and the filtering out of unnecessary data) would be addressed in an orchestration layer and the IT functions at an atomic level would receive in input all the data they need and only the data they need.

Answer 5

Accessing HR data is a wrong approach. Instead, there should be a system that manages authorization (permissions). Employees should get permissions in this system. When a new employee is being onboarded, administrators should be instructed by HR department to give this employee corresponding permissions. If employee role from the HR view changes (new role assigned), again the HR department should instruct the admins to assign corresponding permissions.

Thus the authorization service should have no connection to the HR data.

Applications should only use authorization service.

Thus, no application needs any access to HR data.