Reasoning for ArchitectsMiha Kralj

Argument Structure

Think of assumptions as the glue that holds the evidence to the conclusion.

Argument: a claim (or conclusion), supported by evidence.

AssumptionEvidenceConclusion = +

What is not an Argument

Don’t waste energy trying to win debate on non-arguments.

Assertion: Separation of concerns is key SOA principle.

Statement: Zachman said, “focus on Why, How, What, Who, Where and When.”

Explanation: Because there was not enough time, the design is less than optimal.

Opinion: TOGAF framework is a waste of time.

Identifying the Conclusion and Evidence

Think of assumptions as the glue that holds the evidence to the conclusion

Conclusion:

As a result…Clearly…Consequently…Hence…In conclusion…Therefore…Thus…So…

Evidence:

As indicated by…As shown by…Because…For…Since…Given that…As…The reason is that…

Evaluating the Argument

Best practice: make assumptions explicit and write them down

Testing the EvidenceTesting the Assumption

As this PoC in the cloud works really well, cloud computing is surely the right strategy for your company!

This is the most innovative cloud platform; there are more apps currently built on this platform than on any other cloud technology.

Reasoning Flaws

Most Common Reasoning Flaws

Flawed reasoning turns architecture into marketecture!

Over-genralizatio

n

PoorAnalogy

SelectivePerception

Wrong Causality

Ignoring the

Evidence

Selective Perception

Architects should not be influenced by stereotypes, prejudices or preconceived notions.

Tendency to see the world the way we would like it to be rather than how it really is.

We came in, saw the root cause of problems and rapidly deployed our standard offering that was the most efficient solution for them. Competition was stunned!

They didn’t listen, had a preconceived view of the problem, deployed a canned solution and thought we were happy. We will never call them back again!

Poor Analogy

Advice: meaning and scope of words and terms in arguments must be consistent.

Comparison of items made on the basis that they share some similarities

Why go with such radical design change? What worked in the past will work in the future!

She did such a great job as a delivery architect that we’re going to promote her to an architect manager!

Representativeness Assumptions

Don’t test if a sample is large enough – test if it is diverse enough.

A sample should be a valid representation of the larger group (population)

We virtualized all web servers with no problems, so we can proceed with virtualization of the whole datacenter. (statistically accurate?)

I highly recommend this IT vendor - on two projects that they were engaged on, they were really good. (anecdotal evidence?)

Selecting “Good” Evidence

Slanting the evidence is the most common reason for broken advisor relationships

Choosing relevant evidence that supports our stance while ignoring refutable ones.

All our case studies show very strong ROI when moving applications to the cloud!(do we publish ones with bad ROI?)

As a technical reviewer, I can say that every project without strong risk mitigation plan fails!(how about projects that didn’t go through technical review?)

Causality Assumptions

Mixing correlation with causation is the most common reasoning flaw in architecture

Incorrect identification of coincidence, correlation or causation of two events

CIO left the company just before our project was cancelled. Therefore, CIO departure caused us to lost the engagement. (coincidence or correlation?)

He is a hard-working architect. No wonder he gets the toughest assignments in his sector! (reverse causation?)

Techniques

Convergent vs. Divergent Thinking

Use convergent thinking for analysis. Use divergent thinking for innovation.

Divergent:

Opens the mindFloodlight thinkingHolistic and diffusedCreative approachInnovative and emotional mindsetSynthesis

Convergent:

Focuses the mindSpotlight thinkingSequence and orderAnalytical approachLogical and scientific mindsetClassification

Thinking-killers and Thinking-growers

Thinking-killers prevent commission errors but encourage omission errors.

Growers:

Are there any questions?What would happen if…Why is this relevant?What have we missed?Wouldn’t it be fun if…What idea have you come up with?Thank you

Killers:

We tried it beforeThat’s not the job of an architectThat’s not how we do itThat sounds crazy to meThis is not importantThat’s a stupid ideaNo

Pros-and-Cons Analysis

Architects often fall into a fallacy of false dilemma when doing Pros-and-Cons analysis

Middle viewContra sidePro side

The Devil’s Advocate Technique

Architects use the devil’s advocate technique to impose objectivity

Approach of advocating an opposing or unpopular cause for the sake of argument or to expose it to a thorough examination

What would an architect from competitor say if they’d see this design proposal?

So, is it true that this solution would work better/faster/cheaper if we’d use competitor’s product?

Prisoner’s Dilemma

The Prisoner’s dilemma is an example when cooperation is superior to competition

Partner cooperates

Partner doesn’t cooperate

I cooperate with partner

I win a little,partner wins a little

I loose,partner wins

I don’t cooperate and do my thing

I win,partner loses

We both lose big time

Mixed-motive game: both parties can do well if they work together by cooperating or can try to gain an advantage by competing

Fallacies

Fallacies Based on Language

Equivocation:Mainframe is better than nothing. Nothing is better than cloud computing. Therefore, mainframe is better than cloud computing.

Distinction without a difference:We didn’t miss the milestone. We just stretched it for a week.

Amphibology:We will waste no time reviewing the reference design.

Fallacies Based on Bad EvidenceHasty Generalization:

I tried to implement SOA three times and each time it was a disaster. SOA is terrible!

Circular Reasoning:Architects do only architecturally-relevant things. Architecturally-relevant things are what architects decide to do.

Negative Proof:No customer complained about knowledge of our consultants, so we are confident that we are offering more than enough technical readiness.

Ad Hominem:How can you let this architect do the design? He is not even certified!

Fallacies Based on Bad Evidence

.

Poisoning the Well:You are not credible in EA – you are from a country/region where nobody knows how to do EA!

Tu quoque:How can you say that I shouldn’t use TOGAF? You are using it all the time!

Red Herring:You have hard time analyzing requirements? When I was your age, we had to use paper and pencil to perform proper analysis!

Ad Antiquitatem (appeal to tradition):We always used this framework since 1998 – there is no need for a new one.

Fallacies Based on Bad EvidenceAd Verecundiam (appeal to authority):

Our Chief architect says he likes it, so it must be good!

Ad Populum (appeal to public opinion):Everybody that I asked agreed that encryption is not required in our case.

Ad Misericordiam (appeal to pity):They will fire me unless you approve this work order!

Ad Metum (appeal to fear):You don’t want to know what will happen if you allow iPads to connect to that environment.

Fallacies Based on Flawed AssumptionsFalse Alternatives:

You either move IT to the cloud or you waste money with your datacenter.

Golden Mean:Agile was too risky, waterfall was too slow so best for us is a hybrid agilefall methodology

Fallacy of composition:Joe is a great consultant. Frank is a great architect. They will make a great team!

Fallacy of division:This team performed really well, therefore everyone in this team was a great performer.

Fallacies Based on Flawed AssumptionsFallacy of the Continuum:

Win 3.1 was good, Win 95 was good, Win XP was good – therefore Vista was good too!

Incorrect attack on generalization:Really, Windows is good OS? My mother can’t do a single thing with it!

Distortion:What you are saying is you don’t care about architecture and only want deployed solution!

Fault Analogy:We are both architects and PMs. You are a good architect, therefore you must be good PM.

Fallacies Found in Deductive LogicAffirming the Consequent (if A, then B -> if B, then A):Whenever I work on an engagement, I write a lot. I write today, therefore I must be on an engagement.

Denying the Antecedent (if A, then B -> if not A, then not B):Whenever that partner is involved, things are difficult. This time partner is not involved, so everything will run smooth as.

Argumentation

Packaging the Response

A fool with a tool is still just a fool.

Using flawed arguments as an advantage

Allow graceful retreat and correction

What would you say if you’d be a

lawyer?

Why Should I care?

Doubt everything.

Critical Thinking

enables bullet-proof

conclusions

Skepticism distinguishes

architects from

marketeers

Reasoning is the strongest tool architect can master

Argumentative Logic

helps you with traceability