This document discusses various heuristics and principles for architecture design. It provides guidelines for creating simplified, evolvable systems using small modular components. Some key points discussed include using open architectures, building in options, and designing structures that are resilient to stress. The document also advocates for pattern-oriented, minimalist designs and evolutionary systems that can adapt over time without disrupting existing information. Overall, the document presents best practices for handling complexity, enabling flexibility, and ensuring architectures can withstand failures.

1. Architecture in action !
Krishna
Sankar
@ksankar
May
7,
2007

2. u Architecture
Succeeds
!
• Quietly
!
Thanks to Chris Wiborg for this observation ….

3. Architecture - Heuristics
u Simplify
• Not
monolithic
systems
but
building
blocks
u Design
the
structure
with
“good
bones”
• Resilient
to
a
wide
range
of
stress
and
usage
patterns
• Internet
:
Constant
assembly
line
with
no
central
point
of
control
• Build
in
and
maintain
options
• Use
open
architectures
u Implementation
matters

4. Architecture - Heuristics
u Build
Evolutionary
systems
• A
system
will
develop
and
evolve
much
more
rapidly
if
there
are
stable
intermediate
forms
than
if
there
are
not
• Old
information
need
not
change
to
have
new
models
• Resolve
ambiguity
&
clarify
/
trap
inconsistencies
at
the
message
layer

5. Architecture - Heuristics
u Use
Pattern
oriented
architectures
• EJB
• General
patterns
• Real
time
patterns
u Software
reflects
the
creators
u Architecture
is
a
“network
good”
• i.e.
adds
value
as
the
users
increase
(like
a
network
of
computers
or
telephones)

6. Architecture - Heuristics
u Minimalist
design
u Build
larger
things
out
of
small
things
• Bigger
programs,
larger
number
of
bugs
• Opportunities
for
wide
open
channels
• Model
after
cells
and
bricks
!
u Generic
appliances
which
can
dynamically
take
different
roles
depending
on
the
state
of
the
network
• E.g.:
Denial
of
attack
:
Lots
of
packet
filtering
functions

7. Architecture - Heuristics
u Web
of
trust
rather
than
single
point
trust
u All
information
is
processed
under
multiple
trust
contexts
u Application/Domain
Level
Security
:
Not
point
to
point
u Defense
in
Depth
principles
• Not
rely
on
one
layer
or
one
device
for
protection
and
information
accuracy
• Multi-­‐level
Security

8. Architecture - Heuristics
u Pervasive
Security
Architecture
• Means
making
security
part
of
everything
and
not
making
it
its
own
thing.
• It
means
security
isn’t
added
to
the
enterprise,
it’s
woven
into
the
fabric
of
the
architecture
Courtsey : http://www.cio.com/research/security/edit/a072601_firewall.html

9. Architecture Methodologies
u Normative/solution
based
• Prescribes
the
“should-­‐be”
in
terms
of
standards,
codes
u Rational/method-­‐based
• Methods
and
processes
to
arrive
at
a
solution.
i.e.
check
lists,
ways
to
review,
SDLC,
…
u Participative
• Brainstorming/concurrent
engg
u Heuristics
• Patterns,
Thumb
rules,
old
tales,
fables,
…

10. Architecture is ….
u Politics
• EEF,
Mitch
Kapoor
u Disciplined
avoidance
of
value
judgments
• Client
–
desirability,
Architect
–
feasibility
• Pyramids
–
architected
not
for
burial,
but
show
of
political
&
religious
power
u Clear
avoidance
of
conflict
of
interest
• Who
benefits
?
Who
pays
?
Who
provides
?
Who
loses
?
u Arms-­‐length
relationship
with
project
management
• But
be
very
aware
of
project
responsibilities
• Need
to
architect
so
that
systems
can
be
built
within
the
project
constraints

11. Architecture is ….
u Policy
• What
you
can
do
is
strongly
correlated
to
how
you
are
connected
• If
we
make
wise
choices
in
architecting
our
systems,
long
before
they
have
millions
of
users,
their
architectures
become
the
firm
foundations
on
which
subsequent
systems
are
built
u Paraphrasing
John
Gilmore

12. Architecture is ….
u Freedom
• From
mundane
things
so
that
the
programmer
can
concentrate
on
the
problem
at
hand
!
u Flip
side
• Enabling
Vs
restriction
u Framework
can
be
very
intelligent
or
very
dumb/pass-­‐
thru
• Architecture
and
it’s
artifacts
are
choke
points
–
deliberate
or
not

13. Architecture is ….
u Handling
Complexities
• Abstract
Essential
Complexity
u Cannot
avoid
domain
complexity
• Avoid
Accidental
Complexity

14. Architecture is …..
u Not
an
isolated
event
• But
a
product
line
u Act
like
a
software
company
• Road
map
• Articulated
feature
set
• Deliverables
• User
feedback
and
influence
u Need
to
reflect
this
in
the
process,
representation
and
the
artifacts

15. Architecture has
u Deliverables
• Have
a
clear
vision
of
whom
the
results
are
for
• Managers
–
fluffy
slides
u “If
you
can't
explain
it
in
5
min,
either
you
don’t
understand
it
or
it
doesn’t
work”
• Architects
u Play-­‐book,
Framework,
Principles
• Developers
u API
Docs,
Examples

16. Architecture has
u Timeframes
5 years Vision
2 years Strategy
1 year Tactical Plan
6-9 months Operational
Thanks to Greg Giles for this observation ….

17. Roles & Responsibilities
u Architect
Vs
Engineer
Vs
Builder
u Different
View
points
u Important
to
realize
which
hat
you
are
wearing

18. An Architecture is not optional
Some
are designed
and some
just happen
But it’s there
and it affects the efficiency of the product
Every product already has an Architecture

19. u Byzantine
failure
• Assume
the
component
fails
&
• Does
the
worst
possible
thing
• To
the
system
u Ariane 5 disaster (1996)
u Dual redundant system
• Main system failed
• Switched to the backup system (which already had failed
due to the same cause)
• Cause – Conversion 64 bit to 16 bit integer
u Code left over from Ariane 4 which was never reqd in 5 but
reqd in 4, but only till lift off - 9 seconds. But they continued
the calculations lift off+50 seconds :o(
http://www.around.com/ariane.html
http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

20. Challenges
u Not
just
new
technology,
but
performance
measurements
&
reward
system
u Incompatible
applications
would
not
magically
become
compatible
with
the
web
services
fabric
(Mark
Day,Cisco
Systems)
u Technical
standards
need
not
translate
to
successful
business
models/enablers

21. Challenges
u Do
we
have
a
long
term
shared
vision
of
the
IT
&
Business
Architecture
?
u Can
we
balance
new
architecture
&
business
impact
?
u Are
we
moving
fast
enough
to
build
expertise
&
exploit
inter-­‐company
processes
?
u Do
we
have
a
clear
understanding
of
organizational
inertia
and
have
a
plan
?
u Are
we
providing
sufficient
leadership
to
vendors
and
standards
?
Courtsey : HBR 10/01

22. Reuse ?
u Is
there
an
incentive
for
developers
to
build
components
for
reuse,
even
though
it
may
take
longer
and
be
more
expensive?
Remember
that
the
value
of
this
approach
is
being
able
to
reuse
the
components
the
second
and
third
time,
not
the
first
time.
u Are
project
managers
&
functional
managers
compensated
based
on
how
much
reuse
they
are
able
to
employ
in
their
solutions?

23. Reuse ?
u Are
developers
rewarded
for
reusing
components
in
their
solution?
u Has
a
central
body
taken
ownership
of
reusable
components
so
that
they
can
be
available
and
leveraged
by
other
groups?

24. Architecture needs support …
u To
gain
and
retain
skills,
we
need
three
things
:
1. Acquire
the
skill,
2. Be
exposed
to
the
skill
being
practiced
3. Opportunities/motivation
to
practice
the
skill.
u The
Arch
forum
should
provide
1)
and
2).
u 3)
should
come
from
Sr.Staff
and
the
rest
of
the
management
team.

25. Break !

26. PROPRIETARY MATERIAL -
DELETED

27. References
u [1]
The
Art
of
Systems
Architecture
:
Mark
W.
Mainer
et
al
u [2]
Design
&
Use
of
Software
Architectures
:
Jan
Bosch
u [3]
The
Future
of
Ideas
:
Lawrence
Lessig

28. Questions ?

29. Questions
?