Bob Aiello lit the blue touch paper (again) on the debate about ‘what is configuration management?’ and, once again, he seems to be trying to redefine configuration management to fit the role of Configuration Manager identified (incorrectly) in many organisations. This is absolutely the worst way to define configuration management.

Let’s now look at Bob’s list of things he want to dump on CM’s lawn.

I often describe that there is a big CM and a little CM.

Big CM is the field of Configuration Management which I suggest includes:
* Source Code Management
* Build Engineering
* Environment Configuration
* Change Control (seven different types)
* Release Management (coordination and engineering)
* Deployment

while little CM refers to Configuration Control (of interfaces).

From Bob’s original post to this thread

This is simplifying CM?  In this article I hope to show why this redefinition is unnecessary, flawed, and ultimately damaging to CM.

If we were to accept that a discipline is correctly defined by looking at the roles identified in organisations then we would never get anywhere (much like this debate). I for example often have the role named ‘Configuration Manager’ and yes  I also do builds, releases, etc as identified in Bob’s list. But then I also fetch coffee for the team and I do the odd bit of development or testing, I write technical documentation, perform product evaluations, project management, risk assessment, and I assist in problem solving for production systems—and yes, sometimes these things (with the exception of fetching the coffee) are part of my official role (although given the current economic climate, who knows). Does that mean these too are defining features of configuration management? No. This is a silly way to define a discipline. Even if you observe that ‘many’ organisations lump the things together it still would not justify redefining configuration management because there’s absolutely nothing to gain, and much to lose, from doing so.

Configuration management (the discipline) has a perfectly sound definition (all together now); identification, change control, status accounting, and auditing. To change this definition is to define something other than configuration management and I have no objection to defining an umbrella term to cover all the disciplines identified by Bob; in fact I do, I call them Development Support Services.

Yes, we could do more to clearly communicate what CM is. Although, I cannot recall a time when I was ever confused by what the the four core activities were, the difficulty always stemmed from more subtle issues like ‘how do I select good configuration items’ and Bob’s redefinition does precisely zero to address these problems. Adding more complexity by mixing in a load more disciplines is hardly likely to aid clarity.

If the idea is that by lumping all of these disciplines under the CM heading we can make CM appear more useful or make it an easier sell to management, then I think that’s horribly misguided too.

You: We want to introduce CM.
Manager: What’s that when it’s at home?
You: Oooh. Loads of good stuff. Build, release, change….
Manager: Hang on. We do most of that stuff already.
You: Ah. But we’ll pull it all together under one heading. Make it more coherent. Make it better.
Manager: Create a bottleneck you mean.
You: No. No. No. We’d be specialists.
Manager: So CM is just all this stuff under one team?
You: Oh no. We also do identification, change control, status…. *noticing manager slip into comma* Oh, wait. Remember the ITIL course you went on?
Manager: Oh yeah. That was a great couple of week. Great evenings…. Oh. I mean, yes, very valuable.
You: And you remember them saying you needed a good CMDB?
Manager: Yeees?
You: Well that’s what we’ll do.
Manager: As well as all this other stuff?
You: Sure.
Manager: And what about all the people already doing the other stuff?
You: They’ll be part of my team.
Manager: Hang on. Your team?
You: Of course. They’ll be under the CM team.
…. and so on…

Obviously I’m being slightly facetious, but hopefully you see my point; why complicate things? The manager is now more confused about what CM is than he was at the start. Sure, you’ve made a pitch to create a service team supporting development, but you’re not closer to furthering the CM cause than you would have been had you just reminded the manager about his ITIL course in the first place. You’ve made no real progress in explaining CM, you’ve just hidden it amongst a load of other stuff, possibly to the point of obscuring it completely.

‘But we should move with the times’ is a common enough response. I agree. Let’s draw a parallel to show how it’s unnecessary to abandon the existing definition of CM but still move with the times.

Science is decomposed into disciplines. Physicist will often joke (and in some cases only half-jokingly) that all other sciences are ultimately reducible to physics and therefore physics is the only science we need. This seems to be what those who want to lump all these other disciplines into configuration management are set on doing, lumping all the other disciplines into one. And, just as with the science example, it’s a bad idea.

Continuing the parallel between CM and science. Just because scientists resist the temptation to mangle all their disciplines together hardly means they’re not moving with the times. Biological science is unrecognisable from fifty years ago, but it’s still Biology. Similarly, configuration management’s scope has increased as we have more powerful tools we can realistically monitor and control to a finer and finer degree of detail. Where in the past a configuration item’s scope would be limited by the capacity of a paper system to realistically track it, we can now declare almost every file in a system to be a CI if we so choose.

What Bob (and I’ll use Bob as a proxy for all those who support the view that CM should absorb all these other disciplines) seems to be proposing is something like the following (I’ve reduced the list to just build and release management to keep the diagrams simple, my point is still made I think).

Or, heaven forbid, the following.

In the first case build and release management become intrinsic parts (aggregate into) configuration management. In the second (shudder) they become inner classes, only accessible through the configuration management wrapper.

Both of these system architectures are… well. They’re terrible design. If a software engineer came to me with this design I’d fire his ass. (If people are sufficiently interested in me expanding this claim, I will do so in another post.)

One observation, made by Joe Townsend, was that the four activities that constitute configuration management are still to be performed within many of the sub-discplines identified by Bob. If this is so, then why not keep the CM discipline separate and have these disciplines use it rather than mangling them all together? What possible benefit is accrued by redefining CM in this way? ‘Oh well, CM is still a part of some of the disciplines we want to put under the CM banner. Erm. No. Wait. The ‘four activities formerly known as CM’ as now part of some, but not all, of the disciplines that now make up CM’. It just makes no sense. It’s adding insult to injury. It’s muddying the waters. You get the idea; you’re doing nothing at all to help clarify CM and your piling in a load of additional stuff that does not belong in there.

Let me be clear. If you want to be called ‘Configuration Manager’ and cover all the disciplines Bob identifies, good luck to ya. You won’t be the first, or the last, to do that. Heck, you can take the title ‘Lord of all he surveys’ if you like. Makes no odds to me. My gripe is about redefining the discipline of Configuration Management in these terms.

The following diagram shows how build and release management simply use configuration management. A much more elegant structure and one that benefits from modularity, making it much simpler to explain each discipline—also making it simpler to ‘debug’ the processes involved. (The benefits of such modularity should be obvious, but if people are keen for me to expand I will do so at another time.)

It’s simple. It’s elegant. It’s modular. It’s scalable. And IT’S WHAT WE HAVE NOW! (Well, those who have not polluted the well.)

Another objection is that this combination of disciplines under the CM rubric is only done for Software Configuration Management (SCM). What! Why? Why do people insist on making this asinine distinction? SCM is ‘Configuration Management of Software’, which, according to the correct definition of CM is precisely the same discipline as, for example, ‘Configuration Management of automotive engineering’, ‘Configuration Management of hardware’, or ‘Configuration Management of X’ for whatever ‘X’ you care to put in there.

If you accept the universality of CM principles then the multi-discipline agglomeration proposed by Bob makes even less sense. Most engineering CM systems, for example, have no build discipline within them; the CM discipline is used by fabrication plants to provide reference material (engineering specification, computer controlled tool programs and the like) from which the fabrication plant build the items. The closest these CM teams get to performing a build is assembling a baseline to be passed to the fabrication teams. It is simply coincidental that people labelled ‘configuration manager’ in the software business tend to be qualified to do build management. This is not sufficient justification for putting build management under the CM (or even SCM) banner.

Even if you claim justification for putting these other disciplines under the CM banner by saying something along the lines, ‘oh, well CM does not ‘do’ the builds necessarily, they’re just responsible for ensuring they are done’ I say that road leads to perdition. You could justify the inclusion of almost anything you want under the CM discipline using that argument, and you’d be wrong every time.

In the course of helping a client look for tools to support their development process I recalled that a couple of years ago I looked briefly at JIRA when building a change control system for another client. So, I suggested we look at JIRA as a possible tool for this new system.

Having looked around the JIRA site I noticed that Atlassian had also taken FishEye (a tool I had used before for providing viewing and analysis tools on repositories) into their stable. And they also support a whole suite of integrated tools that can be used individually or together.

I suggested we take a closer look. So, we set about creating a very simple demonstration of the tools.

I have to say, ‘I’m impressed’.

These are great looking, well integrated, easy to use, easy to set up and very competitively priced tools. Based on a couple of months playing around with them, I’d have absolutely no difficulty recommending them to organisations of almost any size—certainly they should be on your list of tools to look at.

Not only are the tools themselves very flexible and easy to configure but the company seems very keen to hear from their customers. They have open beta programmes and actively encourage users to take part in product development (they really do want to know what their customers want). They also provide really low cost licenses; up to 90 days evaluation licenses and then for small teams (or individuals) they offer 10 user licenses for $10. Seriously! This is a brilliant move. It means freelance consultants (such as your’s truly) can actually use their tools and develop for them, without needing to remortgage the house to obtain licenses. (The tools also don’t require a massive hardware commitment—in fact I’m running a system on a Linux virtual machine on my Mac Pro  and it works great for development and creating documentation/training material.)

Oh, and if you’re a non-profit or open source organisation they will let you have unlimited licenses for free! Genius.

Can’t be bothered with all that setup? Atlassian offer a hosted solution for many of their tools too. (Although I can’t comment on these as I have not tried them, but if they’re anything like as good as what I have seen so far, they’re probably worth looking at if you want a hosted solution.)

The price apart, the tools really are very good. And if they don’t do exactly what you want you can always write your own extensions. Atlassian publish comprehensive developer information and the tools all communicate through open web interfaces and all support a plugin architecture (which I understand Atlassian are working hard to make simpler to use).

Another promising sign is that Atlassian ‘eat their own dog food’. They user all their own tools internally and pride themselves on being the guinea pigs for all their product development. Their own website and online documentation is all run through their own products.

Even better! Atlassian let their product speak for itself. No annoying salespeople calling, no pressure to come along and ‘do a demo’. They just provide you with a really simple way to download their product, get an evaluation license, and then let the product do the selling (no kidding I had downloaded, installed and licensed JIRA in about ten minutes—it took about a day to install, license and integrate the entire suite). Brilliant! [Note to all vendors: if you're product is good then let it speak for you. If you're product needs to be explained, then make it better, provide good online documentation, and provide help when it's requested. I understand that some customer like a demo, but many just want to try out your product for themselves. After all, if it can't be setup and used by their own staff, what hope is there for the future? They just end up being highly dependent on your consulting services. Oh. I think I get it now.]

If, as seems likely, the client goes ahead with this solution I’ll be sure to report back on how these products perform under real life conditions, but for now, go take a look.

The problem with many of the other terms is their absolutism; ‘this is the right way’, a sort of ‘here is the solution, not what was the problem’ attitude. I say, ‘no’. I say that the correct approach is always ‘it depends’.

Contingent CM emphasises that there is no one solution, there is no ‘best’ way to do CM and the core CM discipline is independent of the method, process, approach or dogma to which it is being applied. You should learn the underlying principles of CM, then you can apply it in any arena.

Given the modest success of that experimental session, I have planned a series of similar events (details can be found here).

Currently planned are:

• “What is a configuration Item?” – Friday 4th March 2011
• “Version control for beginners” – Friday 18th March 2011
• “Branching. What, when, and how” – Thursday 31st March 2011
• “Parallel development. What, when and how” – Friday 15th April 2011
• “Selling configuration management” – Friday 29th April 2011

All meetings are free to attend and are currently planned for 20:00GMT (There really is no good time that covers all time-zones. If enough people ask I may repeat meetings at other times to cover other timezones—better yet, why not organise one yourself .)

I’ll certainly be chatting for half an hour at least (if no one else steps up to contribute I can certainly talk about any of these topics for at least that long ) but I’ve allowed two hours for each session and am happy for sessions roll on beyond this if there is enough interest.

These are informal discussion groups intended for any level of expertise (although obviously some are aimed primarily at beginners I would welcome input from experienced users too). I will probably make some opening remarks to get things rolling, but I am hoping enough people are interested to make for some real discussion.

You can contribute through the text ‘chat’ on the site or better yet if you have a mic (and video camera if you like) you can step up and present your ideas that way.

Come along if you have questions, are just interested in the topic, or have something to say on the topic being discussed.

Let’s put this into concrete terms.

Suppose the original change request is something like, “correct the spelling mistakes in the poem” and the poem is held in two files.

file1.txt contains the following text.

Mary hard a litl lamb,
It's fles was wite as snow,

And file2.txt contains the following text.

And everywere that Mary went,
That lam was sure to go.

We correct these two file to the following using a change record CR1.

Mary hard a little lamb.
It's fleece was white as snow

And everywhere that Mary went,
That lamb was sure to go.

Here then is my first build (build1).

Initial build: conceptual and literal change equivalent

So, not bad, but the still have “hard” instead of “had” in the first line of file1.txt. This does not change the integrity of build1, but does make another build (build2) necessary to include a correction to the erroneous work submitted into build1.

There are different ways we might choose to track the correction of the defect arising from build1.

Each approach has its own merits but, from the perspective of build integrity, they share an the important feature; when dealing with the conceptual change “correct the spelling mistakes in the poem”, they are semantically equivalent. For build2 to have integrity it must include both the revisions associated with the original change and all new revisions associated with the correction to the change, regardless of how that correction is controlled.

We correct the defect in build1 with an additional change to file1.txt to produce the following.

Mary had a little lamb,
It's fleece was white as snow,

The following illustration shows build2 (in this case I have re-used CR1 to correct the defect). I should be obvious that missing any revision associated with CR1 has the potential to break the build’s integrity (we may have only part of CR1 in the build).

Fix Build: Conceptual change implemented with reworked literal change

Fix build: Conceptual change now implemented with two literal changes

And this is the point. Yes, the literal changes CR1 and D1 are, in one sense, changes. In practical terms though each on its own fails to achieve the objective of the original change request and consequently they are little more than sets of revisions. The two literal changes controlled by records CR1 and D1, taken together, achieve the original goal of the change request “correct spelling mistakes in the poem”. It is this latter type of change (what I have called conceptual change) that is more interesting to configuration management and build integrity is maintained through these conceptual changes rather than the less significant literal changes.

This distinction between the conceptual change and literal change becomes increasingly important as we consider configuration integrity, a subject I shall discuss in more detail in subsequent posts.

The great advantage of semantic web over efforts such as the now defunct Application Lifecycle Framework (ALF) is that it requires no agreement between vendors (beyond using semantic web technology). The weakness of efforts such as ALF is always that they demand buy-in from the main tool vendors. A substantial number need to agree to develop and support the new standard.

Certainly semantic web is no panacea, but at least if Vendor A chooses one semantic representation of CM information and Vendor B chooses another they can still communicate by creating a correspondence rule set between the two representations (a little like XSLT can transform one XML into another — only a little though, semantic web has much more to offer).

So vendors need to agree to use and provide semantic web representations for CM information? No, not really. Most tools provide APIs that would allow this information to be interpreted from, or added to, any existing tool. Certainly a non-trivial effort, but one that is at least feasible. Better still, if multiple implementations are created for any tool these can again be consolidated using semantic web techniques.

The real power of semantic web technology comes from two sources; the abstraction of information semantics, and the ability to draw inferences from this information. Once you have an ontology, some inference rules and semantic relationships between ontologies, your inference rules will work across ontologies — neat. What does all the gobbledy-gook mean? It means that if Vendor A develops an ontology with a set of inference rules (rules for extracting more information from the underlying information) then Vendor B can map their ontology onto Vendor A’s and use Vendor A’s inference rules too. Actually it’s even better. User X can extend the rules and have them apply to Vendor A and/or Vendor B’s information sets equally, even if the original inference rules were designed for only Vendor A.

Brilliant. Problem solved then? Sadly, no. Although this all offers promise of a way forward there remains a lot of work to establish these semantic descriptions and, as many have discovered before, agreeing on the precise meaning of each semantic element is nontrivial in its own right. Not that this should stop us attempting the task.

Remember a few posts back I mentioned working on a CMS reporting tool? Well, I’ve been working with a client on a tool for managing parallel development, which is closely related to the type of reporting I had in mind for the CMS reporting tool. The client’s focus is on Dimensions, but in the interests of creating a flexible system I’ve been designing with other underlying in mind (although, as is often the way, timescales and pragmatism mean the implementation is sometimes more tool specific than the original design). The result of this has been some extended mental gymnastics that have resulting in some useful and hopefully interesting thoughts that I would like to share with you now.

The parallel development tool needs to both report, analyse and, ultimately, update the host SCM database. There are a number of special considerations that I won’t go into now, but these created much candle burning and banging of my head on desks, walls and other solid objects as I struggled to resolve some apparently simple problems that turned out to be rather tricky. (The sad thing is, as is often the case with these things, once I had an answer it turned out to be deceptively simple.) The upshot of all this cranial damage covers a wide variety of topics, too many for a single post, but we can make a start.

Identification

How do we identify things?

Each tool has its own method of identifying the things it controls. In Dimensions items are ultimately identified by some sort of unique specification; files are identifies by an Object Spec, projects (worksets) are identified by Project Specs and so on. Each of these Specs. provides a unique reference within the context of a specific Dimension base database. Subversion identifies things by their position in it virtual file system; path and revision. Again, Subversion references are qualified by the repository in which they are held. Since Subversion repositories can be referred to by any number of methods there is no one unique ‘name’ for an item in Subversion once you step beyond the bound of the repository (I can, for example, use several host names to refer to the same repository).

With this in mind, how can we uniquely refer to a single controllable entity (I shall use the term ‘Artefact’ to represent a uniquely identifiable thing). For simplicity we’ll focus our attention on a file, after all with software configuration management (SCM) this is the most common sort of Artefact we want to control. As I discussed briefly in a previous post, files exist along two histories; the Revision History (in which new Artefacts are created for each revision of the file), and the Lifecycle History (in which an Artefact may undergo change without changing its revision, without becoming a new Artefact). Dimensions does a nice job of recording these two histories, but our challenge here is to differentiate identities.

Do we assign the identity to the Artefact’s revisions, or do we assign the identity to each Lifecycle historic state?

To illustrate, consider file1.txt. This file will be subject to the simple lifecycle illustrated below.

A very simple lifecycle

Starting in the state NEW we assign the file1.txt Artefact a revision of 1. The Artefacts two histories and its change log are illustrated below.

file1.txt - a simple change log

The developer chooses to change the original file1.txt but while in lifecycle state NEW we do not require a new Artefact, the resulting edited version of file1.txt remains revision 1. The lifecycle state also remains NEW, so although we have travelled the In-place Edit path in the lifecycle, the result is an edit event but no change in either the state or the revision of file1.txt. Using state and revision to identity the Artefacts (the one before the edit and the one after the edit) is therefore not sufficient to account for the two different edited versions of file1.txt.

We could simple state that we are not interested in such edits or we could also simply assign some ‘point’ revision to distinguish these intra-state revisions. Both of these options have been adopted by tools in the past, but when trying to generalise a solution we need to accommodate as many possibilities as we can. Generalising a solution should allow us to sit atop any underlying implementation. To arrive at a generalisation we need to explore the problem domain further.

Derived Identities

Perhaps the answer lies in content-based addressing (CBA). With CBA we identify Artefacts by creating a signature based upon intrinsic attributes of the item itself. This works very well for electronic data (in our case, files). There are many CBAs available and they are widely used in peer-to-peer systems for identifying files. The current darling of the CBA world is the SHA-2 family of hashing functions. These hashing functions process the stream of bytes in a file (or any other source of data), producing a single ‘summary’ string of characters which is much shorter than the original (often 64, 128, or 256 bits long).

CBA has huge appeal for our purpose in uniquely identifying an Artefact. A CBA is almost guaranteed to be unique to the data being encoded (I say almost because any CBA will ultimately collide — two data sets produce the same hash — since a potentially infinite set of data is being mapped onto a finite set of hash codes). A CBA is intimately related to the Artefact’s characteristics and so no assignment authority is required (see Assigned Identities a little later). This also means that given an Artefact we can work out its unique identity, providing we know the hash function and the attributes used for identification (a files data, for example).

CBAs work very well for electronic data. Unfortunately, CBAs do not work well for the general case. How, for example, might we assign a CBA to a physical Artefact?

Assigned Identities

This brings us to assigned identities. An assigned identity is one that, unsurprisingly, is assigned by some agent. Examples of assigned identities are legion. The ISBN you find on any book you buy is an assigned identity, not for that specific book, but for the data and form of that book (hardback version of the first edition of XYZ). Similarly, almost all products have a UPC (Universal Product Code) — the one that you find encoded in bar codes. Again, UPCs are assigned to a ‘type’ rather than the specific item; so the UPC code 50036 90803 refers to JBL Duet speakers, but not to the specific pair of JBL speakers sitting on my desk.

To ensure the uniqueness of assigned identities two conditions must be met: the scope of the identity must be well defined (ISBNs apply only to books, UPCs apply only to products, and not, for example, to ideas or patents), and there must be some central agency who defines and issues codes (or at least issues blocks of codes to be issued by approved agents).

Assigned identities are not derived from the Artefact that they represent, so there is no way, when presented with an Artefact, to establish that Artefact’s identity, other than by reference to some catalogue to see whether it already has an assigned identity. This could be a very long process if we relied on the data as a whole. ISBNs for example, can be looked up using the books format, title, and edition. These three attributes for the key by which the ISBN can be referenced in a catalogue. This presumes the existence and universal availability of a definitive catalogue.

Another form of assigned identity is the Universally Unique Identifier (UUID). UUIDs also use hashing functions to condense a set of attributes to a string of 128 bits, but the source data is not the file’s content but a series of attributes that are themselves (hopefully) unique. There are many implementations of the UUID scheme and they use different attributes to generate the UUID itself. Like CBA, a UUID is almost guaranteed to be unique — certainly sufficiently unique for most practical purposes.

So where does all this leave us?

An identity based on CBA is great for known data sets because the identity is generated from the data itself. We can therefore recreate the identity independent of any central authority. We can take a file and work out its unique identity and then use this unique identity within our tools. This, as we shall see in coming weeks, has significant advantages to resolving configuration data across distributed databases.

The problems with CBAs are that they do not translate well into the physical realm (we need to establish some characteristic of the physical object that can be uniquely selected for encoding into data and subsequently used to generate the CBA), and they are quite costly to generate (we need to read and process the entire data set to create the CBA).

Assigned identities that rely on an assigning authority (like the ISBN) require significant organisation and coordination. Each assigning authority must be organised to ensure that each identity is assigned uniquely. And here we run into another question related to the other form of assigned identity, UUIDs.

What do we mean by ‘uniquely assigned’? Suppose I create a file containing the text ‘The quick brown fox jumped over the lazy dog’ and I assign it a UUID. Some time later, you create a file with identical content and assign it a UUID. The two UUIDs will be different. Are we then dealing with two Artefacts?

In one sense we are. They are two distinct incarnations of the file. But in any useful sense, we are not. They are in fact the same file. Just as if I took my original file and copied it to another location in my file system I would consider it the same file. Or if you copied your file to my file system I would be unable to distinguish your file from mine. They are the same ‘thing’, but we have assigned different identities.

This is the problem with all assigned identities; how to ensure that the ‘thing’ being identified has no identity already assigned.

Is there an answer?

Yes and no. The work currently underway with the semantic web project (quick overview here) offers some hope. There is still a reliance on ‘authority’ to assign identities, but I think there is much to be learned from the general approach and using a combination of derived and assigned identities will allow easy reconciliation of information between CM datasources. I see the problem of configuration management (and particularly identification) as a special case of identification within the semantic web project.

This is a fascinating area (well, it is to me) of research and one that I believe will be increasingly important as CM moves into ‘the cloud’. As the distinction between CM data under your direct control and that controlled by proxy through service providers and third parties is eroded the need to consolidate CM information across disparate tool sets and managed by different agencies will become increasingly important. This is a problem that we must solve.

I spent some time a couple of years back considering Topic Maps and Resource Description Framework (RDF) as possible SCM schema. Although they are functionally equivalent, RDF seems to have won out in the standards battle. If you are interested in seeing where I think information management is going in the 21st century (and where CM must also go), check out the semantic web.

It is easy to become entangled in confused terminology when discussing items and item histories. To avoid such confusion I will define an Item as a specific version of something we control (most commonly in software configuration management these ‘things’ are files, so for the remainder of this post I will use files to illustrate, but remember that an Item could be anything we version control).

With this definition in mind we can define one type of history as a set of Items related to one another by a predecessor/successor relationship. This is the most common history one becomes familiar with, the revision history.

But there is another history worth considering. The process of managing an Item may involve the Item passing through a number of states. We commonly refer to these states as a lifecycle. An Item may be created into the NEW state, then be edited by a developer in the DEVELOP state. Once completed the developer may submit the item to the REVIEW state for a code review. The item may them pass through various states before finally reaching the RELEASED state. The lifecycle history is independent of the Item revision history.

To illustrate the difference between the lifecycle history and the revision history consider file1.txt shown below. This file has three revision Items; 1, 2, and 3.

Zooming in to the file1.txt revision 3 Item we see the following lifecycle history.

file1.txt revision 3 passed through all of these lifecycle states, passing through the DEV-TEST states twice as a defect was found and resolved.

Version control tools track the revision history but seldom the Item lifecycle history. Configuration management tools, such as Dimensions, capture both the revision history and the lifecycle history.

Any generalised tool for analysing and reporting configurations from as wide a variety of sources must deal with these different histories.

In this article I am going to lay out my definitions for some terminology that will become increasingly important as I develop my CMS model.

The terms I will be discussing are as follows.

• Stream
• Branch
• Configuration Item
• Revision
• Configuration
• Component
• Repository
• Configuration Management Database
• Record

At this point I caution the reader that these definitions are deliberately quite loose and informal. Each will be expanded, refined, rewritten and formalised as I work through articles in this blog. For now, my working definitions are as follows.

Project

A coordinated effort usually conducted by several individuals to deliver a Product. Project describes the totality of planning and activity requires to gather requirements and interpret these into Product.

Product

That which is to be delivered by a Project. Products include, but are not limited to:

• Executable software
• Documents — manuals, design documents, requirements, installation guides, administration and maintenance manuals
• Hardware — computers, network components, any other physical components required as part of the Product
• Training materials — exercise version of data or system components, trainer presenation, training the trainer material, sandbox systems for trainees
• Source code — when developing for a 3rd party. Source code may also be a deliverable in interpreted languages or when delivering web content such as HTML.
• Media — video, graphics, audio

Stream

Projects often consist of more than one piece of development. A common strategy is to manage these pieces of development as a sort of sub-project. Timescales of these Streams are overlapped to allow the project to compress its overall timescale.

Branch

An implementation technique used in development to manage simultaneous changes to common items. In software development Branches are common and used to allow two or more developers to work on the same source code simultaneously.

Configuration Item

A configuration item is an item within the configuration management system that is the focus for change management.

Revision

Each time an item is modified and submitted into version control, a new revision is created. In this way an item’s history can be traced by looking back through the sequence of revisions.

Delta

The difference between two revisions.

Configuration

A specific arrangement of item revisions.

Component

An item that is subject to version control, but is not elevated to the status of a configuration item.

Repository

A safe store for item revisions.

Configuration Management Database

A database containing information about each item revision and their relationships to one another and to records.

Record

A set of data that is subject to a process or workflow but not necessarily version control. Records normally carry information used to account for an item’s current disposition or the current state of a process or workflow.

CM Tool Architecture

As with all multi-layer architectures the important feature is that each layer creates an abstraction then allows layers it serves to use a stable interface. The CM Data layer, for example, will need to deal directly with individual the tools we wish to interrogate. (Recall that I am currently only proposing a tool that analyses and reports the content of the underlying tools, writing a tool to also update the content of those tools adds a whole new set of challenges to the problem. Challenges I have no desire to deal with right now, but which will be served well by this architecture nonetheless.) The CM Data layer presents one, hopefully, stable interface to the CM Model, so the CM Model will not have to be changed is a tool changes its interface (changing its database schema, command line, API, or whatever method we use to access it).

CM Data

This layer presents a common interface to the CM tools that the CMS is fronting. CM Data can be divided into two categories.

• Item library — this holds the items the CM tools store; files, directories, symbolic links, etc.
• Data about items — this is data such as relationships between items, attributes of items (owner, author, date modified, and so on).

The CM Data layer will provide methods for accessing these data. Items will be held in a Repository and the data about these items will be held in a CMDatabase.
All version control tools are a Repository (they store items) and provide at least some data about those items (author, modified date, ancestor/successor relationships, contains relationships), so they provide some functions of a CMDatabase. More advanced tools (like Dimensions and Synergy/CM) provide the same Repository functions but they expand these considerably (adding in records such as change requests) and the CMDatabase functionality is also expanded. These points will be revisited and clarified as we proceed.

CM Model

The CM Model will provide an abstraction of common CM artefacts (items and their relationships, collections, baselines, branches, changes and so on). The point of this abstraction is to, once again, provide a consistent and stable model to the layers that use the CM Model. So, the code in the Business Logic and Presentation layers is written to use the CM Model rather than the various implementations of these artefacts presented by the underlying tools. This means our system can access, say, an Item without needing to know how it is represented in the tool or even which tool it is held in.

The CM Model is perhaps the most important part of the architecture to design. It needs to be sufficiently comprehensive to accommodate the various tools’ concepts but at the same time it needs to be as simple as possible and as stable as possible to preserve a stable interface to the rest of the system.

Business Logic

The Business Logic layer is where all of the rules about how the CM Model is to be interpreted and managed. The most challenging aspect of the Business Layer is the need to allow users to define their own rules without requiring them to program anything into the system (although we will surely make the tool easy to extend programatically). This layer will require a detailed set of user cases and a considerable investment of time in the early design if the final product is to be flexible enough to accommodate a wide variety of users.

The Business Logic layer’s functionality can be divided into two classes; those features of SCM that are fundamental and those that are definable. Establishing fundamental features may be a matter of diktat on my part, but never-the-less I will try to only hardcode rule when absolutely necessary, preferring instead to provide configurable rules. *scratched head* This could take some time.

Presentation

Finally there is the presentation layer. Here all of the various methods of presenting the system’s functionality are gathered. This is perhaps the simplest layer to define functionally but the most difficult to design aesthetically. Having established what the system can do in the other layers the function of the Presentation layer is to provide a method of allowing the user to request that functionality, and providing a means for the system to provide the results to the user. The challenge with user interface (UI) design is how to achieve these two functions in an easy to use and, preferably, intuitive way.

In the first instance I shall probably provide a command line interface as a priority with some form of rudimentary GUI as a secondary development. Once these are done other interfaces may be considered.