I've taken a few days off to spend time with my son (it was half-term last week), but I feel I owe you something. So here is something.
I've worked for over 18 years in the IT
industry most of it in CM and related disciplines, working with
companies to improve their IT system's development and management. In
all that time I've thought I have had a clear conception of what is
was I did and how I did it.
While writing this book I've
discovered many things about myself. Amongst these things is the fact
that things I thought were crystal clear to me are in fact a little
murky when I start to explain them on paper. Taking a critical look
at your subject, trying to distill what you do on a daily basis into
a simple but useful lesson for someone else is very difficult.
I
am determined to make my book more than a description of what IT
systems lifecycle management (or, as a core subset of ITSLM,
configuration management) is. I want it to be more than a simple
checklist, I want it to be a toolkit. I want my readers to take away
a set of useful knowledge and skills that can be applied flexibly, not simply a set of
wrote responses. This is proving to be challenging.
Take the idea of identification, simple
huh? Well, no. Actually there are all sorts of things we can say
about identification. Firstly we have three aspects to
identification:
- What are we identifying?
- What form does the identity take?
- By what process do we select things to
identify and assign identities to them?
Then there is the crossover of topics.
When you talk about identity in the broader sense you start talking
about changes (which leads you into version histories). Then you
start talking about identifying composites and relationships between
the things you identify (and this leads you into configurations). Argh!
Okay, case in point; here I am working
away on identification...
What follows is not verbatim what is in
the book, there's a lot more explanation in the book, but I hope it
illustrates some of the issues I'm hoping to tackle.
Does this belong under identification?
I believe it does because, as I hope this brief outline illustrates,
the identities we assign to “things” and the identities we assign
to specifications (configurations) have different characteristics.
Why is all this important to me? I am
trying to illustrate a very important distinction between the
specification of a thing (its configuration) and the thing itself. I
want to ensure that when I talk about these things later in the book
the reader is clear on the distinction even when I talk about
electronic files where it is easy to confuse the distinction.
I start by using a concrete example of
two PC sitting on two desks. I stick a label to each PC. On one I
write PC-A and on the other I write PC-B. I enter PC-A and PC-B into
a register, noting the PC-A is assigned to you and PC-B is assigned
to me.
What have I identified? I have
identified two physical entities, the two PCs. Great.
Are these two PCs the same? In the
simplest sense the answer is obvious. No. They are two different
physical entities, consequently they are different things. However, I
now provide context to my question.
I will define a specification PCspec-1.
PCspec-1 contains the following information:
- 2Gb RAM
- 300Gb hard-drive
- 3Ghz Pentium IV processor
- 19” monitor
- keyboard
- mouse
I now state that PC-A and PC-B both
meet PCspec-1. Again, are PC-A and PC-B the same?
The answer is a little less clear this
time. If the context of the question is wholly defined by PCspec-1
then the answer is yes PC-A and PC-B are the same. If, on the other
hand, we are still considering the physicality of PC-A and PC-B then
they remain different (they are different PCs).
I now have three identifiers in my
system:
- PC-A - one of the PCs
- PC-B - the other PC
- PCspec-1 – the specification I am
using to define PC-A and PC-B.
I'm going to jump ahead of myself now
(that is I'm going to skip a lot of stuff I discuss in the book) and
consider identities in the context of version control because I think this raises interesting
questions.
Suppose I remove 1Gb of RAM from PC-B.
Without going into all the detail of how I would manage this in real
life what I have implicitly done is create a new specification:
- 1Gb RAM
- 300Gb hard-drive
- 3Ghz Pentium IV processor
- 19” monitor
- keyboard
- mouse
This is obviously not PCspec-1, so I'll
identify this specification as PCspec-2. Now, PC-A is an instance of
PCspec-1 and PC-B is an instance of PCspec-2. But wait! When I change
the specification I created a new identity (PCspec-2), why not also
create a new identity for PC-B, after all I have changed this also.
The identifiers PC-A and PC-B differ
from the identifier PCspec-1 and PCspec-2. PC-A and PC-B are
Artefact Identifiers (they identify “things”, or instances of
specifications), while PCspec-2 and PCspec-2 are Configuration
Identifiers (they identify abstractions). This distinction accounts
for the difference in the way the identifiers are handled.
It is perfectly feasible, and sensible,
to say that PCspec-1 and PCspec-2 exists at the same time. It makes
no sense to say that PC-B “then” exists at the same time as PC-B
“now”, PC-B can only every exist “now”.
What would happen if I did decide to
use different identities? Suppose I labeled the PC as PC-B-1 when it
conformed to PCspec-1 and PC-B-2 when it conformed to PCspec-2? As
soon as PC-B-2 comes into existence PC-B-1 ceases to exist. I would
need to track this somehow (possibly showing PC-B-2 superseding
PC-B-1). If I were using this identity to track the asset (the
physical PC) then I would need to update all references to PC-B-1 to
PC-B-2. This would, in real life, be intolerable. PC-B as an
identifier serves to identify a physical entity, it does not say
anything about how that entity is configured (that is the job of the
specification provided by the corresponding PCspec-1 or PCspec-2).
When I change the physical configuration of PC-B all I need do is
update my asset register (or possibly my CMDB) to show that PC-B now
conforms to PCspec-2.
This whole identity thing becomes
potentially more difficult when we replace the physical PCs with
electronic files. It becomes more difficult not because the situation
is intrinsically more complex but because we make a number of false
associations with the properties of electronic files.
Okay, suppose we set up the same
starting conditions as our PCs but using electronic files. We have
two files (FILE-A and FILE-B) which both conform to the specification
identified by FILEspec-1. FILEspec-1 defines the essential
characteristics of the files (just as the PCspec-1 specification did
for PC-A and PC-B). What is in FILEspec-1?
If I am to usefully construct instances
of the FILEspec-1 it must contain instructions for generating the
content of FILE-A and FILE-B. The simplest way to do this is for
FILEspec-1 to contain a copy of this content. The conceptual error
many people now make is to say something along the lines of, “Hang
on! Surely FILEspec-1 is just another copy of the file then!”
Well, yes and no. Yes, in the sense
that I need some way to create FILE-A and FILE-B and the simplest way
is to maintain a “master copy” of the files content. No in the
same sense that PCspec-1 is not itself a PC. It is essential to
distinguish the specification of the file from instances of the file.
Why must we maintain this distinction
between the abstract specification (what I will eventual call a Bound
Configuration, but again we're getting ahead of ourselves) and its
concrete instances? Firstly, maintaining this conceptual distance
between the specification and its instances allows use to talk
consistently about the difference in managing a configuration and
managing assets (but we'll get to this much later). More importantly,
everything I said previously about the relationships between the
PCspecs (PCspec-1 and PCspec-2) and the PCs (PC-A and PC-B) applies
equally to the relationships between the FILEspec (FILEspec-1) and
its instances (FILE-A and FILE-B).
If I change FILE-B then it becomes a
different file (in the context defined by FILEspec-1), we can label
this FILEspec-2 so that now FILE-B conforms to FILEspec-2. FILEspec-2
contains within itself the content of FILE-B so that I could now
create a new artefact FILE-C which also conforms to FILEspec-2.
FILE-B and FILE-C are different files, they occupy different
locations on my filesystem, however they are the same in the sense
that they both conform to FILEspec-2.
Still with me? Well done! With a fair wind (and assuming I get an editor sorted) I'll be publishing a draft of the identification chapter online before the end of the month so you can see all this in context.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
. 
