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

might help.

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

them.