- Configurations, being the current content of a workspace. It may be complete or incomplete, but it contains everything the developer needs to work on or work with.
- Streams, to evolve configurations from their current state to a new state closer to the final state (the product release state)
- Control mechanisms to assure that the configurations evolve toward the goal in an efficient and effective way.
In a reaction Robert Cowham wonders what a component is and what a stream is. From a scientific point of view we may need unambiguous definitions before we start reasoning about them, but as a practitioner I rather use fuzziness to create a common understanding and interpretation first. Afterall, we are not writing lawbooks here, nor scientific dissertations.
The 4+2 view of SCM principles as explained by Brad Appleton contains 6 different views:
Each of these views contains 3 aspects to consider:
- Static instances (i.e. physical reality),
- Dynamic interactions between these instances (i.e. birth, life, growth and death) and
- Rules (i.e. laws of nature, traditions) to which the instances and interactions must obey.
For example, a Process view consists of practices (dynamics, the actions how things evolve into different things) which are written down in procedures (statics, how things are at a certain time and place) which require level of competence and motivation before people actually apply them (rules, the laws of nature and reality for things and actions).
Let’s assume that a development project is a single goal: a product that satisfies a particular set of requirements for a particular set of stakeholders. Or in more practical terms, a set of executables and manuals for the customer, and a set of source code, models and development documents for the development organization (for further development and maintenance). So the final configuration (static instance) is known. And suppose the project is starting from scratch, so the initial configuration is also known, you might think…
Wrong! The “initial” configuration does not contain a assets (static instances) to perform action (dynamics). We need to hire developers, acquire computers, install and configure the tools, set up and fill databases with our so-called “initial configuration”, set up the organization of the project (roles, responsibilities, agreements, commitments), etcetera. Only then, the configuration is filled with everything a developer needs to work on or to work with, which makes the initial configuration. Yet, the initial configuration still is a set of static instances.
Then the teams start working. Basically, all they do is taking a configuration and transforming it in another configuration. If we consider a configuration a “point in time and space”, then the continuous evolution of configurations as a “line in time and space”, which we call a stream. Conceptually, each team or even each individual within a team (or project) has a separate set of streams, where at any moment in time a stream can be split (i.e. two actions on the same configuration resulting in two new configurations) or joined (i.e. an action is performed on two configurations resulting in one new configuration).
If this happens completely organically, following the rules of reality to perform the dynamics, without any level of control, it is likely that a Darwinistic evolution takes place where is it unpredictable when and whether any configuration comes anywhere close to the project goal within a reasonable time. Very likely, psychological and sociological rules will dominate economic and business rules.
So we need a form of control to assure that a (final) configuration matches the project goal. Typically, there are two dimentions to control from a configuration management perspective: content and quality. By combining them into a single attribute, we come to value. A rule of nature is that a stronger species survives a weaker species. For configuration management, we can translate this in: a configuration of a higher value survives a configuration of a lower value.
To take this more in a practice way, we can say that a team (or an individual) that is degrading the product, the environment, the organization or any other of the 4+2 views, then the resulting configuration should be rejected by configuration management. Of course, project management would be wise to not even allow a team to spend time and effort on a degrading activity, but sometimes (for example, when prototyping to determine added value in an empirical way) a team result may produce a degraded configuration compared to what they started with.
Another example of a degraded (lower value) configuration may occur when two teams create a new configuration of a higher value than their initial configuration (which makes both configurations acceptable for configuration management), but joining results in some many issues that the joined configuration is of lesser value than the initial configuration. In that case, we have the option of accepting one of the configurations and reject the other one (in spite of its added value), or work on the degraded (joined) configuration to created enough added value so that the overall value is higher than the initial configuration.
The mechanisms of controlling configurations and streams in a strategic manner is what makes configuration management an interesting profession. This way branching strategies, workflow strategies, integration strategies, etcetera are born.