The World Needs a B2B Application Development Platform

By: Richard Gendal Brown, Chief Technology Officer

We’ve been building business-to-business applications wrong this whole time!

Imagine a firm needs a new way for employees to book vacation. Or maybe customers want to be able to track their orders online. It’s your job to build the application. What design would you go with?

Chances are you’ll build it in much the same way as everybody else does. There will be a database. There will be a business logic layer—you have a lot of choices here. And there will be a front-end—perhaps a mobile app or website, or a set of APIs. And then you have to worry about hosting it. Perhaps the HR department will host it in-house. Perhaps the supplier will host it in the cloud.

Fundamentally, there aren’t really many distinct ways to build these things.

But did you notice something? Did you see how it never even crossed your mind that the employee should write or run the vacation booking application, or that the customer should write or run the online order tracking app? It’s so obvious that it should be the employer and the supplier right?

It’s ‘obvious’ because there’s an asymmetry in many business interactions, and this makes it easy to figure out who should be responsible for what. There’s usually a ‘user’ of a service, and a ‘provider’. And this usually maps nicely to the idea of ‘clients’ and ‘servers’ in the world of IT.

And this is very helpful, because if we can assume there is a single party providing a service, who is the ‘owner’ of the data and controls changes to it, then it becomes very simple to design the application.

This is certainly the case in our examples above: we’d expect the HR department to be responsible for information about employees, and it makes sense that it’s a supplier who keeps track of what has been ordered, by whom. Modern application development frameworks bake the assumption that there’s an ‘authoritative party’ into their designs as a result.

One size does not fit all

However there’s a big problem. The problem is that lots of business interactions do not fit this pattern.

• Imagine you had to automate reconciliations between a network of banks. Which banks are the ‘clients’ and which is the ‘server’?
• What about a new platform to facilitate the negotiation of contracts between buyers and sellers? Who should run that application and control all the data as a result?

It’s not obvious, is it?

Yet, all too often when faced with a market with no obvious ‘clients’ or ‘servers’, the IT industry’s response has been to insist that there must be a server if you want to use our products! And if that means reshaping how the market works to introduce a brand new intermediary then so be it. This is surely nuts. Why do we think it is normal that when a market doesn’t conform to IT vendors’ ideas of what it should look like, it’s the industry that has to change, not the software?

The result of this process is that manual work that was happily performed bilaterally is often controlled by a third party once the market has ‘digitised’ itself. Is this progress?

When exactly was it we decided we had to change the structure of an existing market to solve a simple business problem? How did it become acceptable that IT design assumptions should have the power to reshape the dynamics of entire industries?

If you think this is a philosophical problem of no practical concern, consider the following examples:

Marketplaces

When buyers and sellers get together at a physical market to trade with each other, they follow a collectively agreed set of rules, usually overseen by a market ‘operator’ that they collectively govern. Yet when buyers and sellers trade with each other electronically, the market operator’s role is usually far more significant. Somehow, when markets ‘go digital’ they end up entrenching the market operator in an ever-more privileged position. An impartial ‘arbiter’ often becomes the most powerful and profitable entity in the ecosystem.

Maybe we should ask ourselves: how much of this is a natural market outcome, and how much of it was driven by the hidden assumptions inside the software development tools we use? Have our tools forced us to model a peer-to-peer market as a client-server architecture?

Reconciliation

When banks and large companies need to check the accuracy of their accounting records, their auditors reach out directly to their trading partners to verify that their books and records are in sync. This is an inherently decentralised, point-to-point style of interaction. Yet when IT systems were built to automate these processes, they were invariably built as centralised, hub-and-spoke systems, often run by new third-parties.

Was this a conscious decision to change how the industry worked? Or was it an unintentional consequence of an IT design decision?

Global trade

International trade still relies on a large amount of paper. Buyers, sellers, shippers, banks and others interact on a daily basis to facilitate the flow of goods, and payments for them, around the world. Yet there has been surprisingly little progress in digitising the process of trade finance: issuance of letters of credit and so forth. There’s so much paper!

Could this be because a centralised application with an all-powerful operator is fundamentally incompatible with the messy, decentralised, international trade finance industry? Who is the ‘client’ and who is the ‘server’ when a large UK retailer buys some goods from a Chinese manufacturer? Could the failure of the trade finance industry to digitise until recently actually be a sign of their sophisticated understanding of market dynamics and the IT industry’s failure to understand them?

When you start thinking this way, you can see examples of it everywhere.

The bottom line is that the application development platforms we’ve been using for the last twenty years are designed for a hub-and-spoke model where the users are supplicants of an all-powerful application owner at the centre. This is perfect for many scenarios, especially in the ‘business to consumer’ and ‘employer to employee’ space.

But huge numbers of situations—particularly in the ‘business to business (B2B)’ space—do not look like this. B2B interactions are almost always interactions between peers and counterparts… buyers and sellers, each acting with full agency, neither superior to the other.

If you asked two traders in a market which of them was the service provider and which of them was merely the ‘client’, they’d look at you as if you were mad! So why are we building applications that embed this assumption into the heart of their architecture?

The world needs a modern B2B application platform

It’s time we challenged ourselves to do better. So can we at least write down some requirements for a business-to-business application development platform that does respect existing market dynamics and doesn’t force new parties into the mix? For example, what are some of the problems you need to solve when building a true B2B market-style application?

Record-level data ownership: fundamentally, we’d probably start with the idea that different records in the system should be controlled or ‘owned’ by different parties. If one party controlled everything then we’d have the status quo. This immediately creates a need for some notion of…

Identity: if different records are owned by different parties, we need to a way to refer to these parties. And it’s likely that each of them will want to control who has access to which records. So this means we need a way to manage…

Data sharing, reconciliation and synchronisation: each record will have one or more owners, but there will be other parties who need to have a copy, and they need to be sure their copy is the most recent version and that it has been validly created. Where did it come from? If it was updated, who did it, when, and was it done in accordance with any pre-agreed rules? After all, these records may represent real legal agreements. The need for updates that might require sign-off creates a requirement for…

Workflow: whenever firms are interacting with each other, invariably there are complex processes that need to be orchestrated. Sign-offs and approvals need to be obtained. And the inevitable delays and glitches have to be resolved. And these workflows, critically, need to be managed across and between all the different firms involved in the process… so the workflow layer needs to have an inherent and deep understanding of identity, and an ability to coordinate between firms, not just within a single firm. But if every single update needs manual sign-off, we’d never get anything done. So this creates a need for…

Shared, distributed, verifiable business logic execution: applications always contain business logic but in B2B scenarios, the question of who is expected to calculate what, for whom and when, is surprisingly subtle. So there needs to be a way for firms to verify some computations for themselves, and to specify whom they trust to calculate other things for them. After all, that’s how things work today: some things can be taken on trust, other things must explicitly be verified. And it’s rare in the real world to just give some central party complete power to do everything. The B2B application platform needs to reflect and support this real-world sophistication. But a system that is in sync with its peers in other companies but out of sync with the applications in your own company solves nothing. So we also need rich support for…

Integration: the system needs to play well with other internal systems and processes… we have to remember that the firms who need this sort of platform probably already have hundreds of existing applications, each of which is probably a system of record for something or other. So, in addition to synchronising information between parties, we need a sophisticated way to ensure this point of ‘inter-firm truth’ is in sync with all the other places it exists inside each firm. Finally, this entire architecture needs to be built to run between firms, across the internet, so we need a modern approach to…

Security: the system must understand that events, data updates and business process invocations could be arriving from both inside the firm and from outside the firm. Records in your database could be updated automatically if their owner is some other firm. We’ll be communicating non-stop with the outside about critically important business data. We can’t just pretend we’re sitting behind a strong firewall that protects us from the outside. So we need to implement cryptographic protections into the heart of the application: all interactions must be authenticated, data updates need to be controlled by pre-agreed constraints, records need to be fingerprinted in order to detect malicious mutation, and more. In short: these applications need to rely wholeheartedly on applied cryptography, or ‘trust technology’ as we sometimes call it to avoid scaring business people.

There are, of course, many more requirements. But my experience from building a system that implements the vision I’m outlining here is that these are the requirements that drive most of the architecturally-significant decisions.

Put the power back in the hands of businesses, not the IT vendors

At its heart, the problem we’re trying to solve is one of power dynamics: how can firms come together to improve how their markets work, but without accidentally introducing a ‘monster’ that turns round and eats them all? We’ve all seen what happens when regular centralised platforms obtain a position of elevated power: they get to control everything that is happening on their platform and, as the platform grows, it becomes ever more valuable, attracting more users, whilst simultaneously making it harder for existing users to leave, increasing the pricing power of the operator. This is a problem we’re trying to avoid.

We also need to be pragmatic, however. Every firm wants to believe they’re in control, but not all of them want to incur the cost of running their own infrastructure, at least not at first. So we need an architecture that enables some participants to run their own piece of the shared infrastructure, whilst others experience it as a cloud service. The power comes from having the option to ‘repatriate’ data and control should they feel a central operator or other service provider is becoming over-bearing. You don’t need to exercise that option for it to have power. We might call this empowering such firms with ‘digital sovereignty’.

The good news is that we’re on the cusp of solving these problems: B2B application development platforms now exist. We just haven’t been describing them in this way.

So what have we been calling them?

B2B application development platforms are…enterprise blockchains!

The answer is that a world-class B2B application development platform has been engineered in plain sight over the last seven years. It goes by the name of Corda, but you may also know it as an example of an ‘enterprise blockchain.’ This term is used because many of the techniques being applied were first popularised by public blockchain platforms, even though the public and private blockchain communities would be the first to admit their networks do some really quite different things.

I imagine some readers have an eyebrow raised at this point. If so, I’d encourage you to re-read this article and then look at what platforms such as Corda actually do, and what they’re being used for (as opposed to the jaw-dropping amount of hype and bluster that infects this space)…

If you have a business-to-business problem that needs an IT solution, and are wondering why the standard development tools don’t quite hit the mark, it’s OK… you’re not the only one. It’s a real problem. The good news is that there’s also a solution: Corda.

In this piece, my objective was to motivate the need for a purpose-built B2B application development platform. But now you are, I hope, intrigued, you can find out more about how Corda attempts to support this concept by reading the intro whitepaper, heading over to our docs or, most powerfully of all, read about real-life production projects that are using the platform right now.