DAML driven development: setting the benchmark for Distributed Ledger Technology

DAMLDigital Asset’s smart contract modelling language tool – can offer unique benefits to the financial services industry and enable GFT to bring Distributed Ledger Technology (DLT) solutions from prototype to production in an accelerated timeframe. In my lastest blog I plan to show how DAML is helping GFT improve productivity, make better use of skills, and improve the quality of the DLT solutions that are currently being developed 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 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.

We 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:

  • 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.
  • 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 utilised 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!


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

  • 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.
  • 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.
  • 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.

Please note that the first version of this blog was originally published here: Medium.com/daml-driven.