AECbytes Viewpoint #52 (May 3, 2010)
Collaborating in the New AEC World
President, A.D Douglas Associates
It’s not news that the AEC industry is undergoing technological and methodological changes like never before. The industry has been in this process of change for the past ten years, with the heat on the burner turned to high over the past 2-3 years. This shift is driven by the need to become more productive and cost-effective in the design-build processes. It is going to take time, and owners, architects, engineers and constructors are adapting at different levels and timelines.
In preparation for writing this article, I asked key people from each of these disciplines their opinion on what the future will look like. None were exactly the same, including their opinions on how long this period of change will take to solidify. Some say a couple of years; others think it will be more like ten years. The discussions also taught me that when the subject of collaboration comes up, the same people had slightly differing views on exactly what that meant because all have differing roles in the delivery of a project.
The main vehicles delivering this change are BIM, IPD and a developing open standard called COBie. This article is not specifically about these new ways of working. There are a multitude of very good articles on each of these subjects, with a good number of them published right here in AECbytes. Rather, it is to zero in on an important component that is required to make them effective. That component is content management and the collaborative role it plays in the lifecycle of a building.
The content I am referring to is the entire mass of documents related to the project that impact the contracting, design through to construction, and closeout. Even though new technologies are changing the workflow, 2D CAD drawings are still being created from the models along with specifications needed to deliver contract documents during the Bid and Construction stages. This and other project content takes on a life and that needs to be managed throughout the entire lifecycle of the building. It also has two states, shared and private.
This content includes but is not necessarily limited to:
- Contracts: Contracts between the owner and the architect, general contractor, project manager, etc.
- Project Communications: General communications, meeting notices, agendas, meeting minutes, requests for information, etc.
- Design Documents: Conceptual design, BIM models, presentation renderings, etc.
- Procurement Documents: Documents issued for bidding or negotiating before signing of an agreement.
- Contract Documents: Documents that describe the work of the project.
- Resource Documents: Documents that show existing conditions, or new construction related to the work, but are not included in the contract.
- Submittal Documents: Contractor submittals, subcontractor submittals (insurance certificates, bonding documents, product sheets, shop drawings, etc).
- Construction Site Related Documents: Health and safety, accident reports, site photographs, etc.
- Addenda and Modification Documents: Collectively known as Supplemental Documents.
- Closeout Documents: Documents of record.
Enterprise Content Management Technology
The management, sharing, and distribution of all this data can be better accomplished when there is a nucleus for this information that is put in place at the very beginning of the project and employed throughout all phases. In Information Technology terms, this is called Enterprise Content Management (ECM). With it, collaboration will be connected, streamlined and effective in the task of improving productivity and reducing costs.
Applying ECM technology to a project brings, first and foremost, content collaboration but also accountability, central storage of all project related documentation, contract document workflow, and assists greatly in bringing interoperability to the many software tools used throughout the project.
Today’s ECM systems are web-enabled and database driven. They provide role-based user access, document viewing/downloading, threaded comments, document-comment association, checkout and check in (file-locking), revision and version tracking, individual document history (who-what-where-when-why), event scheduling and alerting, distribution history and very high security. The database I refer to will hold all project related metadata, no matter its purpose or origin. It is not to be confused with the one attached to your BIM model. That is a structure designed for a specific purpose by a software company and is usually proprietary. It is not the IFC schema either, although IFC does play a part in the BIM and COBie collaborative processes.
What makes ECM so powerful is the metadata associated to the attributes in the database—in other words, the ability to search on and find information relating to very specific tasks, documents, issues, distributions, bids, submittals, notifications, revisions, versions and so on. Collaboration, after all, is not simply communicating about a subject—it is the act of sharing data regarding a subject that you are communicating about. Collaboration is aided through AEC specific tools added to the system, such as project contact management, group distribution, notification, event timers, workflow modules, bid and submittal management modules, plan holders lists, reporting, forms management and print management.
ECM Systems Infrastructure
Content management systems have been around as long as computers have, in one form or another. Mainstream systems began to develop in the mid-nineties and governments and big business were relatively quick to jump on board to get their mountains of documents in order. The systems have proven themselves over time and have had significant impact with regard to regulatory requirements demanded by governments in business sectors such as health care, pharmaceuticals, chemicals and manufacturing. With the introduction of the Sarbanes-Oxley Act in 2002, public corporations have been quick to realize the benefits of ECM in the requirement to comply with the law.
Since around 2001, this experience has been flowing into the AEC community with many systems that have been designed specifically to work in this industry. Some are very good and some are not so good. Some make claims that they cannot support, others do exactly what they say they will do. It is very important to do your homework when deciding on a system because it should be looked at as a long-term engagement and not a project-by-project implementation. In other words, the same system should be used for every project. The reason for this long term relationship is obvious—training and the adoption by the team. These systems are complex with regard to backend implementation. You will need to develop a naming convention, document management structure, and customize the system to a degree to work for you. The customizations will apply to such things as notification templates, forms, attributes and so on. Once the system is in place and customized, it can be used for every project, no matter the size; also, people using the system will become familiar with its look and feel and are more likely to accept it as an everyday part of their workflow.
The simplified graphic shown below illustrates a typical content management system infrastructure consisting of an application server, web server (sometimes the same server is used for both), a database server, disk array (vault), and a firewall device. The ECM application will have the ability to hook to your mail server or may have its own. The costs associated with maintaining this are continuous with regard to software licences and the increased need for storage as more projects are added. Systems today offer both local and web client access. The local client is usually downloaded from the site as needed, managed through the distribution of a URL. This client, sometimes referred to as a “thick” client, is an application that you install on your local machine to access the system. These usually provide much more capability over the web interface and are sometimes integrated with your local file system.
ECM and your BIM Model
This is an important topic and I provide a general description, which does not necessarily apply to all modeling software applications, so please don’t tar and feather me! One of the hot topics I read about and see discussed in User Group forums is “sharing the model” to people outside their network. Most BIM modeling software applications (not IFC based systems) are designed to be installed and managed in a TCP/IP based local or wide area network where read/write access to the file is routed directly. Some people are using Windows Remote Desktop or a VPN tunnel to provide “real-time” access to the model so that updates are done directly to the same model file opened. People using this type of access are still required to be “inside” the network. This is in tune with the way the software is designed to work. Some of the modeling software companies provide specific management tools for this and some are further ahead than others in expanding this to the Internet. The challenge here is that Internet protocols are different than what is used on your network and therefore file access is handled differently. This affects the ability to update the model and speed becomes a problem, which is where your high-speed bandwidth comes into play. Anyone who has opened a 100Mb model across the Internet directly in the application that created it knows the latency involved. Even IFC model servers that are designed to share data in this manner experience this.
It is important to convey some important points to those who are confused about this. If you are working with modeling software that creates a single file, you can upload your model to a content management system to share it, but you cannot expect to provide direct write [update] access to the file to many people at the same time. Access is provided through the database and although more than one person can open a model file directly from an ECM system at the same time (if the software that created the model is installed locally and associated to the file extension), when pulling it down through the Internet a temporary file of the model is created on the local hard drive as a “working copy.” The model software now sees this as the current model file, so that when you change the model, the copy on the hard drive is the one that gets updated, not the one you opened. You could then take that updated copy and upload it into the ECM system. However, if other people are working on the model you originally opened, you would end up with several copies with different information, the exact opposite of how BIM modeling is designed to work.
To go one step further, if the companies that create the modeling software provided a means of linking their [model] database through a standard such as ODBC, then direct access to that database could be accomplished. Technically, it is not as simple as it may seem, and over and beyond that, the individual vendors may not be willing to risk doing this as it could affect their market share—users would not necessarily have to buy their specific application to open and work on the model. Thus, it is likely that we will continue to have proprietary data structures in the foreseeable future, and these create the biggest challenge to interoperability.
Certain companies are making great strides in overcoming this limitation, which will greatly enhance the ability to truly collaborate on a model despite your geographical location. This does not mean that you will be able to open and work on a Company A’s model with Company B’s application and vice versa.
With all of this in mind, the ECM system does have a role to play with regard to BIM modeling. Revisions (and versions thereof) of the model can be uploaded to the system for the purpose of tracking the different stages that the model goes through. By doing this, an audit trail with time, date and access is tracked for record. These versions of the model can then be shared with people in a read-only state for reference. You certainly don’t want people updating an old version of a model that is not regarded as current.
Selecting an ECM System
Hopefully this gives a bit more insight to the power of an ECM system and the role it can play in collaboration. Here is a list of things to keep in mind when researching a system:
- Does the company understand your business to be able to support your needs?
- How many companies currently use the system and who are they?
- What business sector did the system grow-up in? AEC is good, while Pharmaceuticals, Accounting, Manufacturing are not so good.
- Does the software have the features required to properly enable your team to collaborate throughout the entire project?
- Does the vendor have excellent user documentation and training? (This is extremely important.)
- Does the software perform as specified in their marketing? Is a trial period available?
- Is the system both Web and Client enabled?
- Is the system available through Cloud computing (which can offer tremendous cost savings) and if so, is the hosting service security certified and reputable?
- How long has the company offering the system been in business?
- Will the company be around a year from now?
The decision of whether to buy, install and manage the infrastructure of an ECM or whether to subscribe to a service depends on your IT capabilities and the size of your company. Today’s hosted systems that users subscribe to are becoming more prevalent and can offer huge cost savings over owned systems and the good ones are very secure. Whatever system is employed, it is important to “play in it” first if you can. Get a feel for the interface, features and functionality to determine whether or not it has what it takes to tackle the types of projects you are involved in. Most importantly, talk to companies that are using the system now and get their feed back. You’ll get the most honest opinions that way.
Now comes the question of who should own (pay for) the system. My experience has witnessed this as one of the biggest stumbling blocks in the adoption of this technology over the years that I have been involved. I could write an entire article on this subject alone. Suffice to say that prior to the recent upsurge in the adoption of BIM, the different disciplines involved felt they were isolated in the way they manage their own data and that FTP and Email was all they needed in order to collaborate. Those days are over with BIM and IPD becoming more mainstream. A more streamlined approach to achieving higher productivity in a highly collaborative environment with all parties involved will be the engine of change.
This naturally points to the owners to be advocates, as they will benefit the most by its implementation because upon commissioning of the building the data can then be used during the entire lifecycle of the building. This is where COBie comes in. I want to touch on COBie because there are not a great number of articles about it and during my discussions only two people were apparently aware of it.
Construction Operations Building Information Exchange (COBie and COBie2) is a developing open standard to address the following:
- An open standards specification to provide a format to publish a subset of a building model regardless of project type.
- Interaction between this specification format and the IFC is critical to improvements in lifecycle management.
- Information is stored in this format by the various members involved in a project as design, preconstruction, construction and commissioning progress to the close-out phase.
- The information is delivered as part of the closeout to ensure the owner has all the building information as it relates to “as-built.”
- The greatest value of COBie is to the Owner as the data collected will be used in computer aided facilities management systems (CAFM) throughout the entire lifecycle of the building.
- To acquire a complete set of data, it must be gathered from the design stage and the process adhered to all the way through to close-out.
Collaborative effort is required to compile and store COBie/COBie2 data because it is generated and gathered either manually or from a properly structured BIM model by many different people throughout the design, construct, and commission and closeout phases. The associated data can be stored in a COBie spreadsheet or exported as IFC data. This information should be stored in the ECM system because many different people are generating it over time and it can become very difficult to compile at a later date. For more information on COBie and COBie2, go to the National Institute of Building Sciences web site: http://www.wbdg.org/resources/cobie.php
As the adoption rate of BIM and IPD grows, the need to collaborate more effectively will naturally increase. This in turn will put more demand on access to information and digital approval processes. It is with IPD that the biggest productivity gains will be realized and even more so, with a strong content collaborative environment.
About the Author
Al Douglas is President of A.D Douglas Associates, a private consulting firm in Kanata, Ontario Canada. He has been involved in the AEC industry since 1972 in a number of roles, the past 15 of which have been around content management implementation and administration, document management, data repurposing, and workflow design.
Note: The views expressed in Viewpoint articles
are those of the individual authors and do not
necessarily reflect those of AECbytes. Also, AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.
Have comments or feedback on this article?
Visit its AECbytes
blog posting to share them with other readers
or see what others have to say.
> Issue #52 > Printer-friendly