@mwra No problem with sharing “the real subject area”, it’s not a secret just a tad esoteric.
The backstory is that I have a background in both engineering and law. For many years I ran a software company writing drilling engineering software. I sold my shares c. 2000, mucked around for a few years, then took a law degree and qualified as a solicitor. Shock, horror! The legal profession is years (decades?) behind much of the world, particular in terms of how they run their businesses. To be fair, this is partly because of the nature of partnerships, which can’t raise investment by issuing shares, but there are easy things that pay back quickly and that low hanging fruit is not being picked.
When I ran out of steam as a lawyer, I retired and turned my mind to whether there was a business to be made applying engineering practices to the business of law. Buzz words like “design thinking” get thrown around with gay abandon, but nobody much seems to have actually practiced design in the sense of “if we design this oil well wrong it’s going to blow out, kill a lot of people and pollute half the North Sea”. When you’re writing the CAE software that people are using to design that well how you do it is, shall we say, an important factor in sleeping at night.
If you’re an engineer you’ll appreciate that a fundamental reason why oil wells don’t often go bang, bridges don’t fall down, trains pretty much never crash and aircraft rarely spontaneously disassemble in mid air is process systemization. That, and a decent understanding of physics, is largely what engineering is. Things such as trains and 'planes and bridges (and, indeed, oil wells) are not artisanal creations; they are the end product of repeatable design processes, constructed and assured using defined, testable systems, and operated and maintained according to defined systems. Even when the artefact itself is bespoke it is inevitably a variation on a common theme — a taller bridge, a longer tunnel or a deeper well. Te process by which it is designed and built remains systematic.
So I thought I’d try throwing (relatively) common engineering practices at legal processes to see what stuck.
First up, how about stochastic cost and time estimation? If you go to the typical firm of solicitors and ask what fee they’ll charge for some (reasonably complex) transaction — like selling a company or settling a large estate — you’ll be lucky to get a fixed price quote. And that’s for the type of work that solicitors undertake repeatedly and understand well. Why? Because although they know what to do and they have systems (for “matter management”) to support them, their processes aren’t systematised and, because of that, they can’t be instrumented to record to the level of detail needed to generate accurate quotes. c.f. almost any other profession: of course you can get a fixed price for an audit, of course you can get a fixed price for building your website, of course your dentist can tell you the price of a root canal …
Problem number one. “We’ve got all the stuff you’ll need in our matter management system, it’s got all the details of every transaction we’ve done in it.” Well, yeeess, but… I can see that Janet the solicitor spent three hours 12 minutes “drafting”, and that John the trainee was occupied on “document review” for two hours last Friday afternoon. You’ve got lots and lots of that data ‘cos you bill by the hour and you need it to know how much to charge. BUT it would be handy to know what dear Janet was drafting and WHY. “Sorry, we don’t record that". Nevermind, can I get a copy of your database? “Oh, we don’t have a database, it’s all safe in XYZ vendor’s cloud (latest buzz word), I’m sure you can speak to them” . Please Sir, can I get access to ABC’s database, and can you tell me how it’s structured so I can query it? “What! You want us to disclose our super sophisticated, highly optimised, proprietary schema? Heaven forfend!” Which probably means grief, no, it wasn’t that good to start with and we’ve kludged so much stuff into the backend to support the latest spiffy new features demanded by marketing that the technical debt is about to capsize the ship. I know, I understand, I’ve been there, it happens to everyone.
So set aside any idea of stochastic cost estimation, set aside systemisation and process improvement, there’s no point in trying to sell anything that can’t meet the demand of “will it work with what I presently use?”.
Cue much pondering on long walks with the dogs and digging the garden, followed by extensive Googling on data exchange standards (virtually none, it would seem in the legal field) and how client server computing works today (as opposed to twenty years ago). Much the same it seems, but they’ve changed the names and learnt (yet again) that wire protocols should be flexible. REST? Seemingly a database query in disguise loosely married to a remote procedure call. GraphQL? Oh, a treewalk to save round trips to the database. Been there, done that on a '486 running at 500Mhz over an ISDN telephone line. SQL? Surely by now someone, anyone must have come up with a less incomprehensible language! Sorry. Excuse me while I go into Victor Meldrew mode.
The real issue I finally surmised — the pervasive, underlying issue — is one of data sovereignty. Law firms have largely lost it. More accurately, having dug themselves massive holes trying to make disparate off the shelf software play together happily — yes, I’m looking at you Exchange and you too, Sharepoint. Just stop bickering, the pair of you — ceded it to various “legal systems” vendors of in the vain hope of being thrown a rope. Information is the lifeblood of business and ceding sovereignty over it — allowing control over the structure, storage and access to yout own information to slipthrough your fingers— is to hamstring your business’ capacity to change. Give up sovereignty and you are, almost literally, in the hands of your vendors. Sure they gave you a rope, it just wasn’t tied off at the top.
Hence project number two. Design and publish a flexible and extensible data model capable of holding all business information pertinent to legal practice. Then build a reference implementation for a datastore that is based entirely on open source software.
This is where Tinderbox comes in. TBX use case #1. I have what I consider to be a reasonably good core model (prosaically called the Legal Practice Model, LPM), but it needs documenting and, ideally, published to the web. Tinderbox can do this.
TBX use case #2. The structure of the LPM is similar to that used by Tinderbox, namely it is a spin on the Entity - Attribute - Value pattern. The Note - Attribute - Link approach should facilitate exploration and prototyping of data patterns implementable in the LPM.
TBX use case #3. The LPM, like all extensible models, relies heavily on dictionaries. Populating these dictionaries constitutes by far the greatest design effort. Tinderbox seems an ideal tool for building, by iterative refinement, classifications from sets of instance data (time records, documents etc. etc.) and delivering the classification in a form amenable to uploading into a database.
Finally, TBX use case #4. A tool for prototyping applications. There’s looks to be enough flexibility in the user interface and sufficient data manipulation capability in Action Script to build more than mere toy applications, and way quicker than building a web or electron app.
All in all a voyage of exploration into little charted seas. With luck we shall avoid the Corryvreckan, be spat out by the Kraken as a distasteful little morsel and arrive unscathed. If anyone — particularly any practicing or academic lawyers (maybe those teaching legal tech courses?) or anyone with backend development skills — would like to board, do please contact me.