One argument put forward for the use of databases, models and other data storage solutions is that we need a single source of the truth. The question that is not raised at this point is ‘What is the truth?’. We often want multiple versions of the truth. When I give data to a supplier, I might choose to withhold some facets of that data; reasons for decisions, cost expectations, future plans. As a supplier, I have to give data back to the customer, and again, I might choose to withhold some facets. This is all normal practice, and is generally handled by having an external facing set of information, and a more detailed internal facing set.
In a little lightbulb moment, I connected this problem of multiple sets of the truth, with the DOORS Next Generation configuration management capability.
If I have two streams, one for the internal facing information, and another for the external facing information, I can easily control the flow of information across the organizational boundary. Much of the content is common, which is why this can turn into a nightmare if not carefully managed. Common information is populated from a change set that can be delivered to both streams. Internal only, or, more rarely, external only, information is delivered only to one stream.
A single document does not live in isolation from the project and when we create a stream, it contains everything from the parent stream. This means that we don’t have a stream containing ‘just’ the document of interest. There are always multiple approaches to process, but in this case I would suggest that if the document is to be delivered in isolation then it would make sense to have a stream where only the export version is edited, and change sets can be delivered to the internal stream as necessary. Change sets updating related information can be delivered into the export stream to ensure that the context is maintained as up to date. If the external organization is to have access to the live database, then tighter controls on what is included in that stream will be necessary.
Links are primarily maintained in the appropriate stream as shown in the diagram.
Before embarking on any DNG config management set up, I would strongly encourage anyone to plan carefully, test in a sandbox, and be sure that you really understand what you are doing. A simple demo showing just a few modules is easily set up, but when the real world scope of a live project hits, you will find complexity. Even something as simple as the scenario described here, requires process and understanding. I showed a simple example of configuration management in a previous post, and while it should appear simple to the end users, there does need to be an advanced level of understanding of the tool in a small number of people to ensure that it is all set up correctly. The scenario described here might be a good starting point, as it can be much simpler than full on variant management or parallel development.