You are here
The Law is an Ass, but the cloud database is an Aas that can kick it
While the technical arguments for switching databases are often straightforward, they won’t be the primary consideration for those outside the IT department. How, for example, would you present the case to the legal department? They think differently over there.
There’s good news and bad news for the legal department. The bad news is that the Law is an Ass. Everyone familiar with corporate litigation almost certainly knew that already. But they don’t know the good news. Compliance with some regulations and legal agreements can be offered ‘as a service’ (AAS), through a cloud-enabled database. In other words, the law is an ass, but compliance is an Aas. It’s your job to convince them that the latter can kick the former.
Choose your words carefully when describing how cloud-enabled databases can help them meet legally binding service level agreements (SLAs). It needs to be perceived as a legal tool, rather than a technology product. So try to frame everything in terms that are evocative of the legal profession.
It helps if you can speak the language of the legal and compliance departments. This means you need to think about how you can couch all the familiar technical arguments into terms they would use as a matter of course in their own day-to-day business.
There are some common words between IT and the legal sector, but they often mean different things. For example, we in IT use the word ‘breach’ to indicate that someone has gained unauthorized access to an information source. According to Black’s Law Dictionary, the legal and compliance crowd use the word breach for a variety of derelictions, of contract, duty, confidence, warranty and, finally, breaches of the peace.
We need to find phrases that express, without ambivalence, how the choice of database can affect a company’s data security, integrity, durability, consistency and ultimately its sovereignty.
Lawyers enjoy what they call the ‘freedom of a tight brief’, a phrase that sounds oxy-moronic. However, a tightly defined set of rules, - be they legal or technical - can be enormously liberating, as it grants the practitioner license to do more valuable creative work, by rescuing them from the prospect of multiple sources of breaches, or unpleasant events. This is where tales of open source software, with its ability to put security at risk, is a recognizable parable for the legally minded professional. They need no further explanation as to how open source databases are likely to be less akin to a well-defined but perfectly elastic entity - and more likely to be ‘all over the place’.
The fact that NoSQL’s lack of strict transaction consistency can put customer data at risk can be explained by comparing it to a shabbily applied process of law. In these cases there is no consistency of events. Events are everything though. As British Prime Minister Harold Macmillan famously responded, when asked what makes governments lose their consistency: “Events, dear boy, events.”
Despite claims of “eventual” consistency by NoSQL, eventual can quickly lead to never. Imagine all the servers hosting components of a NoSQL database as being different people in a legal department. The Compliance Officer tells the Marketing Manager that it’s going to be a busy day tomorrow. However, the Corporate Lawyer tells her husband it will be a quiet day and she’ll be finished early. Then the Compliance Officer tells the corporate Lawyer that it’s going to be a hectic day tomorrow.
This means that all the servers (Compliance Officer, Marketing Manager, Corporate Lawyer) will know the truth, which is that it’s going to be a massively busy day tomorrow. However, the client (the lawyer’s husband) is under the impression that it’s going to be an easy day, because he asked one of the servers (his wife) - who at that time was telling the truth.
That is the type of eventual inconsistency you expect from NoSQL.
Explaining the strict consistency and discipline of ACID compliance calls for more creative thinking. How do you explain concepts of Atomicity, Consistency, Isolation and Durability without losing your nontechnical audience?
Atomicity is akin to the atomic option, under which each update (“it’s going to be a nightmare at work tomorrow, don’t expect to get home early”) has to be duplicated across ALL parties, or not at all. There is no passing of information to one person, based on the assumption that everyone will find out.
Consistency means that any transaction brings everyone forward, while isolation can be explained in terms of all the transactions collectively being akin to the result if each was carried out in sequence individually. Durability is the quality of not losing information in the event of a system crash, since results are stored permanently.
To exemplify this in a legal setting: If your company has $5 million in the bank and a client settles an invoice for another $10 million, the balance, when queried from anybody’s desk, will say $15 million.
However, if the company hired Charlie Sheen as its Marketing Manager, there may soon be a series of Lawsuits, collectively costing $500,000 a day. Each day, no matter what screen an employee is using to check the company accounts, the total cash holdings will have depleted by half a million dollars. The database will continue to be this consistent until, after thirty days, there is no cash left in the account.
At no time can the balance reflect anything other than the actual sum of all of the transactions made on your account to that exact moment.
Only those NewSQL databases that are designed to be distributed will have strict consistency. The distributed object architecture, that takes full use of the collective power of the cloud of computers, creates an environment where new servers can be added painlessly. This means that you can ramp up the capacity of the database without losing anything in the performance. This is a result of a model that uses tiers of computing power (AKA transaction engines) which are aggregated together in the same way that big companies add more lawyers to a legal team for a high profile court case.
Such a court case might involve, say, a global cloud service provider in a dispute over data from European clients, which is subject to searches by the FBI. There are regulations springing up all around the world about data sovereignty. Russia’s localization laws mean that Russian data must live in Russia. Meanwhile, not only must German data reside locally, but all of the 16 German states have their own specific data protection laws pertaining to the same areas.
The various degrees of data residency and sovereignty demanded by each country in the world can be catered for by NewSQL databases, and NuoDB is leading development in this area.
Data in the cloud is going to be pervasive but, in another sense, it will never be ‘all over the place’. We can litigate for that.
Nick is a freelance tech writer who wrestled with IT in the health service, financial services and the police (and saw the best and worst of its effects) before he moved into journalism. He still has nightmares about bringing the Metropolitan Police’s traffic system to a standstill, because his boss said he ought to teach myself about IT through trial and error. He is a freelance technology writer for publications such as Daily Mail, The Guardian, Data Center Dynamics, Microscope, and Computer Weekly.
Nick can be found on Twitter @ohthisbloodypc