Software-as-a-service

JC pontificates about technology An occasional series. →Go uptown It’s got its own app, and bluetooth. Technology Tell me more Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

“All reg tech solutions are alike; each reg tech problem is a problem in its own way.”

—Leo Tolstoy, Anna Karenina

Software as a service — fondly known as SAAS but known to users as rent-seeking as a service — is rent-seeking by means of intellectual property or some other kind of monopolistic behaviour. It is also basically the only business model reg tech entrepreneurs — a.k.a. refugee managing associates with JavaScript developers from Bucharest they found on the dark web — can figure out.

The equivalent of selling a warranty on a toaster. Charging a running cost for a software application which shouldn’t need a lot of maintenance, unless you built it to need maintenance.

If your software were any good you would design a user-interface easy enough for the meatware to deal with so you didn’t need a service contract. Right?

The reg tech business model conundrum

Lesson one: Insist on an unsupervised pilot where real users get to push and pull the product by themselves without help from the vendor, and not just a chaperoned proof of concept where the software vendor can control inputs and outcomes to make the product seem satisfactory. Remember the sixth law of worker entropy.

It is a familiar experience amongst buyers of reg tech and legal tech that hawked products do fabulously when demonstrated to the general counsel at the pitch (often by performing some kind of magic on a pre-prepared non-disclosure agreement), but underwhelm upon implementation when set upon by the morlocks who actually need to use them to solve real-life problems.

This is partly because the yen to be thought-leadings agents for step-change in their industry, plays to a general counsel’s innate credulity and weakness for flattery, but has a profounder operating cause: reg tech struggles mightily with a business model that scales. reg tech strives to automate tedious, repetitive and manual tasks, thereby removing a significant cost item from the departmental budget, and accelerating and improving the output quality at the same time. The idea is to disintermediate, taking out expensive, unreliable, high-maintenance machinery and replacing it with does the same job for nothing.

If you are buying that product “off the shelf” — assuming it can already do what its vendors claim; by no means a given — observe where the vendor’s energy is going: exclusively, sales. They are costlessly reprinting something they made earlier, and proposing to charge you a licence for it, per seat, per use, or per time period. On this model, there is only one way to make decent amount of money: by extracting rent. Now this would be fine, of course, if the product did work as billed, and intelligently anticipated your particular applications, and handled them quickly, quietly and immaculately right out of the box.

But, of course, they don’t. It is a common experience, when you finally get to play with it, that a reg tech application doesn’t quite do what you want it to. Either your intended use isn’t quite the one the vendor had in mind, and the product can’t quite do it and isn’t flexible enough for you to reconfigure it — call this a “misalignment” problem — or it can, but to get the application to be of any use, it will need a good deal of energy, expertise and effort from your people to configure or train it; energy they will be disinclined to provide — call this a “configuration” problem.

Misalignment and configuration are different problems, but most reg tech offerings suffer from both, because they both stem from the same fact of life: while there is an unquantifiably huge volume of tedium to be automated, no two instances of tedium are quite alike. Tedium is particular, not generic. That is why it is tedious. If the same instance of tedium were common to enough market participants that a glib SaaS solution could fix it, it would have been fixed by now. Fixable tedium is not stable. Persistent tedium is stable. Notwithstanding breathtaking claims to the contrary from people who should really know better — who do, in fact — this has been the story of technological progress in the legal industry in the last thirty years. Pace Allen & Overy’s thought-leaders there has been tons of legal technology. The BlackBerry. Citrix. Document comparison. Document management. Optical character recognition. Voice recognition. Cloud computing. Remote access. Working from home. Skype. Virtual deal rooms. e-Discovery. Legal process outsourcing. All things that effectively, quickly and cheaply solve generic problems, that are intuitive, that boost productivity from the get-go.

Misalignment

The JC has lost count of the products that do a job, but just not quite the one you’d like them to. Document assembly packages that oblige you to create document structures in their application rather than in Microsoft Word, or can’t handle columns. Document management systems without APIs to your own systems. Workflow systems that can’t handle parallel routing. Document extraction engines that can’t handle regular expressions. In each case we need this kind of functionality to apply the application to our particular, counter-intuitive and often baffling circumstances. Our institutions shouldn’t be counter-intuitive or baffling of course, and it is hardly the reg tech provider’s fault, but they are. They are complex organic systems with a tendency to complicatedness. Every bureaucratic firm is bureaucratic in its own way.

Configuration

Configuration problems tend to be ones that attend the use of artificial intelligence. Again, thought leaders see the abstract appeal of artificial intelligence while disregarding the challenges of the particular. Neural networks need to be trained. This is a slow, laborious, painstaking job. To extract a re-hypothecation formula from a database of thousands of random prime brokerage agreements, for example, is doable — if you have on hand a specialist with a sophisticated understanding not only of legal language and market practice but also of regular expressions and PHP, who is prepared to spend weeks training the neural network to get it started.

Not many people do. Certainly this is not the general counsel’s expectation when, during the pitch, he is presented with a magical machine learning application which, he is told, will solve his every problem.

Note two ironies here: first, the lion’s share of the effort, expertise, and experience required to make a neural network work comes not from the product itself, but from those inside the client who painstakingly train it. Given how long the training process will take, this is no small cost — yet, being “sunk”, it will fall off the costing projections when the business case is put together.

Second, this subject matter expert training is exactly the sort of thing that — if a client permits it — the vendor can harness to improve the product for its other clients. To be sure, there is a quid-pro-quo here: the client, too, will benefit from the training the product receives from the hands of the vendor’s other clients, but this only sharpens the irony: the value the vendor itself provides is minimal: merely an application interface on top of open-source neural network technology. What turns a public utility with a glossy front-end into gold-dust is the distributed training the application receives, from the clients. Yet, the vendor gets to bill the clients, and not the other way around. That is truly “indistinguishable from magic”.

Then there’s blockchain, of course

The latest iteration — talked about in tones of reverent optimism here — is “blockchain as a service”. But a service to whom? And did I hear a siren going off?

See also

• Blockchain
• Rent-seeking
• Reg tech