March 18, 2003, 12:00 AM — Somebody, I think it was Adam Bosworth of BEA, once said that every
layer of abstraction costs you 50% of your audience. Or words to that
Let's do the math. You are presenting on the subject of a new business
IT architecture to an audience of 100 people. You start with people and
business processes at the bottom of your diagram. You add layers of
abstraction on top so that everything fits neatly into some nice three
letter acronym-emblazoned box at the top. Let's call the top level box
XYZ for the sake of argument. The XYZ acronym becomes a strategy
buzzword of the enterprise. All new systems have to be XYZ-enabled or
XYZ compliant. Board members start to talk about XYZ as a vision. A
group is established to care and feed XYZ and get the all important
mouse mats printed.
Let's say there are five layers of abstraction in the architecture. If
every layer costs you 50% of the initial audience of 100 people, by the
time you reach the last one, only four people in the room have one iota
of what you are talking about.
It's the same over in the IT department by the way, where the technical
underpinnings of the XYZ corporate vision are spelled out. The IT
architect takes the podium on front of an audience of 100 IT people. She
explains how the chosen J2EE patterns are implemented in terms of XML
interfaces conforming to the chosen e-commerce meta-model in which all
meta-data conforms to an ontology managed as a set of RDF triples.
By the time you hit the RDF triples (working from the top down), all but
four people in the room are tidying the hard disks of their laptops or
updating their blogs.
Sobering stuff. Abstraction extracts such a terrible price in return for
the benefits of complexity management it bestows on the chosen few.
Abstraction creates a high priest environment in which only a few can
ever hope to really understand the "vision" buried in all the
abstraction. In the hands of the chosen few, the abstractions are a
precision tool wielded to powerful effect. In the hands of the other
94%, the tool is more like a monkey wrench. A tool that can be used for
every job but is the *wrong* tool for every job.
I fear that RDF - the uber-abstraction that underlies the Semantic Web -
is one such monkey wrench. Given the undoubted benefits to all of us, if
Tim Berners Lee's vision of the Semantic Web becomes a reality, how
can we make the abstractions it depends on, usable by the 94% of the
world's system developers? The population for whom the abstractions are
a step too far for them to comfortably follow?
I think the answer lies in what I call semantic shadows. Let's say I am
working with XML and want to have customers and products in my data
model. I want to think in terms of plain vanilla customer tags and
product tags - stuff specific to my problem. I don't want to have to
think in a more abstract model than necessary to get my job done.