You can’t get an ought from an is.  This famous concept from the great Scottish philosopher David Hume (1711–76) has interesting implications for Enterprise Architects.  Hume observed that people seem to derive what ought to be done by citing facts about what is, yet logically there seems to be a gap, and there must be some other point of reference.  As Enterprise Architects we need to inspect this other point of reference rather than just accepting it.

science to the rescue, or not?

In philosophical terms, Hume’s concept originally related to a field now called Meta-ethics.  We won’t spend too long on the ethical side here, but to clarify what we mean by this ought-is problem, consider the highly charged issue of pro-life vs pro-choice (trying not to take a moral position).  Often each side will look to medical facts to validate their position, however, these facts typically need some other guiding ought; science alone cannot conclusively resolve the issue.  For example, one theory is that up until the time that there is brain activity, which can be determined by science, there is no person, therefore no right to life.  But the fact about brain activity still requires some other judgement or rule to say that no brain activity means we ought not to consider them, or it, a person (putting aside the being a person therefore equals a right to life position).  There is a theory that we intuitively determine what feels right, then determine the ought statements to fill the logical gap that makes this correct; this intuition may be driven by religious beliefs, libertarian beliefs, social peer influences, or from some unknown point of reference.

Why would I pick such a controversial example?  The pro-life vs pro-choice debate is perhaps the most polarizing debate in recent human history, and also one where most people can feel their intuition in the driver seat.  This is also an area where ambiguity cannot be accommodated as the lawmakers must pick a position.  As stated by a giant in this field, Baroness Warnock, the law [in the West at least] requires precision more than it requires accuracy.  You can’t get an ought from an is, yet that is what you must do to determine a legal rule of law.

Photo by Carolmooredc, acquired from Wikimedia Commons

back to safer ground

The key here is that in many situations we intuitively determine what is right, then reverse engineer the ought statements to fill the logical gap that makes this correct.  We are also remarkably efficient at finding evidence that our intuition is correct.  This has been well documented by the likes of the Nobel Prize winning psychologist Daniel Kahneman (recipient of the 2002 Nobel Memorial Prize in Economic Sciences).  Relying on intuition is not necessarily a bad thing; it has largely been responsible for our success as a species, along with opposable thumbs of course (try operating your iPhone without using your thumbs).  However it does expose us to bias (again not always a bad thing).  Compounding this, we now have well intended search engines and personalisation algorithms that are very good at showing us what we want to see (to keep us engaged), which is what will confirm that we are indeed correct.

a principled solution, or not

As Enterprise Architects we like to believe we are unbiased and base our guidance on facts, however as we have seen above, facts alone cannot get us to a determination.  We need some other reference to get us from the fact (is), to the guidance (ought).  Mostly as architects we seek to bridge this logic gap by defining architectural principles.  These principles are themselves ought statements (thou ought to loosely couple thy systems).  We can be prone to determining principles out of context so they ‘feel’ safe in their abstraction.  We then kind of forget we did this when we apply them.  This bridges the is-ought gap.

“I am a man of fixed and unbending principles, the first of which is to be flexible at all times” – Everett Dirksen

Years ago working as a Data Architect I remember explaining to people that certain logical or physical models didn’t ‘feel’ right.  It would be hard to put your finger on it, but you just knew from experience that it wasn’t right.  Sometimes models would adhere to the normalization rules (I miss sub-typing), but just didn’t ‘feel’ right, and often a bit of denormalization would do the trick.  Sometimes accuracy does matter more than precision if architects want to be trusted advisers rather than pedantic lawyers (I’d assume here that being pedantic is a useful trait for a lawyer, just not for an Enterprise Architect).

Architectural principles have their place perhaps, but we need to use them carefully as rules of thumb, and not principled positions to defend.  Often architectural principles are used as a way to justify what good looks like, rather than relying on good judgement.  A better approach might be to consider the desirability of certain architectural characteristics within the context of the solution being provided.  For example you may have a buy before build principle, and a lose coupling principle, but many COTS packages can put these two at odds.  It might be more useful to have guidance that we need to determined if the characteristics of interchangeable components are more important than characteristics of prefabrication within the specific context.