Wouldn’t life be simpler if all software packages used a universal document management system? John Evans sets out his challenge to the industry’s suppliers.
At Lawray Architects, we use NBS Chorus for specifications (using Uniclass 2015 clauses) along with the NBS Plugin for Revit. We are trying to encourage the NBS developers to finish off NBS Tools, especially the sub-sections covering BIM Level of Development/Level of Information (LoD/LoI) and the associated diagrams therein that could form a universal standard ‘Working Drawings Handbook’ for drawings, modelling content and presentation at different LoDs/LoIs and RIBA work stages.
I’d like Autodesk to get involved here, as it did when it published and backed the long-ago AutoCAD layer schema standard that was also driven by the AEC (UK) group. NBS Chorus is great, and we have been doing a lot of work in this area to develop processes and procedures that really improve the specification process and integration with Revit and downstream operations. It’s excellent how we can have the Revit model and the NBS specification on screen and each database fully integrated at the same time. However, Chorus has its own data store – and here is my point(s)…
One of my big bugbears with cloud technologies is the way each solution comes (naturally) with its own document management system (DMS) or ‘Docs’. In pre-cloud days, we only had our on-premises file server estate under Windows. We only had one DMS (Windows File Explorer – a hierarchical database). Everything was simple, if dumb metadata-wise. All project data could be hosted in one place and if we made sure we had on-premises backup and disaster recovery solutions in place, everything was straightforward.
Then we incorporated cloud backup and cloud disaster recovery as an additional safety net and developed better security solutions for our Cyber Essentials certification. This was our first tentative step to the cloud itself. Now we are using more cloud solutions and our project data is getting dispersed across multiple cloud solutions and their data stores.
“As software developers all build their products on top of Microsoft’s foundation products, surely it’s not beyond the capability of developers to pull together to get a unified ‘Docs’ solution incorporated into the operating system?”
Currently we are using MS Teams/SharePoint, NBS Chorus/Tools and Autodesk BIM 360 Docs data stores – just three solutions (not to mention the plethora of extranets and things like OneDrive, Dropbox, etc), and our traditional Windows file server estate. The problem is the DMS solutions don’t all recognise all the file types we use, which Windows does by default. So, we cannot establish a ‘one-stop shop’ work-in-progress solution to replace our on-premises file server estate. Additionally, each developer has created vertical solutions that sit on top of and are integrated with their DMS.
Another area where information is lacking is backup and disaster recovery of these DMS solutions despite their service level agreements of 99.9999% uptime. I believe ArchiveHub from Matterlab is a complete archiving solution for BIM 360 users to access a complete offline, local version of their BIM 360 data. But you will still need somewhere to put that archive.
But I digress. I want to get back to a single back-end data store for everything again: or in BIM-speak, a single common data environment. That means each developer must collaborate in establishing such a solution that they all contribute to, develop, and buy in to.
As the software developers all build their products on top of Microsoft’s foundation products, surely it’s not beyond the capability of developers to pull together to get a unified ‘Docs’ solution incorporated into the OS rather than separately develop their own DMSs that all do the “same thing but different”? As a customer of such solutions, this is a fundamental I’d very much like resolved.
It makes absolute sense to me as a customer/user of these products for a ‘Docs’ solution to reside in the OS not in the vertical product or product line of each developer, but I know that is unlikely. This needs to be resolved before too many customers find their data gets locked into separate DMS solutions, which is already happening and has proved problematic for some employer clients (with some notable legal consequences).
IT administration has increased, not decreased, due to the different data stores and permissions structures in each cloud solution. I certainly find it a pain having to manage multiple solutions, multiple user access and multiple user permissions across these different solutions. Even if such IT administration is delegated to trusted employees, if you can use Active Directory Services, it is a very big IT overhead. And that’s just in-house: it becomes more onerous when third parties need secure access to project data.
Autodesk presentation images show Docs as a mid-level solution on top of which are the vertical product modules and below which are Microsoft’s foundation products. I’d like to see a Docs (DMS) that resides below the developer’s verticals and sits with Microsoft instead. One which Teams, BIM Collaborate Pro, NBS Chorus/Tools, MS OneDrive/Teams and Adobe Creative Cloud use as their ‘Docs’ foundation.
“IT administration has increased, not decreased, due to the different data stores and permissions structures in each cloud solution.”
Some might say MS already has such a DMS in the form of SharePoint. But my idea is it should be a neutral (open) format baseline on top of which verticals can be built (Revit Collaboration, NBS Chorus, etc.) and additional modules could also be built at the Docs level (version control, file viewers and so on), with user membership and permissions controlled across all the verticals (MS, Autodesk, NBS, Adobe, etc), so I have a single administration portal to build the ‘at desktop’ (or in terms of our agile working abilities ‘at laptop’) per user solution.
This should include a pick-and-mix metaphor for the application software (AutoCAD, Revit, NBS Chorus, Teams, Acrobat Pro, InDesign, Photoshop, etc) where I can create individual software portfolios tailored to a user’s needs or what I’m willing to spend per user, rather than having to purchase product suites, most of which applications therein never get used.
Finally, licence payment should be based on a pay-as-you-go basis, with suitable admin portal tracking tools so I can track (by username/email address, not just an obscure user ID number – and no, developers should not hide behind GDPR as an excuse not to enable administrators to track usage by user name/email address), how much time (and cost) a user is spending per application. This would enable me to flex licence usage and costs per user and so reduce our licence cost burden. For it is our software cost, as well as the disparate data repositories that are getting out of hand now.
John Evans is BIM manager at Lawray Architects.
Don’t miss out on BIM and digital construction news: sign up to receive the BIMplus newsletter.
