For the past two years I’ve been part of an Australian Government funded research team exploring the theme of Delivering Digital Architecture in Australia, investigating issues such as architect/engineer communication, data interoperability and lessons from parallel industries.

Early in the research we gathered information about data interoperability experiences from our staff and collated it into an Interoperability Database. This revealed some basic approaches to interoperability problems:

Use an import/export tool written by a software vendor.
Write your own tool to do the data transformation Depending on the particular tool, these approaches can be characterised as either a Scalpel or a Swiss army knife.

Scalpel A tool that links two particular pieces of software (e.g. GSA to Revit)

Pros:
• Specifically designed for the task, often giving the best results.
• Can be optimised to deal with cross-discipline or “geometry + analysis data” transfer.

Cons:
• Can limit the choice of design tools.
• Causes problems as the number of design tools increases.
• Some user written tools prove difficult to share with others.

Swiss Army knife A more general purpose approach, using an exchange file format such as IFC.

Pros:
• Generally industry funded, based on well designed and documented formats.
• Often provided by software vendors as a feature in their products.

Cons:
• Might not meet project data requirements, and may not be easily extendable.
• Currently best suited to “documentation/co-ordination” data rather than “design/analysis” data. As part of our research we are proposing a third possibility, which solves some of these problems but, as with any solution, also has its downsides.

The DesignLink Software Development Kit (SDK) – a meta tool for building tools.

The DesignLink SDK combines a data exchange format with the routines needed to read/write that data to various applications or file formats.

The DesignLink SDK can be used to build tools to solve interoperability problems as well as custom tools to use in the design process. It’s this ability to use the SDK as a platform for building custom design tools that sets it apart from other data exchange toolkits. Since these custom tools share some common DNA, it will be easier for programmers to share useful code. They also benefit from being built on a platform that includes:

• inbuilt testing routines
• easy methods for people to contribute ideas or code, without needing a degree in software development
• a community of programmers and users to review and improve the code

The types of tools that can be built with the SDK include programs to enable designers to connect parametric geometry models to engineering analysis models, allowing them to explore more design options; and custom written programs that perform design processes such as member size optimisation and design code checking.

We recently showcased DesignLink at SmartGeometry 2009 and I’m currently in the process of testing DesignLink on project and planning the next steps, which might involve Collaborative Licensing to further develop the SDK.