The granularity of Abstraction

What is that and why 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. Namely the level of component granularity.

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

In order not to be too abstract, in the following example, we will use an online Phone Book as a Use Case.

What is a large and what is a small abstraction?

Basically, there is no right answer to this question. Let me try.

The smallest possible abstraction is the one computing  entity which does one thing. And has one method on its single 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, answer me what is the opposite then? The opposite of “doing one thing” might be a component that given UID returns everything available for that person. In that scenario, all the phone numbers, addresses, notes, and such, are associated with than one person. That is certainly more than a single piece of data.

Detour: of course, UID (Unique ID) is the one abstraction utilized above. Well-defined single and simple meaning.

Detour: a single piece of data is materialized in this century, as one key/value pair. For example:

Great. Let’s do this  “one thing” then: architect the system which compares the approach of many components, each with an interface that does one thing with the opposite end of the spectrum: one method.

The many-components approach is also what will give us the greatest possible number of components for a given system to be developed, deployed, fed, and watered.  And each Cloud component is a piece of server-side software. Thus it also has to be implemented, maintained, debugged, etc.

Here is one “sketch” antagonizing these two opposites: on the left is each thing as one component vs one component one API returning many data things about one person in one call, on the right side (note: components with public APIs might be separate server-side processes these days fashionably named “microservices”):

On the left are four arbitrary separate modules as an interface to the proverbial “Phone Book” abstraction, on the right, is the opposite concept: 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 your front end (aka the “browser”). On the right: not a lot of them but very few large(r) data sets flying from the cloud toward your browser. So. Which one do you prefer?

Do you prefer the “Right-hand side” option? Ok. You represent an opposing school of thought: you want to minimize the number of data provider components. I guess you do not want to create maintenance effort draining your DevOps resources.

But now you take a pause to think. The “Left” option is very tempting because it is flexible. Simply you do not get the data you do not need. You want just a person’s name, and there is a separate component delivering only the person’s name and nothing else but a person’s name. And you do not provoke a lot of large data sets with all the data about one person in one data set, flying around. Good. Allow me to pull you back into reality now.

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

Yes, it is linear. Instead of one (1) component, you might have N of components. With costs multiplied by: teams, deployments, tests, debugging, high visibility maintenance events, and such. And that raises the overall Cost of the product.

I am not advocating one or the other philosophy.  Just dragging you in front of the actual and real picture.

Conclusion

And there you have it: this is the granularity of abstraction explained. Journalists might say: “Truth uncovered”.

Smaller granularity is a more complex interface on fewer components, larger granularity is a simpler interface on each of much more components. One component with one API is the extreme end point in that direction.


1: Where N is a large number