Versioning and practice-use requirements

In previous meetings Mike and I have discussed how the system would operate (along with a lengthy discussion about Google Maps/Earth). One import issue Mike brought up was the role of versioning and how that would play out in the system. I think at this point there is a distinction to draw between the IT/programming concept of 'versioning' and one an architect may hold. In programming versioning is the process of tracking changes from a given point in time based on a set of very clearly defined parameters.

Two common programming versioning systems are CVS and Subversion. I use Subversion on a daily basis with Eclipse (my Java IDE). The process of using a versioning system involves 'committing' code changes to the repository and at defined times (like a software release) creating 'braches' from the main development 'tree'. The versioning system does not keep multiple copies of files it simply tracks the changes to each file and dynamically builds files by adding together all the code changes. Such a system extremely useful, especially when working in groups as different pieces can be worked on simultaneously and then combined. Probably the most important aspect of the entire process is the unobtrusive nature of the versioning process from a developer's perspective. Committing a change is as simple as a right mouse button click yet the consequences are sophisticated and extremely useful.

 

From an architect's perspective versioning is a little different as the idea is more conceptual in practice and hardly ever grounds itself in a concise piece of 'code' (a single drawing/sketch). Some CAD packages do versioning based on parametric conditions or the notion of time, but as far as versioning across an entire project, manual methods are still the main form of versioning. Online project Intranets are trying to address this issue but because of the buy-in and major working changes required to use a project intranet these services have not gained major acceptance.

For the most part the practical realities of creating a true 'versioned' design model are beyond the reach of all but a few of the most anally retentive architects. In most offices I have been associated with digital versioning typically consists of creating a new file when a major change is about to take place or going back to a backup if a change occurs that cannot be easily 'undone' using the software.

So in my proposed system one of the designers asks the question, 'when was the door moved from A to B and why?' how will this search, and the information related to it, be displayed?
This question is essential to answer but difficult to solve and poses a conceptual versioning dilemma. In in the context of a design project a whole series of design moves could be made in a single 'version' of the design. Two CAD models produced at different times may provide evidence of the elemental shift but it probably would not narrow down the date of when this change occurred or more importantly why. To identify the when and why you would first need to know who made the decision to move the door, what discussions led to this decision and when in the design development stage was this decision implemented and whether subsequent design moves influenced this shift.
When searching for these answers you would probably be asking the following questions and receiving these hypothetical responses:

1. What is the design history of this door?

Whilst not specific you generally begin a broad search and then narrow it down from there. More often than not when using any search engine (be it Google or your local file search tool) your initial search attempt is a test of the water rather than a precisely focused search statement. In the case of the door it is problematic to search within CAD models themselves as doors are typically only represented by a series of lines. In a Building Information Model it could be possible to search within the document to find a specific door instance but achieving this in todays mixed AutoCAD/Revit/ArchiCAD/Microstation environment would be problematic and probably lead to inconsistent results.
So as far as searching for the door's history we would be limited to meta-data tags and written documentation (in the form of notes, briefing documents, etc).

Another avenue for locating information could follow the use of project plans and work diaries. Given enough chronological information about the project as far as when things were done by whom it could be possible to extend the usefulness of any search by identifying useful pieces of information. This brings to question exactly how often data should be entered into the system. Just like in computer software versioning the system is only as good as the data it receives. If you fail to frequently commit your changes to the versioning system your chronological view of the model will be very weak. Hence the versioning process in this system would need to take place as frequently as possible (whenever information is exchanged, important decisions are met or at the close of the business day).

2. When did the move from A to B take place?

If the general search for the history of the door door in question returns a large number of results (from material options to recorded notes on design options sent to the client by the architect) the next phase in the search would be the isolation of when the actual move took place. The most efficient manner to do this would be a narrowing of the search based on the tag 'design decision' (or equivalent as setup within the project). This tag would be applied to any correspondence or work logs submitted that related to instances where specific design decisions were made. The highlighted results viewed against a project timeline would highlight when design decisions related to doors occurred. It would be at this point when the user would use their own intuition based on their personal insights and knowledge of the project to zoom in on a specific time zone within the project where it was thought the door was probably moved (based on the displayed information).
This move is very similar to how we interact with current search engines of all kinds. The greatest difference is that we view and evaluate these results against the chronological project canvas.

3. Who moved the door?

Now that we have narrowed down the time frame as to when the door was moved it is important to understand who were the parties involved in the decision making process. Was this an action performed individually for no reason or did it occur against the backdrop of a number of different but inter-related issues that are important to keep in mind?

4. Why was the door moved?

Understanding this question will require extracting a subset of the conversations and logs placed by the person responsible for moving the door. By examining their activity before and after the activity we would soon identify whether this was a requested planned action, a spur of the moment decision or an action brought on by a chain of events unassociated to the door itself. Situations like this often occur when a design change results in the repositioning of a spacial element which in turn forces the door move (through no fault of its own).

5. Subsequent to this discussion, what other (if any) influences effected the placement of the door?

This investigation of the moving of the door may reveal discussion threads indirectly associated with the door's repositioning. In order to identify this a broad cross section of the conversation would need to be extracted and browsed based on the time frame, participants and project tags associated to the repositioning of the door element.

What would make users buy into this increased data entry requirement?

I believe architects would be willing to invest their time in such an endevour if it was proven that it satisfied a number of their ongoing concerns about working digitally. By itself the system would be useful but the added burden would stunt, if not destroy any chance of widespread adoption. There are a number of small areas where architecture practitioners must pay particular attention to that large software vendors do not properly address. From my experience acting as a consultant in this environment these 'gaps' can be broken into four different groups:
a.) Taking care of the data backup process
b.) Time tracking based on task/project particulars for a specific person
c.) Finding things they or others have worked on in the past
d.) Enable simple sharing between people in their team and other parties

These issues are presently tackled in a number of ways and usually involve customised manual processes that have evolved within each particular office. For example:

a.) Taking care of the data backup process

All companies are deeply concerned about loosing their data. There is the time cost involved in loosing past work but also the prestige and moral hit that takes place when hours of blood sweat and tears suddenly disappear. This is especially important when other parties depend on the data you are providing to undertake work. Just recently I had an experience where an architecture practice lost a few files and they could not be recovered. The flow on effects for this loss where huge. A team of builders could not work, other projects were delayed and office moral took a dive as hundreds of hours of work had to be redone under stressful circumstances.

Probably the most surprising thing however is that architects still do not value their data enough (until it is lost). For many the idea of creating frequent, multiple offsite backups of their work is just too much effort when a single, weekly backup protects them on a week by week basis. If a system like the one proposed were to exist then backups of critical data would occur automatically as changes were logged or information exchanged between groups. Not only this but as more parties joined the project the backup integrity would increase as multiple copies of the same file propagated itself through the network.

b.) Time tracking based on task/project particulars for a specific person

Tracking what time was spent on which tasks by who is crucial for architecture practices. Not only is it required for paying employees but also tracking chargeable hours and assisting in the quoting of new jobs. There are numerous applications available for time tracking, especially for the legal arena but none have been universally adopted by architects (in fact in this field a simple Excel spreadsheet is a popular option). If the system logged time spent on projects as users committed work to the project this information would be silently recorded by the system for later analysis. Not only would it provide immediate benefits in staff and charge out tracking but over the long-term it would provide a resource for comparing past projects to future estimates.

c.) Finding things others have worked on in the past

Information reuse within any office is typically very low. Due to the sheer quantity of information present within a single project it is often easier to reinvent a solution rather than track down past work on a crowded disk archive. As more materials and accepted solutions libraries are put in digital format the architects physical reference library is shrinking yet their capacity to easily find digital information available to them still depends almost entirely on an up to date and comprehensible digital filing system. Desktop search tools like Spotlight and Beagle acknowledge this problem and are attempting to provide general search functionality to desktops around the world. Unfortunately the functionality provided by any of these general search engines fall well below that required in an architecture specific context as no matter how evolved these tools become they will never understand AEC semantics.

If the tool provided this ability to easily search a project or projects information base for a set of constraints old solutions could potentially be rediscovered and utilized on current problems.

d.) Enable simple sharing between people in their team and other parties

Although file sharing has been around since the beginning of computers it is still difficult. Presently project files are exchanged either physically (on CD/USB) or using the Internet (via email). Within an office often the option exists to share files live via the local network but this is problematic in small offices due to the lack of IT knowledge available and various intricacies that still exist in the process itself.

Exchanging files using email or physical means results in a 'frozen' version of the file that does not keep pace with changes made by either party. In this scenario we do not want others to have direct ability to change our files (or even see our in-process version). What we do need to be able easily do is easily notify users of a particular file that it is now considered out of date and for what reasons.

Consider the following example, I email a development drawing to a quantity surveyor and building services engineer for estimation and simulation. The quantity surveyor's feedback results in the design undergoing a series of changes. Once these design changes are finalized a simple mechanism is required to notify the quantity surveyor, building scientist and any other related parties of the design change otherwise there is the potential (as so often happens) that third party work will be completed using outdated data. In computer programming such a concept is known as a 'thread-safe architecture'. Basically it boils down to establishing a common communication layer between all actions so that everyone is always on the same page.

Part of the file sharing process also requires a communication of assumptions, standards and conventions associated with a file. When emailing data, especially to people outside your work group these factors play a crucial role in not only determining what the data is but also play a role in the eventual outputs from this third party. In a conventional AutoCAD file the semantics behind CAD layers and XREF management are vital to understand but more importantly in an estimation or simulation context other users must be aware of assumptions, shortcuts and operating logic associated to the working data. In these scenarios the raw data (an Excel sheet, 3D walkthrough or still image) is only the first clue to the puzzle, understanding the logic behind this data and how it fits into the bigger picture is very (if not more) important.