Skip to main content

The legality and morality of IT solutions

I’m often found ranting and raving about the legality or morality; or rather the illegality and immorality, of some solution or other – more often than I care to admit. This post should hopefully clarify what I mean when I say it’s “illegal” or “immoral”. I should point out that I'm using these terms as an analogy in context of some IT solution and of course the legality of a solution in technical terms is an entirely different question. Morality never was very well defined.

For further clarification I should state this post is in regard of IT solutions and not the behavioural rules and norms of society in general. That some of those IT solutions I’ve worked on may conflict with what society would expect is a separate issue…

Legality - TFD defines legality as “A requirement enjoined by law”. The key word here from a solution perspective is “requirement”. If we assume that all requirements are mandatory (of course they’re not) then when I say some solution or part of a solution is “illegal” I am simply (pompously) stating that it does not satisfy some requirement or other. This may be acceptable depending on the clients view of the requirement as some rules can be, err, bent.

Unfortunately, I often find that it’s the non-functionals that get eroded first. E.g.:

  • “It’s acceptable that such-and-such a function doesn’t work with IE7 because it looks great on other browsers and isn’t worth the cost to fix it” – breaking a compatibility requirement.

  • “It’s acceptable that performance on some pages suck – it’s good enough generally!” – stretching performance requirements.


Or perhaps the worst (and all too common):

  • “Just dump all the user data to a flat file and e-mail it to the marketing guys – they need it now!” – violating security policy. If found out you could get fired, if leaked you could bring the whole organisation down – low probability but very high risk. It’s interesting that the business focuses on the “probability” whilst the IT dept. focuses on the “risk”…


Morality - TFD defines morality as “The quality of being in accord with standards of right or good conduct”. Oh dear, all very subjective. Who’s to say what’s right and what’s good? The architect of course! (arguments commence)…

Anyway, when I say some solution is immoral, then I’m just saying it doesn’t fit with standards and best practices in the industry. In terms of architecture this could be due to poor division of responsibilities, tight coupling between components and sub-systems, incongruence with organisational structure, inconsistencies in implementations, complex dependencies and so on. None of this is black and white and sometimes compromise is the best solution – so long as you can sleep at night. But there are reasons why this stuff exists – partly because it works, partly it’s old wives tales – you’ll need to figure out which is which.

 

We’re often asked to bend requirements. Sometimes it’s the right thing to do, sometimes it’s just the easy thing to do. In any case, like the law, ignorance is no excuse. Make sure you understand the requirements and if you don’t satisfy them then, well, that’s your call.

When it comes to morality it’s best to follow standards and best practice – most of the time – if only so you can avoid confrontation with the high priest of architecture (aka the Chief Architect). What’s right and what’s good is always worth the debate though – and a pint or two helps to lubricate the argument…

 

Comments

Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.