Brexit-proofing software – without programming for specific dates, jurisdictions, etc

Brexit-proofing software – without programming for specific dates, jurisdictions, etc

Abstract: Simple methods to inoculate data protection (or any other) multi-jurisdictional software from Brexit and similar events, before their possibility can be known or even contemplated.

International software blues

A general problem for lawyers – and for all their clients dealing with multiple jurisdictions – is how to ensure seamless transition of processes and systems (IT and otherwise) between different jurisdictions, in which different legal systems apply and unpredictable new rules can come into effect at any moment and, in the case of common law, often backdated.

A general problem for software developers – and for all their internal and external customers dealing with multiple environments – is how to ensure seamless transition of the same core software between widely diverse and (to an extent) unpredictable future physical and other non-software environments.

The reader will notice the preceding two statements have almost identical structure. It is submitted that, from an architectural / engineering perspective, conceptually it’s the same problem.

Caveats and scope

Warning to lawyers – partly trite, but CONTAINS IT-GEEKERY (and nuts)

Warning to IT folk – partly trite, but CONTAINS LAW-GEEKERY (ex officio you already have all the nuts you need)

This is not a learned treatise covering all possible approaches. Nor will I be taxonomically precise. I merely discuss some traditional approaches to these generic problems. Then I demonstrate the simple architecture/techniques I developed before Brexit was a thing, or even a word. Thus my solution really has nothing to do with Brexit per se – it merely happens to solve many international IT architecture issues flowing from Brexit. This is not fortuitous but inevitable. 1

The problem, traditionally stated

Let us postulate we already have Some Process which we, with faultless precision, shall call DoStuff. Let us further postulate we have Some IT Process supporting it which we, for reasons that defy comprehensibility, shall call DoStuffApp.

DoStuff can be a legal method. It can be a business process. It can be another IT system we’re supporting. It truly makes no difference. All that needs concern us is the hypothetical risk that DoStuffApp might go haywire post-Brexit.

Ok. So this is our scenario. Brexit is suddenly announced by Mr Cameron before flouncing off in a huff. We foolishly had not foreseen this obvious result (unless we’re one of those that profited mightily on the day). We realise DoStuffApp has a risk of going haywire post-Brexit. What do we do?

Of course we are forced to assume the additional risk of “enhancing” DoStuffApp to cover the changes flowing from “Brexit” 2

Under the kind of functional analysis that even numeracy-challenged people (honest guv, I didn’t say lawyers) can perform, we’re going to have to clone DoStuffApp and turn one into a new code block/library/app/whatever called, imaginatively, DoBrexitStuffApp. We combine them into a single generically DoNewStuffApp which we might represent in pseudo-code as follows (just an example, mileage will vary):

  • IF material jurisdiction == uk AND material scenario date > 29 March 2019 THEN
    • DoBrexitStuff
      • defined as DoStuff stuff that is specific to the uk, if any, i.e.
        • DoStuff;
        • minus the EU club rules;
        • plus the rules of all of the new clubs we already know and have pre-announced we are entering (without all that tiresome bother of actually negotiating entry) or even re-entering 3
        • plus any new UK-specific rules the UK executive dreams up 4
  • ELSE
    • DoStuff [i.e. just as before]
  • ENDIF

So far, so bleeding edge of obvious. But there’s a legal/financial/technical/business problem, encapsulated by at least three principles

  1. All changes to systems (IT or otherwise) incur serious risk. The more serious the change, the more serious the risk. And business is not, EVER, in the business of taking risks. 5
  2. Worse: the core specification of DoBrexitStuff changes. Sometimes the direction from the Program Sponsor and even its consistent identity 6 seems unclear from day to day. Think date change – there might be an extension. Or a transition period. The algorithm might change? 7 After the US has killed off the WTO zombie, we might join Canada++, or even ++Canada. We might become part of APEC. 8 Any or all or none of these mean changes to the UK-specific algorithm, depending on the rules of whichever club(s) we join/create/recreate – or even re-enter . New risks develop and pile up upon the old new risks.
  3. Entropy increases. Not quite until the heat-death of the universe, but certainly for five or so years until the app becomes terminally unfit for purpose and has to be abandoned, I mean upgraded or replaced, accompanied by a data migration that’s always dodgy, I mean successful. Never mind, with the IT department’s omniscient understanding of precisely how their systems work, we can continue our reasonable refusal to believe that anything could possibly go wrong.

Traditional solutions

I’ll just run non-exhaustively through a few technical solutions of varying sophistication often for slightly varying purposes. I ignore structural algorithmic changes and focus on changes to suspect variables – such as who’s exiting, who’s not, dates of exit, etc.

  • Abstract dodgy magic number variables (such as “uk” and “29 March 2019”) into constants – pure programming solution
  • Abstract them into static data (ditto).
  • Abstract them into environment (sys-level) or config (app-level) metadata. (This has the huge advantage of eliminating the need for software re-compilation/re-deployment)
  • Abstract them into a config metadatabase (if there are hundreds of them – you can see where this is starting to head)
  • So-called “Internationalization” techniques (not material here but good to make frontends work in any language)

Here’s the solution approach I’m about to demonstrate:

  • For any scenarios that might recur, refactoring the code so future “similar” changes (in this context say Cexit, Dexit, Eexit, Fexit, Gexit, Breenter, etc) can be accommodated by changes to metadata rather than code.
  • in short: the traditional refactor once, reuse often, for all anticipated and many unanticipated functional spec changes

As it happened, with Brexit I’d already embedded this capability into my legal architecture. Why? Because, in terms of designing a legal architecture Brexit-coping functionality isn’t remotely new and so I’d already catered for it. Inadvertently – and that’s the real point here. Most jurisdictions are members of many legal rule “clubs”, which the legal geeks call “treaties” which themselves can be treated as jurisdictions whenever they have binding dispute resolution mechanisms, which the legal geeks usually call “Courts”. Many do. The UK has, or (if you prefer) has sacrificed its sovereignty to, plenty.

Here are a few clubs with attached Courts of binding authority which are in the model for the jurisdictions I’ll exhibit:

  • The ICC.
  • The CE (sponsor of the Court of Human Rights 9).
  • The EU.

But there are plenty of others which I haven’t actually inserted into my model 10. I expect the UK’s plan is just like other nations’: to continue subordinating itself to clubs for trade or other purposes, and indeed to continue sacrificing territorial sovereignty. A “jurisdiction” for me is thus a dynamic artefact 11 scoped within many factors/constraints, including time. Jurisdictions continuously cycle in and out of existence, even within the UK itself which relentlessly has jettisoned sovereignty since 1867 (Canada) up to the present day. 12

So. How do we encapsulate all such nuances without ever having to put them into source code or special configuration metadata?

For illustrative purposes I present la2.082b.jurisdiction – a small extract, neither wide nor long (circa 3% of the rows and 12% of the columns), of the jurisdiction artefact of my current legal architecture metadatamodel (which for avoidance of doubt is protected by copyright, database right, moral rights and pending patents).

I draw your attention to each of the columns:

  • Code – note that this looks like a two-character ISO code with 3-character provincial extensions. But it’s not. (ISO codes are physical-geographical, which therefore do not map to jurisdictions except by coincidence). Technically neither the EU nor the UK possess existence (which here I use as a predicate despite St Anselm) in terms of such ISO geography 13, I take liberties with the reserved codes “EU” and “UK” – and similarly invent codes for other jurisdictions where material.
  • FromDate – each of the “post-Brexit” UK jurisdictions has an entry. It is submitted it’s self-evident why and how this works. The others don’t.
  • ToDate – each of the “pre-Brexit” UK jurisdictions has an entry. Ditto.
  • Super-jurisdictions 14 – This designates the list of jurisdiction codes of all the “clubs”, or treaties if you prefer, to which this particular jurisdiction has subordinated itself de jure (as distinct from the arcane workings of “public international law”, see below) for the duration of the time period defined by the jurisdiction. 15

Voila. Once your code loads such a jurisdiction artefact, it knows everything it needs to know about the jurisdiction. It can exploit this (as set out below or in later posts) to process all the rules (or, as legal geeks say, applicable law) for each material jurisdiction.

Plus it knows that (for example) Northern Ireland is part of the UK. Here is the key functionality derived from the Superjurisdictions column – to identify the superjurisdictions so it knows to process any applicable law it can find (from something called, for utterly opaque reasons, the ApplicableLaw artefact), for those jurisdictions too. Without a single jurisdiction-specific line of source code required.

Bonus: strategic planning and future-proofed risk testing becomes easy once you design your jurisdictions this way. Because? Because you can set up the scenario dates for anything you like (defaulting of course to today) and – voila again – your jurisdiction artefact apparently magically adjusts itself to contain to those, and only those, jurisdictions that exist on the scenario date. (of course it doesn’t physically change anything – it’s just that your processing app is only ever permitted to see the “view” of the table that’s delimited by the specified date.

My choice of jurisdictions prima facie may appear eclectic, you say? It’s not. The rows chosen are:

  • the 8 material UK jurisdictions (chosen for current purposes), plus
  • Mayotte, Aruba, Bermuda, Jamaica, and Greenland – chosen partly for comparison, partly in order to demonstrate calculation of GDPR direct engagement of  such jurisdictions 16 – but I’ve gone on too long so that can reside in a future post. (see https://www.gdpr360.com/gdpr-engagement-of-30-additional-jurisdictions-automated-pleadings)
  • For benefit of particular prospects, or additional public international law pointers, in future I may consider adding others, for example the Isle of Man.

Please read the Disclaimer at https://www.gdpr360.com/disclaimer

  1. Because, aside from any regrettable and supposedly Unintended Consequences to parliamentary sovereignty (ssshh!), as will become clear from a “meta-legal” perspective there’s absolutely nothing novel about the general effects of jurisdictions joining or leaving clubs / “treaties”.
  2. (whatever that may mean apart from “Brexit Means Brexit” which as a functional specification undoubtedly is delivered like Moses’ tablets of stone from the highest of possible authority below God and the monarch, but arguably remains comparatively sub-optimal in the context of a detailed design.
  3. Though, having burned our bridges with both the EU and the EFTA, which we created in a failed attempt to destroy the EU before we indecently abandoned all the suckers (I mean our new friends we’d persuaded to join having burned their own bridges) the instant we got a better offer from the EU, don’t ever think they’ve forgotten or forgiven.
  4. with its new sweeping Henry VIII delegated powers which empower our so-perfectly-trustworthy Ministers to bypass all that annoyingly antiquated parliamentary enactment constitution “red tape” and rule-by-decree in exactly the same way Ministers did before Charles I when we suddenly went into a huff and started chopping their heads off – what could possibly go wrong?
  5. Contrary to popular myths and propaganda businesses, whether established ones or entrepreneurs, avoid and minimise and mitigate risk and any they can’t they strive to transfer to government and customers and any other available suckers as much as humanly possible. Those that don’t fail to survive against those that do, fun fact.
  6. beyond say a committee of unstable composition calling itself the Cupboard, or the Cabinet or something.
  7. Yes ok, of course it’ll change, this after all is an IT Project and no IT Project survives contact with the Enemy, aka the Users.
  8. which after all inherently contains a certain attractive logic flowing from the mutiny on the Bounty and our subsequent death-grip on Pitcairn Island.
  9. I haven’t factored in Treaty 108, but until I can see how that might become directly actionable rather than souping up other cause of action, I won’t.
  10. Such as the WTO with which I won’t bother unless someone persuades me it’s not going to die as soon as the next WTO judge retires and the Court can no longer hear cases.
  11. I use the anglo spelling very deliberately to indicate meaning as this is not a distinction without a difference.
  12. For example the new Welsh jurisdiction which I haven’t yet enabled because how it works, other than as a sub-jurisdiction of England and Wales as distinct from the UK, remains to me as clear as mud.
  13. ssshh, don’t tell Mr Raab or Mr Barnier, they’ll be hurling Cartesian abuse at each other for months. 
  14. For IT geeks – yes, this column is very obviously not normalized. The artefact is not an SQL table, nor even nosql. It’s in effect my own internal in-memory extension of SQL-ish functionality written for personal maintenance convenience, so I can massively reduce artefact complexity.
  15. You can reverse this concept if you wish and instead list a component sub-jurisdiction list, but logically the two concepts each are fully derivative of the other so it’s a distinction without a difference. It is submitted each have maintenance advantages and disadvantages – including some (harmlessly) redundant metadata.
  16. Specifically, how it’s possible for a automated Particulars of Claim drafting app to cycle through the six or so alternative pointers to determine how “by virtue of public international law” GDPR might be engaged in some or all of the  material “non-EU” jurisdictions that could engage the GDPR – without ever having to insert code into the app specifically dealing with any or all of them. I count circa 31 non-EU jurisdictions that currently might qualify.

Share this post

Comment (1)

Leave a Reply

Your email address will not be published.