Information Exchange Projects
Information exchange projects define vendor-neutral, open-standards for the exchange of some specific type of project information. These exchanges are started and driven by subject matter experts like you who form project teams to solve specific information exchange problems. The critical task facing a team is to define clearly the information needed, at specific points in the project, for the team's problem to be solved. The design of a full solution will usually require information created upstream of when it needs to be exchanged. The team will map out the contract parties who create specific data at individual handover points. The specification of the exchange may also need to be phased to allow current software capabilities to provide partial solutions now and full solutions over time. Members of the team, beyond the initial set of subject matter experts, can assist in this process.
What is the output of an Information Exchange project?
Successful Information Exchange products will, when completed, provide (1) an IFC- and OmniClass-based definition of information to be exchanged, (1) contract language specifying the conditions under which this information may be exchanged, and (3) identification of public software that has is able to meet the appropriate contract specifications.
Who should to participate?
There are three kinds of individuals needed to complete such a project: (1) subject matter experts, (2) systems analysts, and (3) software engineers. Subject Matter Experts identify the scope of the problem, develop a process map that creates the needed information, and describes the content of the information to be exchanged. System analysts are invited to the group to document the process maps and exchange requirements. Software engineers will assist analysts to package the technical descriptions of these requirements into commercial software.
How do professional and trade associations participate?
Professional and trade associations are essential participants in Work Groups. Building Information Modeling (BIM) groups, of sufficiently well defined scopes, within associations may initiate Alliance project teams.
While the short-term work of the Alliance to create Information Exchanges are necessary, the long-term dissemination of best-practice that implement compliant products will correctly be the responsibility of professional and trade associations recognized as the authoritative sources for their segments of the capital facilities process.
In problem domains with multiple authoritative associations, Alliance Information Exchange projects can serve as a neutral "proving ground" for the creation of open standards serving all members requirements.
How to start?
When creating any engineered artifact, designers begin with a problem and list attributes and constraints derived from that specific problem statement. For example, when creating a new chair design machinists do not start by walking up to a band saw with a block of wood. Designers start the process by evaluating a specific type of seating need. From the formal documentation of those observations, identification of specific problems, and associated constraints a design for a new type of chair may be created. Only when the design is completed and prototyped, then the machinist is sent to the band saw with a specific set of design instructions.
The most efficient design of Information Exchange products follows the same design process as any other engineered artifact. First the problem is fully described. A problem description should specifically identify waste in the current information exchange process that will be eliminated if the project is fully implemented. Starting with the definition of the extent of the problem will serve as the motivating point for participation and allow a quantifiable validation of the results of the project. The problem statement is easily transformed into a business case.
Once the problem and significance are documented, and the team can begin to break down the business case into actionable components. This is accomplished through the creation of a series of flow charts. These charts illustrate how information is transferred during the relevant parts of the capital facilities life-cycle. The flow chart for Alliance projects should be produced using Business Process Modeling Notation (www.bpmn.org). The "swim-lane" diagram shows who creates what information and the timing of information exchanges during related processes. The team should be able to directly map the business case description into the swim lane diagram.
The swim lane diagram answers the "who" and "when" questions associated with the problem. The next step identifies the "what" required for the Information Exchange project. Each line in the swim lane diagram that crosses between different parties, or swim lanes, is a location where information is exchanged. At this stage of the process the team lists the commonly used professional and trade names of all data exchanged during each handover in the swim land diagram. As the team's effort progresses the set of data items that directly impact exchanges that can assist in resolution of the problem at hand can be collated.
During this process the focus must not be on the mapping of these exchange requirements to the IFC model or OmniClass. Premature focus on the details of the IFC model may result in incomplete exchange requirement definitions.
Following the complete identification of the stages of data exchange, and the requirements for information exchange by subject matter experts in the team, the mapping of these exchanges into the IFC model and OmniClass coding scheme are conducted. A critical function of the buildingSMART Alliance is to ensure that the mappings being accomplished by the team are complementary with mappings accomplished by other teams and with the world-wide International Alliance for Interoperability.
The IFC mapping creates the open definition of the data needed for the Information Exchange product specification. Mapping this "mini-IFC model" needed to solve the problem statement can be accomplished through a variety of means including: IFC Model View Definitions, ifcXML, ifcEXPRESS, spreadsheets, or other formats. These information exchange definitions, created by analysts and software engineers, are used by software manufacturers to exchange information. These definitions may also be used as the basis for contract language that requires the transfer of Information Exchange data as indicated by the "swim lane" diagram. Effective teams will include major software companies and parties responsible for writing contracts that will include the Information Exchange specifications.
Following a demonstration of software that implements the Information Exchange package, and demonstration of the results in one or more pilot projects, the team will be able to widely distribute and use their results. Depending on the nature of the standard and the constituencies involved, the team's efforts may be considered as part of the National Building Information Modeling Standard effort or as part of an International Alliance for Interoperability Model View Definition Project.
Information Exchange Projects
