10 Things Software Architects Should Know

1
10 Things Software Architects Should Know
Eben HewittBangaloreNovember 3-4, 2009
YOUR LOGO
2
goal

• Share ideas for current and would-be architects
• Inspired by the book 97 Things Every Software
  Architect Should Know

YOUR LOGO
3
who am i?

• Architect at a multi-billion dollar, fifty
  year-old US retailer
• Speaker on SOA at JavaOne, others
• Interviewed on SOA by InfoQ
• Author of 5 books including Java SOA Cookbook
  (OReilly, 2009)
• Contributor to 97 Things Every Software
  Architect Should Know
• Technical Reviewer for multiple books including
  upcoming RESTful Web Services Cookbook
• Many certifications in Java, Web Services, TOGAF
• I kitties
• Follow me at twitter.com/ebenhewitt or
  ebenhewitt.com

YOUR LOGO
4
what is the OReilly 97 Things Book?

• Written by four dozen software architects
• Contributors include Gregor Hohpe, Bill de hÓra,
  Neal Ford, editor
• Richard Monson-Haefel
• Written under open source model
• Other books in the series for programmers and
  project managers

YOUR LOGO
5
What is Architecture?
6
Fieldings Definition of Software Architecture

• A software architecture is
• an abstraction of the runtime elements of a
  software system
• during some phase of its operation.
• A system may be composed of many levels of
  abstraction
• and many phases of operation, each with its own
  software architecture.
• A software architecture is defined by a
  configuration of architectural elements
• components, connectors, and data
• that are constrained in their relationships
• in order to achieve a desired set of
  architectural properties.
• --Roy T. Fielding

7
Gartners Definition

• Architecture is
• the process of translating business vision and
  strategy into effective enterprise change
• by creating, communicating, and improving
• key principles and models
• that describe the enterprise future state and
  enable its evolution.

8
Okay

• Abstraction
• Constraints
• Translation
• Properties Principles
• Enabling Evolution

9
Software Architecture is About Constraints
Trade-Offs

• Codify a design choice
• At the proper level of abstraction
• The design choice intends to produce good effects
• Scalability, Reliability, Cacheability, Security
• It inevitably comes with trade-offs
• Choose how you Compensate

10

• Translating Vision Strategy

11
Axiom 1

• Dont Be a Tech Bigot
• SOAP vs. REST, Ruby vs. Java
• James Joyce knew more than a dozen languages.
• He learned Norwegian just to read Ibsen.
• Nothing scales, everything scales
• Yes, Microsoft gets huge shipments of Macs

12
Axiom 2

• The Importance of Consommé
• Parse requirements language with a sieve
• They dont say what they mean
• They dont know what they are talking about
• They dont care
• They dont remember
• They arent necessarily analytic thinkers

13
Axiom 3

• Promote Context, Discourage Meaning
• The Im Just Saying Rule
• Make everything transparent and dumb
• Achieve by high cohesion and loose coupling
• Dont allow implicit rules
• Theyre what hairballs are made of
• Externalize business rules
• Allow interpretation of meaning later
• IT JMX
• System Listeners
• Business BAM dashboards
• Promote new ility Interpretability

14

• Creating Principles Models

15
Axiom 4

• Establish Publish Architectural Principles

• Principles depersonalize
• They direct decision-making

16
TOGAF Principle Example

• Name
• Common Use Applications
• Statement
• Development of applications used across the
  enterprise is preferred over the development of
  similar or duplicative applications which are
  only provided to a particular organization.
• Rationale
• Duplicative capability is expensive and
  proliferates conflicting data.
• Implications
• Depend on enterprisewide capabilities instead of
  local
• Not allowed to develop silos
• See http//www.opengroup.org/architecture/togaf8-d
  oc/arch/chap29.html

17
Axiom 5

• Programmer as Philosopher
• Math, okay
• Art, okay
• Architecture, okay
• Be a philosopher
• Search for Truth
• Language-intensive
• Conceptual clarity
• Formal methods, Systems
• Set theory

18

• Enabling Effective Change

19
Axiom 6

• Write Clueless APIs

Images Phillip Calçado, fragmental.tw
20
Axiom 7

• If IT doesnt deliver, the business will go
  around them.
• Excel, Access, Salesforce.com
• Now you have two problems

21

• Enabling Evolution

22
Axiom 8
All Fields are Green. All Fields are Brown.
23
Axiom 9
Youre Usually Moving the Problem. Move it
somewhere you like better.
24
Axiom 10
Quality is a Feature
25

• Bonus Round!
• A Few More Things

26
Axiom 11
Dont Be a Problem Solver
27
Axiom 12
Right-size Complexity
28
Axiom 13
Give Up Control (and Gain Power)
29
Axiom 14
Virtualize Yourself