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 give UID returns everything availalbe for that person. In this scenaio, all the phoen numbers, all lthe addresses, all the notes and such. That is certainly more that a single piece of data.

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

// single piece of data
{ "key" : "8db07cfa-3b27-4953-9013-1d0eb6295ea4",
"value" : "Mr Data the Commander" }

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 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 flyng form the cloud to you. Right: not a lot but large(r) data sets flying from the cloud toward you. Which one you preffer?

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 arround.

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, debuggings, maintenance events and such. And that riases the overal Cost.

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

Conclusion

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

Smaller granularity is a simpler interface on less components, larger granularity is 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.