You're in The Right Room Solutions.NET vs. Java at a major insurance company Choosing among 8 key management vendors Critical application rearchitecture effort Business decisions Selecting a best-fit partner for a new venture System design Functional decomposition for a cross-organization service-oriented application Standards Company-wide portal platform at a major financial services company Naming standards at VistaPrint
Definitions Sorry, but … Architecture Architecture represents the set of earliest design decisions Hardest to change Most critical to get right Architectural decision
Quality There is no universal goodness Communicating with the business is the key
Quality There is no universal goodness Communicating with the business is the key -ilities are too coarse
Motivation Architecture is a system blueprint Architecture is a project blueprint But most important: Quality manifests in the architecture
Motivation We want to make good decisions early Reduces risk Ensures we don’t build the wrong thing How do architectural decisions get made?
Motivation We want to make good decisions early Reduces risk Ensures we don’t build the wrong thing How do architectural decisions get made? Debate The loudest/most patient/most senior voice wins
Some Background Questioning techniques Questionnaires and checklists Scenario-based methods Measuring techniques Quantitative assessments Metrics Simulations, prototypes, experiments Analyses
LAAAM Inspired by the Architecture Tradeoff Analysis Method from the SEI The process is flexible and adaptable Surprise, it’s supposed to be “lightweight” You don’t need to lock everyone in a room to make it work
It’s lam, it’s not lām
Method Outline Simple process Build a quality tree Rank at each node Figure out your alternatives Assess each alternative/scenario Let the tool do some math Think hard about the results But flexible! Start with what’s most important - quality
The Quality Tree A hierarchy of goodness Seed with commonly-important quality attributes Common templates Totally unrelated to the alternatives being considered The leaves of the tree are scenarios
An Example Quality Tree (A Silly One) Not done! Remember: the leaves are scenarios Quality (i.e. “Good”) PerformanceResponse TimeScalabilityMaintainabilityFlexibilityTrainabilityExtensibility
Scenarios -ilities make us feel warm and fuzzy This is an illusion Be precise! What does it really mean for a system to have “scalability”? Or “flexibility”? Context Stimulus Response
ResponseResponse StimulusStimulus ContextContext Example Scenarios Under normal operation perform a transfer transaction in under 100 milliseconds. For a new release, integrate a new component implementation within two days. The system network is partitioned and restored to normal condition; complete database resynchronization occurs within 30 minutes.
Scenarios in the Quality Tree Quality (i.e. “Good”) PerformanceResponse TimeScalabilityMaintainabilityFlexibilityTrainabilityExtensibility In steady state, a mailbox status update takes < 100ms. At peak load, a mailbox status update takes < 500ms.
Knowing What's Important
Knowing What's Important: Ranking Everything can’t be top priority – tradeoffs Ranking a list of scenarios is too hard So we rank each node in the quality tree
Example Rankings (Also Silly) Quality (i.e. “Good”) Performance (1) Response Time (2) Scalability (1) Maintainability (2) Flexibility (2) Trainability (3) Extensibility (1) (1) In steady state, a mailbox status update takes < 100ms. (2) At peak load, a mailbox status update takes < 500ms.
Scenario Weights Rankings produce a weight for each scenario Using rank order centroids Using a linear distribution Manually (a last resort!)
Rank Order Centroids Values Number of Options Rank
Rank Order Centroids (Really Silly) Quality (i.e. “Good”) Performance (1) -.75 Response Time (2) -.25 Scalability (1) -.75 Maintainability (2) -.25 Flexibility (2) Trainability (3) Extensibility (1) (1) In steady state, a mailbox status update takes < 100ms. W =.75 ×.25 ×.75 (2) At peak load, a mailbox status update takes < 500ms. W =.75 ×.25 ×.25
Building Consensus What’s the problem: everyone just agrees, right? Sometimes we need “tricks” to help build consensus Full federation and tricky (i.e. imperfect) math Voting
Better Example (But Harder to Read)
Alternatives What are your choices? Sometimes this is really easy: vendor A or B Sometimes this is really hard: design A or B
Evaluating For each scenario/alternative pair, evaluate Keep it simple Poor, fair, adequate, good, excellent works well And easy to turn into numeric values Comparing alternatives is ok, if you don’t cheat
The Result Assessment Matrix ScenarioWeight Alternative 1 Alternative 2 Alternative 3 Scenario PoorFairExcellent Scenario GoodGoodPoor Total (scores (scores × weights)
The Result Assessment Matrix ScenarioWeight Alternative 1 Alternative 2 Alternative 3 Scenario Scenario Total We have a winner!!
The Final Assessment Sensitivity analysis Persistent value in the artifacts
Caveats Cost is hard We’re reasoning about potential, not promise
Quality-Oriented Decision Assessment Credits to Gary Chamberlain Manager, Platform Architecture VistaPrint
Summary A robust definition of quality is key Architecture manifests quality Architectural decisions can be made rationally But there’s still no silver bullet
Sessions On-Demand & Community Resources for IT Professionals Resources for Developers Microsoft Certification and Training Resources Microsoft Certification & Training Resources Resources
Complete an evaluation on CommNet and enter to win!