SEI
The
so(ware
architecture
of
a
program
or
compuFng
system
is
a
depic(on
of
the
system
that
aids
in
the
understanding
of
how
the
system
will
behave.
So(ware
architecture
serves
as
the
blueprint
for
both
the
system
and
the
project
developing
it,
defining
the
work
assignments
that
must
be
carried
out
by
design
and
implementaFon
teams.
The
architecture
is
the
primary
carrier
of
system
quali(es
such
as
performance,
modifiability,
and
security,
none
of
which
can
be
achieved
without
a
unifying
architectural
vision.
Architecture
is
an
arFfact
for
early
analysis
to
make
sure
that
a
design
approach
will
yield
an
acceptable
system.
MSDN
So(ware
applicaFon
architecture
is
the
process
of
defining
a
structured
solu(on
that
meets
all
of
the
technical
and
opera(onal
requirements,
while
op(mizing
common
quality
aCributes
such
as
performance,
security,
and
manageability.
It
involves
a
series
of
decisions
based
on
a
wide
range
of
factors,
and
each
of
these
decisions
can
have
considerable
impact
on
the
quality,
performance,
maintainability,
and
overall
success
of
the
applicaFon.
Len
Bass,
Paul
Clements,
and
Rick
Kazman,
So(ware
Architecture
in
PracFce,
Second
EdiFon
The
so(ware
architecture
of
a
program
or
compuFng
system
is
the
structure
or
structures
of
the
system,
which
comprise
soAware
elements,
the
externally
visible
proper(es
of
those
elements,
and
the
rela(onships
among
them.
“Externally
visible”
properFes
are
those
assumpFons
other
elements
can
make
of
an
element,
such
as
its
provided
services,
performance
characterisFcs,
fault
handling,
shared
resource
usage,
and
so
on.
—Len
Bass,
Paul
Clements,
and
Rick
Kazman,
So(ware
Architecture
in
PracFce,
Second
EdiFon
IEEE
The
highest
level
concept
of
a
system
in
its
environment
[IEEE].
The
architecture
of
a
so(ware
system
(at
a
given
point
in
Fme)
is
its
organiza(on
or
structure
of
significant
components
interac(ng
through
interfaces,
those
components
being
composed
of
successively
smaller
components
and
interfaces
RUP
The
organiza(onal
structure
of
a
system.
An
architecture
can
be
recursively
decomposed
into
parts
that
interact
through
interfaces,
rela(onships
that
connect
parts,
and
constraints
for
assembling
parts.
Parts
that
interact
through
interfaces
include
classes,
components
and
subsystems.
Philippe
Kruchten,
Grady
Booch,
Kurt
BiZner,
and
Rich
Reitman
Philippe
Kruchten,
Grady
Booch,
Kurt
BiZner,
and
Rich
Reitman
derived
and
refined
a
definiFon
of
architecture
based
on
work
by
Mary
Shaw
and
David
Garlan
(Shaw
and
Garlan
1996).
Their
definiFon
is:
SoAware
architecture
encompasses
the
set
of
significant
decisions
about
the
organizaFon
of
a
so(ware
system
including
the
selecFon
of
the
structural
elements
and
their
interfaces
by
which
the
system
is
composed;
behavior
as
specified
in
collaboraFon
among
those
elements;
composi(on
of
these
structural
and
behavioral
elements
into
larger
subsystems;
and
an
architectural
style
that
guides
this
organizaFon.
So(ware
architecture
also
involves
funcFonality,
usability,
resilience,
performance,
reuse,
comprehensibility,
economic
and
technology
constraints,
tradeoffs
and
aestheFc
concerns
Bass,
Clements,
and
Kazman
In
So(ware
Architecture
in
PracFce
(2nd
ediFon),
Bass,
Clements,
and
Kazman
define
architecture
as
follows:
“The
so(ware
architecture
of
a
program
or
compuFng
system
is
the
structure
or
structures
of
the
system,
which
comprise
so(ware
elements,
the
externally
visible
properFes
of
those
elements,
and
the
rela(onships
among
them.
Architecture
is
concerned
with
the
public
side
of
interfaces;
private
details
of
elements—details
having
to
do
solely
with
internal
implementaFon—are
not
architectural.”
Philippe
Krutchen
An
architecture
is
the
set
of
significant
decisions
about
the
organiza(on
of
a
soAware
system,
the
selecFon
of
structural
elements
and
their
interfaces
by
which
the
system
is
composed,
together
with
their
behavior
as
specified
in
the
collabora(ons
among
those
elements,
the
composiFon
of
these
elements
into
progressively
larger
subsystems,
and
the
architectural
style
that
guides
this
organizaFon
-‐-‐
these
elements
and
their
interfaces,
their
collaboraFons,
and
their
composiFon.
[Kruchten]4
MarFn
Fowler
MarFn
Fowler
outlines
some
common
recurring
themes
when
explaining
architecture.
He
idenFfies
these
themes
as:
“The
highest-‐level
breakdown
of
a
system
into
its
parts;
the
decisions
that
are
hard
to
change;
there
are
mulFple
architectures
in
a
system;
what
is
architecturally
significant
can
change
over
a
system's
lifeFme;
and,
in
the
end,
architecture
boils
down
to
whatever
the
important
stuff
is.”
So(ware
Harmony
is
about
Conceptual
Integrity
Anywhere
you
look
in
your
system,
you
can
tell
that
the
design
is
part
of
the
same
overall
design
style,
theme,
mood
…is
about
Design
and
Style
Consistency
in
all
dimensions
of
the
system
Fed
Brooks:
“It
is
be0er
to
have
a
system...reflect
one
set
of
design
ideas,
than
to
have
one
that
contains
many
good
but
independent
and
uncoordinated
ideas”
User
interface,
technologies,
coding
styles,
naming
convenBons,
directory
structures,
classes,
components,
interfaces,
internal
and
external
behavior,
deployment…
Conceptual
Integrity
tries
to
limit
the
system
complexity
Conceptual
Integrity
simplifies
collaboraFon
when
creaFng
so(ware
The
Mythical
Man-‐Month
Conceptual
Integrity
examples
• Unix
• based
on
the
noFon
of
a
"file”
(e.g.
directories,
devices,
filesystems,
named
pipes
and
sockets
are
all
sort-‐of
files)
• Smalltalk
• "everything
is
an
object",
and
the
small
set
of
other
accompanying
principles
• SQL
• "all
data
is
in
tables",
with
keys
and
constraints
• Lisp
• "everything
is
a
list”
h0p://c2.com/cgi/wiki?ConceptualIntegrity
7
Dimensions
x
2*
of
a
So(ware
Work
where
Harmony
must
be
created
Process Dimension Deployment
Dimension Logical
Dimension External Dimension Implementation Dimension Solu%on
Vision
Classes,
Modules,
Design
Components,
Interfaces,
Interac%ons
So:ware
Mechanisms
Use
Cases
/
User
Stories
UX
Guidelines
Run%me
Processes,
Threads
Protocols,
Inter-‐process
Communica%on,
Integra%ons
Implementa%on
Structure
and
Components
Frameworks,
Libraries
Base
Technologies,
Programming
Languages
So:ware
Mechanisms
Infrastructure,
Hardware
and
Network
Topology
Data Dimension Environment Dimension Environments
Tools
Development
Process,
Methods
and
Prac%ces
Data
En%%es
Data
Messages
Logical
Physical
*STRUCTURE
and
BEHAVIOUR
Desired
AZributes
of
a
So(ware
Work
High
Cohesion
each
part/element
is
narrowed
focused
in
its
primary
task
Low
Coupling
each
part
is
self-‐contained/orthogonal
achieved
thru
separaFon
of
concerns
and
encapsulaFon
Conceptual
Integrity
there
is
a
consistent
design*
and
style
across
all
so(ware
dimensions
(*)
programming
is
design
Source:
“The
Art
in
Computer
Programming”,
By
Andrew
Hunt
and
David
Thomas
So(ware
Architecture
=
So(ware
Harmony
A
So(ware
Architecture
(Harmony)
is
the
set
of
significant
decisions
and
their
implementa(on
in
the
7
realizaFon
dimensions
of
the
so(ware
system
considering
structure
and
behaviour
dimensions
in
each
one
with
the
purpose
of
achieving
conceptual
integrity,
low
coupling
and
high
cohesion
The
So(ware
Harmony
is
Coded
So(ware
Mechanisms
(so(ware
soluFons
to
common
problems:
persistence,
IPC,
…
System
Skeleton
(interfaces,
base
components,
deployment
mechanisms
)
Prototypes,
Reference
soluFons
and
Proof
of
Concepts
(soluFons
to
significant
user
stories
or
technical
problems)
Base
frameworks
and
technologies
Base
Guidelines
and
Styles
…
Achieving
Conceptual
Integrity
FredBrooks:
"Conceptual
integrity
in
turn
dictates
that
the
design
must
proceed
from
one
mind,
or
from
a
very
small
number
of
agreeing
resonant
minds"
Aristocracy
vs
Democracy?
“TradiFonal”
So(ware
Architect
architect
derives
from
the
LaFn
architectus,
which
derives
from
the
Greek
arkhitekton
(arkhi-‐,
chief
+
tekton,
builder),
i.e.,
chief
builder
So(ware
Harmonist
=
Technical
Leader
or
Development
Leader
• Keeps
Conceptual
Integrity
and
Unity
across
the
system
and
teams,
while
limiFng
complexity
• Retains
the
final
say
in
technical
disputes
or
arguments
within
the
team(s)
Small
teams
with
resonant
minds
could
not
need
an
specific
tech
leader
From
IntenFonal
to
Emerging
Initial team Agile Project Kickoff Management team Architecture team time Initial project team Prototyping team I1 I2 I3 Initial team Agile Project Kickoff Management team Architecture team time Initial project team Prototyping team I1 I2 I3 Feature 1 Team Feature2 Team Infraestructure Team I4 I5 Prototyping team • IntenFonal
harmony
(architecture)
is
explicitly
idenFfied
and
then
implemented
• Accidental
harmony
(architecture)
emerges
from
the
mulFtude
of
individual
design
decisions
that
occur
during
development,
only
a(er
which
can
we
name
that
architecture
Process Dimension Deployment ( Dimension Logical( (Dimension External Dimension Implementation Dimension Classes,'Modules,'Design'' Components,'Interfaces Use'Cases'/'User'Stories' UX'Guidelines' Run=me'Processes,'Threads'' Protocols,''InterAprocess' Communica=on' Implementa=on'Structure' and'Components' Frameworks,'Libraries' Base'Technologies,' Programming'Languages Infrastructure,'Hardware'and' Network'Topology' Data Dimension Environment Dimension Environments' Tools' Development'Process,' Methods'and'Prac=ces' Data'En==es' Data'Messages' INTENTIONAL
EMERGENT
GROWING
So(ware
Harmony(architecture)
is
Elaborated,
Built,
Used
and
Executed
Architecture=Harmony
is
created
as
set
of
subopFmal
design
decisions
that
can
be
re-‐factor
later
on
SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8 Sprint0 SP9 Building
the
Harmony
Using
Building
….. Using
IntenFonal
Emergent
IntenFonal
Emergent
The
Dilemma
Solu%on
:
Assuring
Conceptual
Integrity
via
Capacity
Alloca%on
to
architecture
=
Harmony
Source:
Dean
Leffinweel
,
h0p://scaledagileframework.com/guidance/assuring-‐architectural-‐integrity-‐via-‐capacity-‐ allocaBon/
_rubengb
yonetty
syukai
ryounasso
parttimenerd
codehex
manfredsteyer
yusukebe
ivargrimstad
chimame
kishida
skanehira
.png){kind=avatar}
melonattacker
tmm1
keavy
matthewcrist
eitanlees
bluesmoon
quramy
bermonpainter
morganepeng
jponch
aleyda
bryan
marktimemedia