Abstracting the Abstraction Layer

by Leslie Ellis // October 14 2002

An expression common to computer scientists is on the rise among cable technologists, and it’s a doozy. Usually it crops up in conversations amongst software engineers, about digital video hardware and software.

The expression: “Abstraction layer.”

Abstraction layers are everywhere in software. Industrially, an abstraction layer is something software architects build. Its intent is to take something complicated, with many possible outcomes, and to put something on top of it that yields a simple way of doing it, that works in lots of different places.

Clear as mud, right?

Let’s break it down further, starting with the word “abstraction.”

Outside of techno-interpretations, “abstraction” carries at least seven meanings (and that’s without consulting the Oxford English Dictionary). Many of its definitions seem only vaguely related to the next: There’s abstraction as in “lost in abstraction.” Or, abstraction as in a removal of something. And, abstraction as the inventive isolation of an object’s characteristics, like when sorting something into its genus or species.

The whole abstraction thing, then, is fairly cerebral, and it doesn’t get much better when hitched to “layer” and whisked into the lexicon of software engineering.

The general invisibility of software is why software people are experts at drawing piles of rectangles, when explaining the “hows” of their world. Most of this stuff is hard to envision without the rectangles, layered to make a stack.

A fairly typical depiction will show a rectangle marked “set-top hardware” at the bottom, “operating system” above it, “middleware” above that, and “applications” at the top.

The north-south intersections of those four rectangles are where the abstraction layers do their work. Abstraction layers essentially say “do it,” instead of listing long instruction sets about how to do it.

Abstraction layers bring with them their own set of prefixes: Hardware abstraction layer, software abstraction layer, database abstraction layer, network abstraction layer. In every sense, the intent is to simplify, for the next software module in the stack, how to proceed with an activity.

So a hardware abstraction layer, in the case of the rectangle at the bottom, marked “set-top hardware,” will summarize for the box above it, marked “operating system,” how to proceed with a desired activity. And so on, up the stack.

If there weren’t abstraction layers, software programs would exist as big blobs, not all that re-useable, and not at all happy or speedy about handling the inevitable changes that happen during the course of business. Without an abstraction layer, then, deployments of whatever the advanced digital video product may be – VOD, SVOD, you name it – would wind up as massive, custom integration projects.

Example: The navigational part of a VOD system, which in the stack of rectangles would sit at the top, as an “application,” just wants to tune a movie. So its abstraction layer says to the one below it, “fetch me the stream for “Waking Ned Divine, please.”

It doesn’t say, “tune the following 6 MHz carrier, find me the program identifier for the MPEG-2 stream related to “Waking Ned Divine,” isolate the index frames, begin filling the MPEG buffer, decompress the video, and get it on the screen, please.”

The kissing cousin to the abstraction layer is the “API,” or “application program interface.” APIs are the software tools used for the layers to talk to one another. People who work at the hardware level — engineering chips onto boards, and writing machine language code to make the chips do their work — need to know how to make all of that sensible to the next thing that needs it. In the case of the set-top box, the next thing that needs it is usually the operating system.

APIs, then, help the operating system know what’s below it. APIs at the middleware level, above the operating system, help applications developers know how to get to what’s below it, and so on.

Building abstraction layers, computer scientists assure, is an art. There are people whose entire lives are spent building abstractions. It’s not always perfect: Sometimes, getting to a high level of abstraction necessitates throwing away some good stuff, too.

Abstractions, as cerebral as they are, weren’t meant to be a confusion device developed by computer scientists to make the rest of us feel stupid. They were meant to simplify. They theoretically afford bigger portions of an R&D budget to go to the actual product, not to custom integration.

And, as cable executives up to the CEO level know all too well, anything that relieves the stacks of dollars going to custom integration is worth its weight in abstractions.

This column originally appeared in the Broadband Week section of Multichannel News.