I spent today trying to explain what I
do to people who really do want to get it. I spent hours discussing
it, trying to make the esoteric world of design priorities, pattern
matching, data mining, and envisioning seem not only interesting but
effective and practical as well. Interesting I can handle; I love my
job. Effective and practical, though, that’s another story.
At first I spent a lot of time talking
about everyone’s favorite topics: the abilities. You’ve run into
them in trade magazines, bad books on IT management, and dark street
corners. Manageability, action-ability, supportability,
sustainability, reliability…the list seems endless. After mugging
a people a few times with them, though, I started to wonder if they
meant anything. Looking into my victims’ glazed eyes, I assumed not.
It’s an easy trap to fall into. We
toss those words around so casually sometimes, it’s sometimes hard to
remember they don’t mean anything. Perhaps I should rephrase,
slightly. The words still mean something in and of themselves. But
we’ve misused and abused them so much over the last few decades in IT
they have become almost meaningless buzz.
Take manageability, a watchword in IT
circles these days, as an example. Now, on one hand it means
something relatively specific when we get to talking about the
ability to access management functions in a variety of formats, apply
and control security models, and analyze data related to the
somethings behavior. On the other hand it’s been used so many times,
for so many things, that the idea of manageability earns a deep
belly-laugh whenever we bring it up in IT circles. How could it not?
Everything under the sun, including some nightmare inducing control
schemes, enhance enterprise manageability.
Availability isn’t much better. We’ve
all heard the story about how a user thinks the ATM is unavailable
when a deposit envelope isn’t available, even though every system
monitor says the ATM should happily accept a deposit. At the same
time, we all know from our own experience that our perception of
availability comes first and foremost from the system under our
charge. If we work on the network, we check it first. If we work
with servers, we check them first. If we work with applications,
business logic, databases….whatever we work on, that’s what our
vision focuses on.
So, I faced the challenge of explaining
these things without making people’s eyes glaze over. I haven’t made
it the whole way there yet, but I came to two realizations which
The first is that most of what we think
of as -abilities truly exist as processes not as states. A system is
not manageable, certain negative experiences not withstanding,
nor is it really available. What happens is that if all of the
aspects of a given process line up, we perceive that function as a
state. So, we perceive the system as available when all of the
aspects making up the system’s process functions execute the desired
result. We perceive it as manageable when it either fits into our
existing procedures or we can build a management process to create
what we need.
The second is that someone needs to
have his head out of the silos so he can understand the big picture.
You can call this person your architect, your lead, your senior, or
just the guy you feed pizza and cola though the slot in the door.
Someone has to see the whole board; otherwise our approaches fragment
and we start to pursue system states rather than the fundamental
processes able to create the impression of a state.
I need to spend more time with this
idea, I think. It’s fundamental to both ITIL and several IT
architecture frameworks, so maybe I can borrow some language from