New guidance from Wren Insurance on “cloud technology” seems pessimistic and even outdated. In this post, I take a detailed look at how construction collaboration technology vendors have, since 2000, responded to similar objections.
Legal issues of collaboration
In 2004, David Whitton of Wren Insurance, one of the UK construction industry’s leading providers of professional indemnity insurance cover to architects and other professional practices, helped me with some guidance on an outline clause for a firm’s conditions of appointment. As one might expect from an insurance business, the clause limited the liabilities of a consultant in the event that a third party-hosted collaboration system mandated by the client malfunctioned; it also insisted on the client maintaining free access to the system during the project, and for at least 15 years after practical completion.
I included David’s guidance in my book (p.113) in a section on legal issues of collaboration where I urged both customers and end-users to look carefully at the conditions contained in Master Licence Agreements, End User Licence Agreements and Service Level Agreements with Software-as-a-Service (SaaS) construction collaboration technology providers.
Wren guidance on ‘cloud technology’
A friend has just passed me some new guidance issued by Wren to its customers on “cloud technology”. Most of the potential risks are discussed in my book, but there are some notes that – to me, at least – seem unduly pessimistic (but maybe, if I was in insurance, I would always tend to think the worst?) or outdated. Of course, they may also relate to other cloud-based services that Wren’s customers might use (eg: cloud-based customer relationship management, HR tools, web conferencing, invoicing, email, etc), but I thought it worth providing a commentary on the points made – at least from the perspective of SaaS-based collaboration for architects, engineers and other construction (AEC) professionals.
- Your relationship with the provider will be governed by a Service Level Agreement (SLA) which is often on onerous terms. – Of course, it will be onerous, but that cuts both ways. The customer should look carefully at what is specified in the SLA; the vendor must be able to deliver reassurances on key requirements: security, back-up, functionality, audit trail, speed of access, system availability, software upgrades, customer support, training, etc. If the balance of responsibilities is wrong, then the customer should seek to vary the SLA or find an alternative vendor whose SLA is more appropriate.
- The level of data security is dependent on that set by the provider. – But end-users will also need to remember their own data security obligations, like not sharing passwords or logins, and virus-checking files, etc.
- The storage is likely to be shared with a number of users so its performance can be adversely affected by peaks in demand caused by others. – This will depend on the hosting regime. Where vendors are sharing servers, then the performance of their service can be impacted, but the more sophisticated vendors provide services accessed from dedicated servers that are carefully monitored 24/7, with hardware upgrades programmed to anticipate any future load issues.
- Data held on such sites may not meet the requirements for legal admissibility. – This has been a recurring theme since the earliest days of construction collaboration software, and vendors such as BIW and Cadweb have made PR capital out of their hosting compliance with information management security standards, eg: ITIL, ISO/IEC27001, which would be persuasive to a court of law in considering admissibility.
- Personal data may not be held in accordance with the requirements of the Data Protection Act…. – As far as construction collaboration platforms are concerned, only limited information about individuals is retained (normally just that required to identify an individual and to help other authorised team members make contact). Vendors should be registered under the DPA and ensure any collection and use of personal information is lawful and fair.
- You would be totally reliant on your internet connections to the provider. – With email and other internet-based services in constant use, there are few construction businesses today where communications are not reliant upon an internet connection. In most cases, SaaS providers will have significantly more resilient and faster internet connections (and often multiple connections) than those used by end-user companies – often grumbles about slow or intermittent access to a SaaS service can be traced to issues related to the end-user’s (single) connection to the internet or the local area network (inadequate bandwidth, high contention ratio, traffic slowed by fire-wall tools, etc).
- You could be subject to providers temporarily curtailing access to your data or closing their operations for financial or legal reasons, possibly without warning. – It pays to be diligent in making initial enquiries and then to monitor the circumstances of vendors; technical prowess will still need to be backed by sound finances and stable management systems (including insurance). Responsible vendors will also provide reassurance through detailed provisions regarding system back-up in case of interruption, plus undertakings on data export, software escrow agreements, and contingency arrangements whereby hosting providers will maintain the service for a minimum period even if the software vendor goes bust, allowing customers to find an alternative provider without loss of service.
- The provider could suspend your service because one of your employees has breached the terms and conditions of operation stated in the SLA, e.g. through inappropriate internet usage. – Not just a reason to be wary of SaaS, but also a reason to ensure staff are well trained and are aware of company guidelines regarding appropriate use of the firm’s IT.
- The provider may be operating under another legal jurisdiction. – This was a particular factor in the early days of UK construction collaboration, with several US-hosted systems seeking to claim a share of the European market. However, the main UK provider all hosted their software and associated data in UK-based data centres, though as they have expanded operations overseas, several have opened new hosting facilities in other locations to serve those markets.
Wren still suggests that its members should provide back-up archives on systems under their own control. In my experience, many design firms already maintain good offline systems to manage their project inputs, though they may also take advantage of the archive services delivered by collaboration vendors (eg: from periodic ‘snapshots’ to full end-of-project archives, delivering all the information that the firm had access to, along with the tools needed to access it, via standard hard disk drives). Mind you, if these same businesses are also using cloud-based tools for other purposes, do their vendors offer the same kind of back-up regimes? And having in-house back-up systems is no guarantee either; IT equipment can be stolen in burglaries, and software and hardware can quickly become outdated.
Progress
I regularly talk to university graduates about adoption of collaboration technologies (I lectured to MSc groups at Loughborough and Nottingham Trent universities so far this autumn, for example), and a recurring theme is how construction people who are resistant to the idea of collaboration have used legal or technological issues as a reason to avoid SaaS-based technologies – and Wren’s risk-averse stance regarding cloud computing seems to be along similar lines. It doesn’t seem to recognise that over the past decade there has been great progress in tackling some of the actual and perceived risks of online services.
As I’ve tried to make clear above, since 2000 construction collaboration technology vendors have accumulated considerable knowledge and expertise in meeting such objections – often focused more on people and processes than on the technologies. In short, effective commercial use of SaaS-based collaboration is not about the Software, it’s much more about the Service. Providers, customers, end-users, and their insurers, need to engage in an open and honest dialogue recognising their respective roles and responsibilities, and to understand and incorporate the latest thinking on SaaS delivery.
Updates (26 November, 1 December 2010, 8 June 2011): To be fair to Wren, some vendors also like to play what one commenter dubbed the fear, uncertainty and doubt (FUD) card. BIW did it earlier this autumn (see BIW pushes its low-risk message) with an article in ABC&D, and it has repeated the message in a similar piece, bylined to CEO Colin Smith, in Construction Industry News (not, I have to confess, a publication I have ever seen), with similar sentiments expressed online in a Construction Digital article, and on the BCS website.
1 comment
Very good! I cited this blog in an essay on “extranets and cybersecurity” but which I wanted to take more into the territory of KM meets CSEC. I wrote the paraphrase even before I found your blog to support my position 🙂