Integration and Integrity
It would take a particular type of pessimist to embark on a new project expecting it to fail completely – but a truly foolish level of optimism not to even consider the possibility of problems, and make sensible provision for how to handle them.
The complexity of enterprise-scale IT infrastructure means that any project involving it needs to carefully consider the myriad slings and arrows of outrageous fortune that could affect them. When whole new systems are to be added, many organisations may not have the necessary expertise or available workforce to undertake the project, and will look to specialist third party systems integrators (SIs) to provide assistance.
The implementation and integration phase will inevitably involve change, disruption and the potential for disputes… but exactly how serious those disputes are, and the options when they arise, change dramatically when the system being implemented includes both hardware and software.
Duplication and Duplicity
Over the last two decades, the ubiquity of server infrastructure based on x86 CPUs (whether on premise or in the cloud) has meant that most Systems Integration projects have been software-only. Classic examples might include a new Enterprise Resource Planning (ERP) system, implementation of new core business software or the replacement of a business-critical platform.
Very often the licensor of the system will not be the same entity as the SI. The licensor and SI might be entirely unconnected, but it is also not uncommon for the SI to be a value-added reseller or distribution partner for the relevant licensor. In order for the project to begin, the customer will need to be licensed to use the relevant software, and this inevitably begs the question of when the customer is obliged to pay for the licence to use the software. Whilst the parties could agree almost anything, in general:
- the licensor will want payment up front – as it will not wish to take any portion of risk that the system is not implemented to the customer’s satisfaction; conversely
- the customer will only want to pay after the system has been implemented and passed a battery of acceptance tests, in order to ensure it is paying for a system it can use.
The SI tends to be caught between these two positions. If there is a close connection between SI and licensor, it may be possible for the SI to arrange a period of free use of the software until implementation and testing are complete. More commonly, the customer might end up taking a licence for a smaller number of servers / users / transactions or other chargeable unit for a ‘proof of concept’ or DevTest environment, with the remainder of the licences to be purchased after successful acceptance testing. In this latter case, in effect the customer expects to have some sort of wasted costs’ component for the licence fees within any damages claim for breach of contract it might bring against the SI if implementation is not successfully completed.
Whilst the latter arrangement (licensing for a proof of concept phase) tends to be more common, it is interesting to consider why that first option is available at all. Recall that we’re dealing with a software licence, and the marginal cost of creating an additional copy of existing software is essentially zero. Therefore arguably the licensor can agree to allow ‘free’ use of the software during an integration project because it has suffered no real cost in doing so. Only if the SI or customer relies heavily on support or hosting from the licensor during the project is the licensor likely to incur material costs.
From a hardware perspective, generally all major enterprise software has run on x86 machines. Even if the project goes so badly wrong that the customer terminates and implements an entirely different system, that replacement software would almost certainly also run on the customer’s servers. Claims arising from derailed SI projects have therefore tended not to include material elements of the damages claimed for wasted or no longer useful hardware.
Capital and Capacity
The latest developments in AI, big data and crypto-currencies and tokenisation are often significantly enhanced by specialist hardware. In other sectors, IoT and special devices might enable digital transformations. We have looked in detail at the underlying market drivers for this ‘hardware renaissance’ in our previous articles in this series (covering the hardware renaissance in general, and massively parallel specialist hardware for AI).
These combinations of specialist hardware and software being introduced into the enterprise IT system will require integration, and present a new wave of opportunity for the SIs. However, as soon as you add hardware into the mix, the commercial and legal risk profile changes:
- Unlike software, where there are zero marginal costs in making new copies, there are real costs to the manufacture, shipping and purchase of that new hardware. As a result it is much more likely that the hardware will need to be purchased prior to acceptance of the implemented solution.
- If the system is not successfully implemented, and acceptance tests are not passed, the specialist hardware may not be easily reused with other software if the customer terminates and goes with a different solution.
- The hardware component of a hardware/software solution will often be significantly higher cost than software. Consequently the wasted expenditure will be that much greater.
- The need to manufacture, ship and install hardware increases the points of failure. Everything from constrained access to chip fabs, issues with chip yields, shipping delays, container shortages, damage in transit or poor physical installation can create opportunities for failure and delay.
Litigation and Liability
Introducing hardware into the equation changes the risk profile. In short, there are more potential points of failure and greater opportunities for delay (although the optimist would rather focus on the greater opportunities for innovation and transformation). The increased risk profile therefore brings with it a greater potential for disputes to emerge.
However, when looking at the consequences of specialist and bespoke hardware, it is not just the prospects of a dispute emerging that are important, but also the prospects of being able to resolve any disputes. And it is here, perhaps, that the renaissance of hardware is likely to have the greatest impact on technology disputes.
There are two main reasons why disputes regarding combined hardware and software projects may be more difficult to compromise. The first is the age old problem of money. It is a truth, universally acknowledged, that the more money is at stake in a dispute, the harder that dispute is to resolve. The greater costs, and the greater rewards, of specialist hardware and software solutions will inevitably lead to higher value claims. Many businesses may be more motivated to pursue those claims, or less motivated to pay them off, when the stakes are high.
The second factor is more fundamental, and is intrinsically linked to the nature of specialist hardware and software solutions. With a traditional software only solution, if things go wrong the customer can be confident of turning to an alternative supplier who can provide much the same service. Of course, switching suppliers involves cost and disruption, but the end point will almost certainly be a comparable solution which can run on the customer’s existing servers.
By contrast, with an integrated specialist hardware and software solution, a change in solution is very likely to mean a change in hardware as well. Normally, provided the contract has not excluded the loss (and provided the customer has exercised its termination rights correctly), the recoverable damages from a failed project include the difference between (a) the sums paid or payable to the original supplier; and (b) the market price for the same services from an alternative supplier. However, the more bespoke and specialist the hardware, the more difficult it will be to identify the comparables within the market (if there can be said to be a market at all). It may therefore be more difficult to assess, with confidence, the recoverable loss . No doubt customers and suppliers will take very different approaches to doing so.
There is therefore a markedly different risk profile attached to high value, complex projects involving specialist and bespoke hardware and software solutions.
Sense and Sensibility
With an increased risk profile, and greater likelihood of high-value litigation if things should go wrong, there are some steps that parties can take to mitigate risks:
- An even more detailed project planning and due diligence phase to ensure there are no unbridgeable gaps. Where projects go wrong it is often the result of a poorly defined objective (customer) or bid based on a lack of a clear understanding (SI) – both issues that a better design and planning phase can address.
- Rather than a ‘big bang’ investment in everything up front, smaller investments in just enough hardware and software for proof of concept and pilot projects can help to reduce risk. This tends to mean the timelines for the project need to be extended for a ‘scale up’ phase (itself not without risk), but at least the core functionality will be understood and demonstrated before the higher value purchase commitments.
- Some special-hardware-in-the-cloud solutions exist which make that hardware more fungible. If pilot programmes can use access to the special hardware in the cloud, on a pay-as-you-go model, it reduces the risk of the customer being left with expensive but unable hardware.
Event and Eventually
We’ll be discussing the implications of this exciting time in hardware at the European Technology Summit in our ‘Hardware Renaissance’ panel. To find out more and register to attend the summit, visit the event website.
You can find more views from the DLA Piper team on the topics of hardware, AI, systems integration and the related legal issues on our blog Technology’s Legal Edge.