Intellectual Honesty, Ivory Towers, pragmatism and other emotive phrases

This isn't just enterprise architecture. It's about architecture at lots of levels.

Like many posts, this all started with an innocent (hah, likely!) tweet and then became richer as people joined in. Here's the original. RT @SLSingh Bad Science by @BenGoldacre asks "Why don’t journalists link to primary sources?"  originally posted by @frodedanielsen (someone I have never met). At which point the irrepressible Alkes Buterman and Doug Newdick chimed in.
aleksb6Aleks Buterman

RT @seabird20 RT @SLSingh Bad Science by @BenGoldacre asks "Why don’t journalists link to primary sources?" http://bit.ly/hkcuY4 >>+1 < +42

19 MarFavoriteRetweetReply

dougnewdickDoug Newdick

@aleksb6 @seabird20 how many #entarch are @SLSingh and @BenGoldacre fans?

19 MarFavoriteRetweetReply

But then Aleks posed the hard question... @seabird20 @dougnewdick I'm a big fan of intellectual honesty (#popper) but isn't that easily confused for "academic" #entarch?

That's what got me to this point - and it made me reflect on framing - using language that manages to demean an "opponent" while at the same time boosting your own value. "academic" is just one such word. Often used by teams that are under great pressure to meet a deadline and seeing that deep analysis could extend the time to delivery, demolish some closely held beliefs, make them look stupid because they forgot something. Use in context, "oh you are architects are so academic, that isn't a concern". While others will be thinking ("yet but it will become one..."). Of course the opposite word, used by those not wishing to do deep analysis is "pragmatic". We have a pragmatic solution.... Thus cutting off possible debate/discussion.
Architects can (and should) find themselves in a difficult position here. They (we) must be seen to be taking the side of pragmatism, and yet ensure that the teams are not taking on excessive technical debt. We need to be asking the important questions around operability of the system, its performance and availability envelope, its need for flex when it is used in unanticpated ways. remembering of course that solutions get used in unexpected ways and in unanticipated quantities.
Make sure we use data and data values to describe the system envelope. How many users? How many transactions? How many transactions per second? What is the reliability/bandwidth of the communication path? What does it cost per transaction to use an external service? What if that service is not available? Can the system be unavailable for 1 minute, 5 minutes, 1 hour...? What does it cost to use a "pet" technology? and so on. Otherwise known as the -ilities. Sometimes called non-functional requirements, but I would argue that they are quivalent to functional requirements. If these are not met you don't have a functional system.

In VPEC-T terms this is a classic conflict of values. The EAs are charged with the rather nebulous protection of the future. The project teams are charged with getting value out there fast. Those value systems are fundamentally at odds. So as architects we have the responsibility to be scrupulous in our questioning, demand the data that supports the project's assertions of cost/risk/time to market. Finally those that write the checks have to decide.
What we architects must not do is put up wooly, ivory towered thinking to prove how clever we are, how stupid everyone else is, how the world will come to an end if the solutions are not developed the way we dictate. We must not be sowers of fud, but analysts of relevant data.

Decisions under uncertainty

What data do we use to make decisions? Do we rely on the most up to date information possible? Do we use rough approximations? How do we reason about our decision thinking. Taking a concrete example first, I will then look for further insights and, of course, solicit comment.
My favorite example of decision under uncertainty is when I am making a purchasing decision and paying for the purchase by check (cheque!). I want to have some degree of certainty that the check will clear, so I have several strategies at my disposal.

1. Call the bank, tell the bank that I have a particular purchase to make, give the intended cheque number and amount and get some kind of a gurantee that the check will clear (even if my expected paycheck deposit bounces).
2. Call the bank/go to an ATM or whatever, get the current (available) balance, find out which payments/deposits have already cleared and satisfy myself that there is enough for the check I am about to write
3. Call the bank/go to the ATM or whatever and get the currrent balance, ensure it is enough to cover the check I am about to write
4. Look in the check ledger (or home accounting system) and satisfy myself that the balance is sufficient.
5. Assume that because I have checks left, I must have money.

Well I was just kidding about #5. These choices all have some degree of risk (from very little risk in #1 to significant risk in #5). But which one do we choose, and why? I suspect it has a great deal to do with how we perceive the risks. So, for example, if I were working for a large company with a great history of making payroll, the likelihood of a pay check bouncing is very low, so I will act confidently and perhaps take any of the choices 2, 3, 4. However working for an underfunded startup, I may well choose 1. There are lots of other variables in here too. How much does the bank charge for bouncing a check - vs the value of the check. How much reputation (aka credit report) damage might I suffer, etc. So I make a decision. But except in case 1, the decision is somewhat uncertain.

In our daily lives, we constantly act on imperfect data, but we use our experiences to guide us. I am pretty sure that my socks will be in the sock drawer, so will go there first. But if they are in the laundry - I might have to take a corrective action, the risk is low, the actual impact is low, so I will go to the drawer first. Oh, and no, I don't consciously do the risk analysis of every small thing - that would be very counter productive. That's why we have experience! We can act without consciously managing trivial risk.

Now moving into information systems, things look a little different - but should they? We attempt to limit risk of doing the wrong things (including being gamed by clever risk expoitation) by using tight centralized control (aka databases of record, single points of truth, etc.) However, these kinds of systems are inherently fragile. They are also more unreliable than we think. The value of any piece of data  is only valid at the time we request it unless we wrap the request with explicit transaction boundaries. But then if we have to serialize access to data every time we want to use any of it, everything would gum up and come to a grinding halt. So we always use approximations

The "trick" is to realize that you are always retrieving an approximation, realize that much decision making can be relegated to a system of reference, but that when making changes you must affect the system of record. And when affecting the system of record we do need transactions! Transactions give us the "truth" at that moment. The decision to change the "truth" is however very often made on approximations. This isn't bad - it's reality. Of course we can contrive situations where we have to have "truth" just as in my example 1 above, but those cases are more rare than we imagine.

It then becomes an architectural and design principle - what source do we we use in order to make decisions? How does the system of record react when attempts are made to update it based on out of date information? That all plays into the Values and Trust axes relevant to that decision making.