Daml Driven Development: GFT

Guest post by David Collins, Managing Director, GFT

How do seasoned veterans at one of the world’s top providers of technology solutions to the financial services industry rate Daml — Digital Asset’s smart contract modeling language for solutions based on distributed ledger technology (DLT) — for rapid prototyping of complex financial agreements? In this first of a series of guest blog posts by our partners, customers, and others working with the Daml SDK, GFT’s David Collins discusses how Daml is helping them improve productivity, make better use of skills, and improve the quality of the DLT solutions that they are developing for financial markets.

At GFT, for the last 30 years our 5,000 engineers across the world have been developing bespoke software solutions for our clients in the financial services industry. We think it is fair to say that throughout that time in the world of financial services, we have never seen such a disruption in the complexity of technology change. The advent of Distributed Ledger Technology (DLT), Cloud, Big Data and Artificial Intelligence (AI) has forced us to rethink everything from new paradigm architectures to our resourcing strategies.

GFT’s DLT journey started four years ago with a project at RBS surrounding payments on Ethereum and the Google Cloud Platform (GCP). While successful, our key conclusion was that the time was not yet right for significant consulting opportunities and so we spent greater time on the more mature parts of the digital business, such as AI and large scale public cloud migrations.

In 2017 we re-evaluated DLT, and concluded that the time was now right for further development. As a technology consultancy our clients are looking for us to provide an unbiased view across the vendor landscape, and so we engaged with a shortlist of the market leading platforms to understand what a successful ‘productionised’ project would look like. This involved, amongst other things, implementing the same use case on multiple platforms to assess strengths and weaknesses — more on that later.

GFT is essentially a people business providing technology services for our clients. As such we are looking for the following from any DLT platform:

• A platform appropriate to deliver high quality financial services process re-engineering. This industry has some specific quirks — especially around the non-functional requirements — and not meeting these hygiene factors is a non-starter.
• A clear articulation of the skill sets required to configure and implement the platform into the client. Our clients like to understand exactly what they are paying for and, for example, what should be delivered onshore rather than nearshore.
• A resource pool proportionally sized to the needs of the client. An example of this going wrong would be the current shortage of data scientists in AI. GFT does not want to be selling an offering which requires many resources, when only a handful are available.

GFT started working with Digital Asset and the Digital Asset Platform at the beginning of 2018. Since then we have built many use cases using the Digital Asset modelling language, Daml — presenting some of them at conferences. So far those use cases split into roughly two categories:

1. Consensus across parties. Here, information is agreed-to across a network of potentially ‘untrusting parties’ and optionally published to others. Gaining definitive agreement prior to a milestone is the key benefit here, removing the need for costly reconciliations. Examples would be around the post trade process, trade finance, or trade reporting. In the latter example, publishing is done by revealing the trade information at the appropriate time to the regulator.
   
   The trade finance use case is a good example displaying the compactness and productivity of Daml. In less than a week we were able to codify the end-to-end process of delivering perishable goods from a farm in one country to a shop in another, complete with full documentation e.g. Bills of Lading and Letters of Credit. This included a full set of scenario tests that ensured the flow operated as expected, even when one of the parties was deliberately acting maliciously. The obligables engine — a unique feature of Daml that continuously tracks which parties have a stake in a given transaction — made checking who saw what information at what time almost trivially easy.
2. Complex on-ledger functionality. In this use case, Daml is used to execute complex business logic on the ledger. The benefit here is that all parties know that everyone is executing the same logic deterministically (potentially including the regulator). In some ways, the business logic ends up with the same non-functional qualities as the data (immutable, verifiable etc). The request for quote (RFQ) prototype developed in Daml by GFT utilized this pattern to implement the ‘MIFID II best execution’ compliant algorithm for quote selection, that is then returned to the requestor.

In our experience, applications falling into the first type of use case can be implemented very quickly and safely in Daml as they are fully aligned to the obligables engine. We have only really just started to grasp the implications of the second example.

As far as picking up the language is concerned, our experience was that after reading the documentation, users can rapidly become proficient in Daml by attempting ever more complicated tasks successively. Ninety percent of Daml programming is assembling known patterns in different ways. Whether that is an agreement negotiation, auction, or voting pattern you build up a library of reusable components and then use them to implement the business process you are currently re-imagining. So whilst there is a small learning hump to get over, the investment pays off as you quickly become far more productive using this domain-specific language.

One thing to add was that in our experience the Python interface to the Daml SDK was particularly useful when loading initial or test data, and also when performing any sort of AI responding to events off the ledger. Our data scientists thought it a very versatile interface!

Conclusions

So after eight months of using Daml and the Digital Asset Platform what are our conclusions?

1. Productivity. Using the pattern library described above, writing Daml becomes faster very quickly. The supplied tools make test-driven development relatively straightforward, and you can get to a Daml minimum viable product (MVP) pretty quickly. Using Python to build the applications that invoke Daml contracts, or the many JavaScript options for producing a front end, means that you can get iterating on top of working software quickly — building what the users really want, not what they asked for.
2. Resourcing. Smart contracts are hard to write well. There is a debate in the DLT landscape about whether they should be written in a general-purpose language that allows more people to write them, or in one that is specific for smart contracts (with all other non-specialist code — data interfaces, front-end — in a general purpose language). Digital Asset have chosen the latter, and bearing in mind the succinct nature of Daml and the productivity features, it offers a nice balance — which should be even nicer with enhancements due in the second half of 2018. The clear partition of the skillsets required on a project using Digital Asset’s technology makes finding the resources to staff a team considerably easier for us as a consultancy.
3. Quality of the solution. The cost of fixing defects is often mentioned as going up by an order of magnitude through each of the stages of development. For example, the cost of fixing a bug in user acceptance testing is 10x the cost of fixing it in unit testing — which is itself 10x the cost of fixing it in the specification! Because the Daml obligables engine and other static code analysis techniques are running while you are writing the code, you are effectively forced to write higher quality code earlier. This can take a bit of time to get used to, but the discipline it enforces means that you end up with a higher quality solution faster and at lower cost.

There are many DLT platforms available in the marketplace; however, the unique properties of Daml and the DA Platform mean that it is an excellent candidate for the heavy lifting required when reimagining business processes within financial services.

Join the community and download the Daml SDK at daml.com

This story was originally published 28 August 2018 on Medium

About the author

David Collins, Managing Director, GFT

David has a wealth of experience across financial services and technology. At GFT he leads the Financial Services team across the Atlantic region, and is committed to driving innovative GFT offerings, engaging with new customers and enhancing relationships with existing clients as Country Manager in the UK. David is driving GFT’s Disruptive Technology Practice with its focus on the world of DLT and Blockchain, establishing how GFT can apply this nascent technology to solve our clients’ business problems. David’s vision is to see how DLT and predictive analytics / artificial intelligence / machine learning can be combined, in order to create efficiencies and new client revenue streams.

David joined GFT from Sapient where he was heavily involved in working to reshape and refocus its UK business consulting organisation, and before this, he held the role of CEO of SDX Trading and chief marketing officer at SuperDerivatives.