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

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.

If two items belonging to different revision histories are combined we produce a graph with more than one root, as illustrated below where file1.txt revision 3 has been combined (merged) with file2.txt revision 2 to produce file1.txt revision 4 (or arguably we might call it file2.txt revision 3).

This second situation is often overlooked when considering product integrity. Tools often do not track merge operations between two revision histories like this, so the information about the merge is not available for analysis. The difficulty arises when, in our example, file2.txt is developed to revision 3 under the same change as revision 2 (suppose CR1 was only partially tested when the merge took place and a defect was found and resolved in revision 3).

It should be obvious that file1.txt revision 4 contains only part of change CR1, it therefore lacks integrity. Checking this and reporting it to the user is very difficult if the merge operation is not properly tracked.

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.

Many ticketing systems, supporting processes such as incident management, are prone to ticket ping-pong where tickets are bounced from queue to queue as people keep forwarding the problem to get it off their queue. This is simple to control once you see the problem.

Processes that suffer with this problem all have one thing in common; they all allow one user to simply pass a ticket from their queue to another unchallenged. For example, an incident ticketing system shows up a ticket on Person A’s queue. They cannot deal with it (or do not want to deal with it), so they look for someone they believe should deal with it and assign it to their queue (Person B). Person B looks at the ticket, decides they should not be dealing with it and looks around for someone else to deal with it (Person C). And so it goes, the ticket to bounced around from queue to queue never being handled but always being sent on, possibly even returning to Person A who forwards it on again and the cycle continues.

The problem is that the ticket owner in such systems is defined as the person who has the ticket on their queue and anyone can pass a ticket to another queue. Since no one wants to be lumbered with the ticket it just keeps being passed on. It becomes an SEP (someone else’s problem), doomed to forever wander the queues, never being resolved.

Fixing this process is actually very simple. When a ticket is initially raised by a user onto someone’s queue (let’s say Person A) the queue owner becomes responsible for progressing the ticket. If the Person A believes the ticket belongs to someone else (say, Person B), they propose it into Person B’s queue. But, and this is the important change to the process, ownership of the ticket remains with Person A. Person A remains responsible for ensuring that the ticket is progressed (not simply passed from queue to queue) until Person B accepts the ticket into their queue. This puts pressure on the Person A (as the ticket owner) to actually manage the process, whereas the original process did not pressure anyone because they could simply pass the ticket on to someone else.

It may seem unfair on Person A. It could be that they really cannot deal with the ticket. It could be that Person B really should take ownership of the ticket but they may be trying to avoid doing so by not accepting it into their queue. This is what escalation is for. If Person A has a legitimate cause they can escalate the problem and effectively force Person B to acknowledge their responsibility. In practice this is seldom an issue as Person B, if they recognise their responsibility will simply accept the ticket into their queue and progress it to completion.

I Person B genuinely cannot, or should not, deal with the ticket they simply inform Person A of their reason for not accepting it into their queue. Person A must now seek the correct person to resolve the ticket. Because Person A is responsible for the ticket until someone else takes charge of it they have a vested interest in finding the correct person to deal with it. If they propose the ticket to someone’s queue and do not get a quick response they have a vested interest in following up to find out why the ticket has not been accepted. Person A is motivated to find the correct ticket owner since no one but the correct ticket owner will take the responsibility for progressing the ticket away from Person A and until some takes it from Person A it remains theirs to progress.

Ensuring that people cannot simply pass tickets around the system ensures that they are progressed because it puts pressure on owners to either resolve the ticket or to find the person who really should resolve the ticket.

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.

Fences seem most appealing (even if only for humanitarian reasons), but they are expensive to construct and maintain. Furthermore, constructing a high fence will block the beautiful views across the sea and people will stop visiting the site (which is bad). So your fences can be only so high before they become an impediment and stop people using the facilities. Unfortunately, keeping the fences too low means people can still climb over them and (you guessed is) fall to their doom.

Maintaining ambulances at the foot of the cliff is also expensive. There is the possibility that people falling over the cliff will be so harmed that they do not survive the fall and even those that do survive may be out of commission for some time. Ambulances seem like a last resort, a safety net. Too few ambulances means more injured fallers die when they could have been saved, too many ambulances means increased cost without any benefit.

There is a balance to be struck. Fences to guard against the unwary and ambulances to recover the unfortunate (or plain stupid).

This balance between ambulances and fences is the line that process engineers walk. We try to design fences that are cheap to install, efficient to maintain, stop the majority of people falling over the cliff, and allow people to enjoy the facilities along the cliff edge safely. At the same time we know that there will always be those who venture beyond the fences (they cannot be secured without blocking the view and driving people away — possibly to another cliff), so we prepare a small fleet of ambulances to minimise the impact (forgive the pun) of those who fall.

Creating a process that allows facilities to be used efficiently but also provide a means of identifying and safely recovering when things go wrong is the skill of a good process engineer.

A good example of this is the combination of change and incident management. Change management is a fence, a process designed to avoid problems. Incident management is an ambulance, a process designed to minimise problems once they occur. When change management fails because either someone circumvents the process (climbs the fence) or because the process is incorrectly applied (the fence is damaged or too low) then incident management identifies the resulting problem and hopefully resolves it as quickly as possible (ambulances recovering the injured faller and saving their life).

If change management processes are too draconian they will be expensive (delaying change and making your organisation unresponsive) or simply circumvented when users perceive them to be an unacceptable impediment. If incident management is under resourced they will be incapable of recovering from problems when they occur. As change management becomes less effective the cost of incident management rises, as change management becomes more effective the need for incident management declines.

Striking the right balance is a matter of judgement and will vary from organisation to organisation, and from service to service. The more sensitive your service is to problems, the more change control is called for, the less sensitive your service is to problems, the less change control is required.

A problem in, for example, an order processing system for a mail-order company has serious consequences and suggests more change control should be applied. The cost of failure is so high that incident management costs would be unacceptable. Within the same organisation the system that produces the print catalogue is less sensitive, so change management costs would normally be lower and more incident management might be called for.

The key to good process design and implementation is balance between constructing fences and maintaining ambulances.

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.

1. People are often more afraid of the perceived problems than the practical realities of parallel development.
2. People do not truly appreciate the problems and practical realities of version control and parallel development.
3. There is a need for more theoretical work on the topic and, perhaps more significantly, a need for more formal expression of the process and problems involved.
4. There is a quite substantial book that could be written on the subject.

The first two points are related to the last two insofar as people need a clear explanation of the discipline and, to really acquire a firm understanding of the subject, you need to commit to studying it. There is simply no easy way to explain the more complex material (and by simple I mean one side of A4 summaries demanded by people who think they need to know but who have no practical exposure to the technical nature of software development or version control — there is no ‘managers guide too..’).

As to the third point, I have expressed a concern about this before in various forums. Rather than continue to observe the problem I have decided to start doing something about it. So, over the coming weeks and months I will be expanding some ideas I’ve been mulling over for many years in a series of posts to this blog (special category set up here) and on my website. Be warned though, these articles will probably get very theoretical, often be speculative, and may raise as many new questions as they resolve existing ones. We shall see.

As for the final point, as I build up a sufficiently cogent set of material while writing on the blog (a process unlikely to be well structured), I will assemble more coherent articles on my website and who knows I might get round to pulling them together into a book one day. (Ha! Another of the many books I either intend to write or am in the process of writing but may never finish or publish — *sigh* so many things to do, so little time.) I may even pull material together and add it to the CM wiki or the ITSLM BoK. You never know, stranger things have happened.

Rather than start here, I’ll start an introductory post right now and hopefully have it up in the next day or two. In the meantime, you could check out some past posts on the subject; here and here