An expression common to computer scientists is on the rise among cable technologists, and it's a doozy. Usually it crops up in conversations among 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 is in "lost in abstraction," or abstraction as in the removal of something. There's also 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.
Layered in stacks
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 sets of instruction 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 how to proceed with an activity for the next software module in the stack.
So a hardware abstraction layer marked "set-top hardware," in the case of the rectangle at the bottom, will summarize for the box above it, marked "operating system," how to proceed with a desired activity. And so on, up the stack.
If not for abstraction layers, software programs would exist as big blobs that aren't all that reuseable — 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-megahertz carrier, find me the program identifier for the MPEG-2 (Moving Picture Experts Group) 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 or 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.
People build them
Building abstraction layers is an art, computer scientists assure. 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. Theoretically, they 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.