Architecture & Design editor Branko Miletic speaks to BVN’s Adam Hetherington, Australia’s foremost expert on the dRofus software platform.

The dRofus platform is a unique planning, data management and BIM collaboration tool that provides workflow support and access to building information throughout the building lifecycle.

You studied interior design, which is more artistic, and yet you've swung the other way to become a data scientist.

I guess it was the nature of interior design projects that I always took part in and I worked predominantly for companies that did not draw a line between interiors and architecture; they didn't really separate the strands, so I would find myself doing a lot of work traditionally assigned to architecture and I didn't really know any different. The type of projects that I worked on was always large and civic and complex – hospital redevelopments, science and teaching laboratories, the interior of a mortuary... It's not traditional, like picking cushions and rugs. In fact, I've never specified a rug in 15 years!

Can you tell me about the dRofus platform? What does it do, why do you think it's important and more importantly, what do you think is the future?

I've used a number of database platforms to design with, and I describe myself as a building design database manager. Regardless of whether it is dRofus, Revit or any other platform, the current leader is definitely dRofus. When people ask me to describe it, I usually start with asking them if they understand what Revit is. Revit is a three dimensional architectural modelling software. It’s like a virtual model of the constructed building, and dRofus is a virtual model of that virtual model.

So it's an important distinction to make because the building model in Revit or ArchiCAD is object-based. For a room to exist in the Revit model, you have to draw the walls and put the room in it, and the same with things like furniture or fittings or finishes to capture that information.

Just like Revit has rooms and furniture and finishes, so does dRofus – it has rooms that exist virtually that have the same name as the room that will be in Revit in the future, and it has perhaps a description of its function.

If you can capture all of that information outside of the model perhaps before even the model exists, it allows you to develop a much greater amount of detail for each space prior to anyone being able to draw the model or perhaps while the model is changing a lot. You can design rooms also by the type of room –before you even know how many meeting rooms are there in the building, you can capture what will be in the meeting rooms of various type and size.

Once the number of meeting rooms is decided, then you put that number in and apply the template to it, so immediately you're able to populate large amounts of building data about a particular room or room type. If you're working with object-based data and there are big changes, it can be a real problem; if you've got a room full of furniture in a building model, it's quite hard to push that around if someone decides that room is moving to level nine! Or that room is going to another department, or we need another five of those or three less and so on.

If someone decides to restack a hospital in a building 3D model, it can take a long time. I can restack a database model in a few minutes. It's just much quicker to manage that data, and you don't necessarily have to be able to see that item to know what it is. The real beauty of a database software like dRofus is that it links the virtual data to the real data using some kind of unique key, so the room in the database is linked directly to a room in the model and they synchronise and talk to each other. It’s a bidirectional workflow, where you can push and pull information between the building model and the dRofus database.

The same goes for every individual component and family and system family within that model, so they might be individual bits of FFE or services outlets or they might even be system families, like walls and ceilings and so on. You can control pretty much whatever you want – the mapping of the attributes between what's in the model and what's in the database; you can basically take one parameter in Revit and push it or pull it to an attribute in dRofus.

So it allows you greater amount of control over the model data, especially when you start tying in with facility management software, which really requires very consistent data in particular parameters within the 3D model. Linking to the database certainly puts your eggs into baskets as well. You can really put your hand on your heart and know that the data in the database is exactly what's in the model. Also by putting it in two places, it helps you look for glitches in the matrix; once you synchronise the data, you look for the bit that's different and that’s going to flag something that's not captured or linked, something that might be broken or incorrect. The synchronisation process is key to database management and being able to make sure that what you've got in the model matches with what you might be scheduling from the database.

What is the relationship between that and say, BIM?

There’s too much information required in a complex building environment such as a hospital to capture just in Revit. For instance, a particular guideline that people might be familiar with would be the Australasian Health Facility Guideline, and that guideline actually lives in a dRofus database. The AusHFG is a dRofus database; the data sheets are generated from the dRofus reporting module – they capture all of the standard components as templates in a dRofus database. They link that to a Revit model to produce the layout sheets associated with each of those data sheets.

Where has it been used and what difference has it made?

Well, dRofus is essentially a mandated software for use on any hospital project for health and construction in New South Wales, valued at more than a hundred million dollars. In New South Wales that has certainly created a bit of a quantum leap in dRofus knowledge and dRofus standardisation as well, because it is a very customisable software.

Essentially you can make it to what you want to but that can be a blessing and a curse – that great flexibility is fantastic but if one person goes from one door of this project to another, they might look vastly different. Where that information is kept and how it looks can have quite a bit of variation and people can struggle with it if the format changes too much.

The New South Wales Health and AusHFG having a dRofus template has established a bit of a nomenclature for how a dRofus database can and should be structured for capturing all the health projects. In terms of other types of projects that are using it a lot such as the big railway, stadium and airport projects in New South Wales, dRofus really comes into its own.

The new city fish market is a dRofus database and is using templates to capture existing rooms and using those existing room templates as the baseline for informing what is required for that space in the new building. You can really apply dRofus to any particular building type and typology, but it does lend itself particularly to buildings with large and complex FFE requirements as well as buildings for which you really need to capture a detailed written brief because, instead of a bunch of Excel schedules and folders with meeting minutes, you're actually capturing verifiable data.

So instead of writing in a list that this room needs five tables and twelve chairs, you capture that information into dRofus when you model that room. Because they are connected and linked, you click on the room and it's going to tell you – you've got six tables and you only need five, or you've got 15 double power outlets and you only need 12; it's actually verifying what you’ve promised the client is what you've delivered in the model and so it's actually going to be constructed.

Is this the future in terms of the built/ design environment?

I have often said that once the contractor starts cottoning onto the power of the database, they will be all over it like a rash. If you control the data, you control the building.

It’s the future – it's what health infrastructure is doing. When you start a New South Wales Health project, they give you the database, and it has got essentially all of the rooms that are assigned a template from the Health Facility Guideline. It's their library of components of what you can use and I see that will happen more in the future where I know if I was a contractor, I would want my database and I would control the items in it.

On some projects we find that it's the contractors who want to control the specification of a lot of the FFE, particularly, fixed fittings. They are actually in-putting that data so the designers are doing essentially what is a miniature performance based specification for each individual item in the room and then it's a mixture of the architect and contractor.

The dRofus platform allows you to capture all that information in one environment and attach certificates; you can attach images, or just basic make-model-finish and assign a lot of data to each individual item. All of that information is quite heavy but you just cannot capture it in the building model. So you've got this heavy item in dRofus laden with images, a PDF of the specification, and certificates about fire and slip, and it's directly linked to a modelled element in the building design. You know that item is drawn in the model but all of that heavy data associated with it doesn't need to live in the building model – it lives outside.

This is a cut-down version of the transcript of the podcast interview: Episode 18: Adam Hetherington from BVN is Australia’s foremost expert on the dRofus software platform…click here to go to this podcast.

Branko Miletic

Adam-Hetherington-from-BVN-reveals-the-secrets-1732065104.png

Let’s connect!