The granularity of Abstraction

What is that and why would I write a blog post about it?

Perhaps because I am convinced after N years1 of architecting all sorts of IT systems this is one of the key feasibility indicators of a well-architected IT system.

What is the abstraction in the context of the real IT system? An online web back end for example. Nothing else but a good old, web service. The best example is REST endpoint URI, representing a “resource” which is in turn implemented as a web service.

In the following examples, we will use an online Phone Book as a Use Case.

What is large and what is a small abstraction?

The smallest possible abstraction is the one which does one thing. And has one method on its interface to do that one thing.

Example: for a given UID return the name of the person. A single piece of data. For understanding it better, what is the opposite then? The opposite of “doing one thing” might be a component that gives UID returns everything available for that person. In this scenario, all the phone numbers, all the addresses, all the notes and such. That is certainly more than a single piece of data.

Detour: a single piece of data is one key/value pair. For example:

Great. Let’s do this then “one thing” thing: architect the system which has every component with an interface that does one thing with one method.  Obviously, this is what will give us the greatest flexibility, after all. But.

This is also what will give us the greatest possible number of components for a given system. And each component is a piece of server-side software. It has to be implemented, maintained, debugged, etc.

On the left are four arbitrary components as an interface to the proverbial “Phone Book” , on the right is the opposite concept architecture: a single component with a single method, to get the whole data about a single person in one go.

Left: a lot of little data pieces flying from the cloud to you. Right: not a lot but large(r) data sets flying from the cloud towards you. Which one you prefer?

You prefer the “Right” option. Ok. So we have an opposing force: we want to minimize the number of components. We do not want to create maintenance effort draining our resources.

But, The “Left” option is very tempting because it is flexible. You do not get the data you do not need. And you do not provoke a lof or larger data sets flying around.

In the real world of markets, profits and all those mundane things you do not like to think about (because you are a developer) there is this thing called: Cost.

Yes, it is linear. Instead of 1 you might have N of everything: teams, deployments, tests, debugging, maintenance events and such. And that raises the overall Cost.

I am not advocating one or the other.  Just dragging the cost into the picture.


And there you have it: this is the granularity of abstraction, As journalist would say: “Truth uncovered”.

Smaller granularity is a simpler interface on fewer components, larger granularity is the more complex interface on few or just one component. Just like granules of some IT cereals. The smaller they are the more you need, the larger they are the less will satisfy your breakfast requirements.

1: Where N is a large number

%d bloggers like this: