Академический Документы
Профессиональный Документы
Культура Документы
software architecture,
technical leadership and
the balance with agility
(I code too)
10
Buy the book for $
YI85bLbAXGks 2013)
(expires 30th March
S t r u c t u r e
fi ni ti o n o f s o m et h ing in te rm s and
The de
it s c o m po ne nt s an d in te ra c ti ons As a verb...
of
Vision
The process of architecting,
making (significant) design dec
isions, etc
What is design?
by cost of change.
r e f a ct o r
Ca n y o u
Grady Booch a f t er no on?
it in an
http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog&part=2006
Chaos!
Does the team understand what they are building and how they are building it?
No defined structure,
inconsistent approaches,
Chaos!
big ball of mud,
spaghetti code, ...
STOP
Does the team understand what they are building and how they are building it?
TL; DR
Document
Shared vision of
WTF?!
The software
architecture role
The software architecture role is
different
to the lead developer role
a n i n w a r d and
It’s
d f a c i n g r o l e
outwar
It’s about the
big picture
Abstract Specific
Lines of code
Classes, functions
As software developers, the Design patterns
Unit tests
code
Refactoring
Lines of code
Classes, functions
Sometimes you need to Design patterns
Unit tests
step back
Refactoring
% of
Don’t code 100
e t im e t h o u gh !
th
Would we
code
it that way?
All decisions
involve a
trade-off
Should software architects write
code
on software projects?
y y e s, b ut . . .
Ideall
Software architects
must be
master builders
din g is a g r e a t way
And co
r e t a in t h is s k ill
to Plus it reduces man
y of the
problems associated
with
ivory tower architec
ture
Generalising
Specialist
Breadth
Broad knowledge of
patterns, designs,
approaches, technologies,
Depth non-functional requirements,
different ways of working, etc
Deep hands-on technology
skills and knowledge ...
options and trade-offs
Every software
development team
needs a
master builder
1 or many
Software architecture is about
technical
and
soft skills
Leadership
Communication
Influencing
Negotiation
Collaboration
Motivation
Facilitation
Political
The irresponsible architect
No documentation; ...
Even on
t e gic p l a t f o r m ”
“stra
projects :-o
The software architecture role
Architectural Technology
Drivers Selection Architecting
Designing software
Understanding requirements Choosing and evaluating
and constraints technology
Architecture Architecture
Coding
Evaluation Involvement in the hands-on Evolution
Understanding that the elements of software delivery Ownership of the architecture
architecture works throughout the delivery
control ?
Let’s agree
on some things
Chaos! Let’s ma
k e th e
i
i
t
m licit,
Does the team understand what they are building and how they are buildingpit?
ex pl i c
Put some boundaries
and guidelines in place
Control
Guidelines, consistency,
discipline, rigour, boundaries,
...
Software Architect
Feedback
“I don’t understand why...”
“How should we...” Software Developers
“I don’t like the way that...”
Sits in an ivory tower
Architect
Focusses on the
low level detail
Gap
1. Current Situation
We have an existing Internet Banking offering that allows customers to securely view
information about their bank accounts held with us via the web. Although we were one of the
first to market with such a product, the system itself is a number of years old now and a series
of problems has been identified during a consulting exercise that we recently initiated. In
summary:
• The system only provides customers with read-only access to information about their
bank accounts. This includes account balances, recent transactions and recent
statements.
• The information presented to customers is slightly out-of-date, because information from
the core banking system is exported to the website on a nightly basis.
• Transactional requests are not possible through the site, with customers instead sending
a secure message to the call centre with their request instead. This process is open to
abuse and fraud.
• The number of features supported by the offering is limited.
• The technology is no longer seen as “leading edge”, is hard to enhance and costly to
maintain. In addition, the technology has reached “end of life” and is no longer
proactively supported by the vendor.
• The system doesn’t meet current website accessibility standards.
In a recent survey, our Internet Banking system was perceived as poor in terms of the user
experience and the level of information available through the website. With our competitors
now offering fully transactional systems, there is a risk that we will lose business.
2. Vision
The board have given us the go-ahead to initiate a project to replace the current Internet
Banking system, which will need to coincide with the corporate rebranding that will be taking
place in 12 weeks. The replacement system should:
• Provide customers with real-time access to information about their bank accounts.
• Provide customers with the ability to perform common transactions through the website.
This includes making payments, setting up standing orders, transferring money and so on.
• Provide customers with a rich user experience.
• Meet current website accessibility standards.
• Be developed using the new corporate website design guidelines.
Options
ts
uir n -
en
req & no
em
nts
s
ple
rai
l
on na
nci
nst
cti tio
Pri
Co
al
fun Func
m e r , I
c u s t o
s i n es s n a g e
s a b u c a n m a
0 0 3 ) A h a t( I
0
( n s o t 0 9 ) A s a p
o l o gi e . e r so nal custom
wan t t o nwl iann e r I
ou n t s t t o d ownload s
n k a c c t a t e
m y b a t h e last thr ments for
ee months
.
M u st
y :
Priorit Priority: M
ust
sufficient
foundations
Software lives in the real world,
and the real world has
constraints
u al ly
e u s
s a r
r a i nt o u
s t n y
Con ed u p o
f o r c
Understand what the constraints are,
who imposed them,
why they are being imposed and
they’re realistic
and don’t have a
negative impact
Big Bank plc
Internet Banking System
1. Current Situation
We have an existing Internet Banking offering that allows customers to securely view
information about their bank accounts held with us via the web. Although we were one of the
first to market with such a product, the system itself is a number of years old now and a series
of problems has been identified during a consulting exercise that we recently initiated. In
summary:
• The system only provides customers with read-only access to information about their
bank accounts. This includes account balances, recent transactions and recent
statements.
• The information presented to customers is slightly out-of-date, because information from
the core banking system is exported to the website on a nightly basis.
• Transactional requests are not possible through the site, with customers instead sending
a secure message to the call centre with their request instead. This process is open to
abuse and fraud.
• The number of features supported by the offering is limited.
• The technology is no longer seen as “leading edge”, is hard to enhance and costly to
maintain. In addition, the technology has reached “end of life” and is no longer
proactively supported by the vendor.
• The system doesn’t meet current website accessibility standards.
In a recent survey, our Internet Banking system was perceived as poor in terms of the user
experience and the level of information available through the website. With our competitors
now offering fully transactional systems, there is a risk that we will lose business.
2. Vision
The board have given us the go-ahead to initiate a project to replace the current Internet
Banking system, which will need to coincide with the corporate rebranding that will be taking
place in 12 weeks. The replacement system should:
• Provide customers with real-time access to information about their bank accounts.
• Provide customers with the ability to perform common transactions through the website.
This includes making payments, setting up standing orders, transferring money and so on.
• Provide customers with a rich user experience.
• Meet current website accessibility standards.
• Be developed using the new corporate website design guidelines.
Options
ts
uir n -
en
req & no
em
nts
s
ple
rai
l
on na
nci
nst
cti tio
Pri
Co
al
fun Func
Start analysing
coding
or start ?
r a l y s is ” &
pa
“Analysis c tor”
r d is t r a
“refacto
b o t h b ad
are
Bo xe s & lines
Thing
e r Th i ng
Ot h
m p o r t a n t l ine
I
Visualising
software
UML tool?
n e e d a U ML
You don’t ture
a r c h i t e c
tool to do tion
e o n n o t a
but agre
Whiteboard or
flip chart?
Collaborative design
(e.g. pair architecting)
NoUML
diagrams?
We can visualise our process...
not our
...but
software!
Moving fast (agility) requires
good
communication
System
Container
Container
Component
Class Class
Component Component
Class Class
Container
ts
2. Containers 3. Componen
1. Context
C4
e
the static structur
... and, optionally,
4. Classes
(runtime, infrastructure,
p lo ym en t, et c are also important)
de
Context
Containers
Components Thinking inside the box
Classes
Thisisn’t about
creating a standard
you
It’s about providing
e or g an is a tio n al id e as
som
• What are we building?
Context • Who is using it? (users, actors, roles, personas, etc)
• How does it fit into the existing IT environment?
• What are the high-level technology decisions?
Containers • How do containers communicate with one another?
• As a developer, where do I need to write code?
• What components/services is the system made up of?
Components • Is it clear how the system works at a high-level?
• Do all components have a home (a container)?
Titles Lines Layout
Make line style and arrows explicit, Sticky notes and index cards make a
Short and meaningful, numbered if
add annotations to lines to provide great substitute for drawn boxes,
diagram order is important
additional information especially early on
communicate
software architecture
d e si g n p rocess
During the
r e t r o s p e c t ively
and
Documenting
software
“
Working software
over
comprehensive
documentation Manifesto for Agile Software Development, 2001
No idea what
you’re on about...
#fail
Current Development Team Business Sponsors Future Development Team
Your system
a r c h i t e c ture
Software r
a t f o r m f o
is a pl
. . . b e s o cial!
on
conversati
Other Teams Security Team Compliance and Audit
Soft w a r e
Arc h ite c tu r e Maps
D o c u m e n t Sights and
itineraries
i d e b o o k
Gu
History and
culture
Practical
Information
Quality
Functional Constraints
Context Attributes
What is this all about? Overview Are there any significant Are there any significant
What does the system do? non-functional constraints?
requirements?
Software External
Principles Code
What design and Architecture Interfaces Are there any
development principles What does the big picture implementation details
What are the external
have been adopted? look like and how is the you need to explain?
system interfaces?
system structured?
Infrastructure Operation
Data Deployment
What does the data model Architecture What is the mapping & Support
look like and where is it What does the target between software and How will people operate
being stored? deployment infrastructure? and support the system?
environment look like?
Documentation should
describe what
code doesn’t
the
w as t e ,
Re du c e Use it to explain intent and
v a lu e act as a guide to navigate
add the source code
How much of the document is
up to date and relevant?
Software architecture in the
development
lifecycle
Software development is not a
relay sport
Software
e
Architectur
Document
throughout
(not just analysis and design)
How much up front design should you do?
Emergent design?
(or none, depending on
Big design up front? your viewpoint!)
Waterfall
Something in between?
You should do
“just enough”
Base your architecture on
requirements, travel light
and prove your architecture
with concrete experiments.
Scott Ambler
http://www.agilemodeling.com/essays/agileArchitecture.htm
What is architecturally
significant?
t l y t o c h a n ge
Cos
actor it New
(can you ref
on?)
in an afterno
Complex
You need to
risks
t w i l l c a u s e
Things tha
o j e ct t o f a il
your pr
t o b e f i re d!
or you
Probability
Medium (2) High (3)
Low (1)
2 3
Low (1)
1
Medium (2)
Impact
2 4 6
3 6 9
High (3)
Who looks after the risks
on most software projects?
“Just enough”
n d m i ti g ate
a
Identify
e k ey r i sks Provide firm foundations
Understand how the th
and a vision
significant elements
to move forward
fit together
The software architecture role and
the process of software architecting are
different
The software architecture role
Dedicated Everybody is a
software architect software architect
L e a d e r s h ip (Roy Os herove)
Elastic
Single point of responsibility for
o m m a n d a n d c ontrol), Joint responsibility for the
the technical aspects of the Survival (c technical aspects of the
ing),
software project learning (coach software project
o r g a n is in g ( f a c ilitation)
self-
The process of software architecting
Software
/// <summary>
/// Represents the behaviour behind the ...
e
Architectur
/// </summary>
public class SomeWizard : AbstractWizard
{
Document
private DomainObject _object;
private WizardPage _page;
public SomeWizard()
{
}
...
Evolutionary
Big up front design architecture
Requirements capture, analysis The architecture evolves
and design complete before secondary to the value created
coding starts by early regular releases of
working software
21st century software architecture
“just enough”
/// <summary>
/// Represents the behaviour behind the ...
/// </summary>
public class SomeWizard : AbstractWizard
Software {
private DomainObject _object;
Architecture private WizardPage _page;
public SomeWizard()
{
}
...
}
you
Do whatever works for