THE FRUSTRATED ARCHITECT Simon Brown @simonbrown Perceptions Big - - PowerPoint PPT Presentation

SLIDE 1

THE FRUSTRATED ARCHITECT

Simon Brown

@simonbrown

SLIDE 2

Perceptions

SLIDE 3

I’m a

software architect

Big up front design

and analysis paralysis

UML Waterfall Ivory Tower

Architecture Astronaut

PowerPoint Architect

SLIDE 4

PowerPoint

Architecture

yes, I know ... but I’m not using PowerPoint :-P E n t e r p r i s e S e r v i c e B u s S i n g l e S i g n

• O

n Corporate Data Model Buzzword Bingo

SLIDE 5

Relay Sport

Architecture

S

• f

t w a r e A r c h i t e c t u r e D

• c

u m e n t This is a big bunch of

A a a S

SLIDE 6

I’m another member of the team

(and I like writing code)

SLIDE 7 Coding “Architecture” Time

SLIDE 8

The UML phase

SLIDE 9

The

Management Consulting

phase

SLIDE 10 Our tech lead and mentor has been “promoted” ...

help!

The “corporate ladder”

Technical Non-technical

SLIDE 11

Your management thinks

coding

is a

commodity?

Tell them to

• ffshore it all

SLIDE 12 http://www.codingthearchitecture.com

SLIDE 13

“Software Architect” is not an

• rganisational rank

It’s a role that you

evolve into

SLIDE 14

We aspire to be agile

and self-organising

And that’s cool, but aren’t you

forgetting something?

SLIDE 15

Agile

SLIDE 16

Agile

Emergent design Retrospectives Moving fast, embracing change Automated acceptance testing Continuous delivery Self-organising team Test-driven development Lean Kanban

Technical guidance Non-functional requirements Vision Structure Performance Scalability Availability Security Technical quality

SLIDE 17

Agile _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

I don’t position most of my content as agile, but...

SLIDE 18

What is an

agile architect

anyway?

SLIDE 19

I’m an agile

architect!

Evolutionary Architecture

and Emergent Design

YAGNI

Defer until the

last responsible moment

Refactoring

Spikes, stripes and tracers

System Metaphor

SLIDE 20

Agile

architecture?

SLIDE 21

Agile (e.g. Scrum)

Skills Business Modelling Requirements Analysis & Design Implementation Test Deployment Configuration Management Project Management Environment Sprint 1 Sprint 2 Sprint 3

SLIDE 22

Evolutionary architecture

Foolishly hoping for the best?

SLIDE 23 Agile software team

We don’t need software architecture; we do TDD

SLIDE 24

TDD is about code

... architecture isn’t

(well, it is, but it’s also about more than just the code)

SLIDE 25

Last responsible moment

M

• s

t p e

• p

l e k n

• w

r

• u

g h l y w h a t t h e y ’ r e b u i l d i n g s

• j

u s t m a k e s

• m

e d e c i s i

• n

s !

SLIDE 26

Flat, self-organising teams are great but...

...they don’t always work

SLIDE 27

Let’s

invent

something shiny and new...

r e

SLIDE 28

Retrospective

SLIDE 29

Have we forgotten more than we’ve learnt?

SLIDE 30

UML

SLIDE 31

SLIDE 32

Class

Responsibilities Collaborators

C l a s s

R e s p

• n

s i b i l i t i e s C

• l

l a b

• r

a t

• r

s

Class-Responsibility-Collaboration

Class

Responsibilities Collaborators

SLIDE 33

Component-based development

Component A Component B Component C H i g h c

• h

e s i

• n

, l

• w

c

• u

p l i n g d e s i g n b y c

• n

t r a c t , L i s k

• v

s u b s t i t u t i

• n

p r i n c i p l e

SLIDE 34

Pattern-Oriented Software Architecture

SLIDE 35

Rational Unified Process (RUP)

Transition Construction Elaboration Skills Business Modelling Requirements Analysis & Design Implementation Test Deployment Configuration Management Project Management Environment Inception

SLIDE 36

Be pragmatic with this stuff

(if you know it exists, of course)

SLIDE 37

Who is teaching the classics of the pre-agile era?

UML Component-Based Development Pattern-Oriented Software Architecture R a t i

• n

a l U n i fi e d P r

• c

e s s Test-Driven Development

Kanban

C

• n

t i n u

• u

s D e l i v e r y Agile Systems Thinking Extreme Programming

SLIDE 38

So you think you're an architect

SLIDE 39 C u r r i c u l u m V i t a e / R e s u m e

E n t e r p r i s e A r c h i t e c t

A B i g C

• m

p a n y ( 2 6

• d

a t e ) I h a v e b e e n r e s p

• n

s i b l e f

• r

t h e d e s i g n a n d i m p l e m e n t a t i

• n
• f

a n e n t e r p r i s e c u s t

• m

e r s

• l

u t i

• n

. I d r e w s

• m

e U M L d i a g r a m s a n d I w r

• t

e s

• m

e J a v a c

• d

e . I w

• u

l d l i k e a j

• b

w r i t i n g m

• r

e c

• d

e p l e a s e . :

• )

Err, no; you’re a software architect who just happens to work in a large organisation

( i n f a c t , y

• u

’ r e b a r e l y a “ s

• f

t w a r e a r c h i t e c t ” e i t h e r )

SLIDE 40

Software development is not a

relay sport

S

• f

t w a r e A r c h i t e c t u r e D

• c

u m e n t

SLIDE 41

Successful software delivery is not an

implementation detail!

SLIDE 42

The irresponsible architect

Cross-site scripting attacks possible; weak passwords allowed; HTTP sessions didn’t timeout; ... Basic functionality errors; little or no quality assurance; rework required late in the project because

• f assumptions; ...

No non-functional testing (e.g. penetration testing or load testing); ...

SLIDE 43

Foolishly hoping for the best?

SLIDE 44

The irresponsible architect

Cross-site scripting attacks possible; weak passwords allowed; HTTP sessions didn’t timeout; ... Basic functionality errors; little or no quality assurance; rework required late in the project because

• f assumptions; ...

Oh, did I mention this was supposed to be a “strategic platform”? No non-functional testing (e.g. penetration testing or load testing); ... No documentation; ...

SLIDE 45 Context What is this all about? Functional View What does the system do? Process View Does the system implement business processes? Non-functional View Are there any significant non- functional requirements influencing the architecture? Architectural Constraints Are there any constraints influencing the architecture? Architectural Principles Are there any principles influencing the architecture? Logical View What does the big picture look like and how is the system structured? Interface View Are there internal or external system interfaces? Design View Is it clear how system components should be implemented? Infrastructure View What does the target deployment environment look like? Deployment View How will the system components be deployed onto the target infrastructure? Operational View How will people operate and support the system? Security View How is security handled across all tiers? Data View How is data managed, archived, backed-up, etc? Technology Selection What led to the selection of the technologies in use? Architecture Justification Does the chosen architecture “work”?

SLIDE 46

Author or architect?

SLIDE 47

#win P r

• j

e c t M a n a g i n g #fail

SLIDE 48

Technical Project Managers

tend to focus more on

project management

than technology

(This is Matt; he’s approximately my height)

SLIDE 49

Serenity

SLIDE 50 Macro (classes) Abstract Specific As developers, the code is usually our main focus T e l e p h

• t
• (

c

• m

p

• n

e n t s ) S t a n d a r d ( c

• n

t a i n e r s ) Wide angle (context)

SLIDE 51 Abstract Specific Sometimes you need to

step back from your IDE

Macro (classes) T e l e p h

• t
• (

c

• m

p

• n

e n t s ) S t a n d a r d ( c

• n

t a i n e r s ) Wide angle (context)

SLIDE 52 F u n c t i

• n

a l & n

• n
• f

u n c t i

• n

a l r e q u i r e m e n t s Principles Constraints

• 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

• f 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.

Big Bank plc Internet Banking System Macro (classes) T e l e p h

• t
• (

c

• m

p

• n

e n t s ) S t a n d a r d ( c

• n

t a i n e r s ) Wide angle (context)

Options

SLIDE 53 P

• s

t

• i

t n

• t

e s Flipchart & pens Blu-Tack Index cards W h i t e b

• a

r d & p e n s C

• l

l a b

• r

a t i v e d e s i g n

SLIDE 54

Effective sketches

are an excellent way to

collaborate

• n software architecture

Macro (classes) T e l e p h

• t
• (

c

• m

p

• n

e n t s ) S t a n d a r d ( c

• n

t a i n e r s ) Wide angle (context)

SLIDE 55

Drawing diagrams

doesn’t make you an

architect

SLIDE 56

Would you

code

it that way?

This is why software architects must be able to code!

SLIDE 57

Or preferably both; I like software architectures to be grounded in reality

(and that includes technology choices)

SLIDE 58

Maybe, maybe not

(remember what I said about technology choices?)

SLIDE 59

Deferring framework decisions and isolating them should be a

conscious decision

SLIDE 60

How much

architecture do you need to do?

This much? This much?

SLIDE 61

You need to do

“just enough”

architecture

SLIDE 62

Base your architecture on requirements, travel light and prove your architecture with concrete experiments. Base your architecture on requirements, travel light and prove your architecture with concrete experiments. Base your architecture on requirements, travel light and prove your architecture with concrete experiments.

Scott Ambler http://www.agilemodeling.com/essays/agileArchitecture.htm

SLIDE 63

If you flex functionality, does the architecture

change?

P r

• b

a b l y n

• t

, s

• j

u s t m a k e

s

• m

e d e c i s i

• n

s

. . .

SLIDE 64

What is architecturally

significant?

C

• s

t l y t

• c

h a n g e ( c a n y

• u

r e f a c t

• r

i t i n a n a f t e r n

• n

? ) C

• m

p l e x a n d r i s k y New

SLIDE 65 An example timeline from

“Beyond Retrospectives”

by Linda Rising #gotocon Aarhus 2011

SLIDE 66

Just enough

Understand how the significant elements fit together M i t i g a t e t h e k e y r i s k s Provide the foundations and vision to move forward

SLIDE 67

Requirements Context and Containers Components (and Ballpark Estimates)

D

• i

n g t h i s c

• l

l a b

• r

a t i v e l y a l l

• w

s p e

• p

l e ’ s s e p a r a t e i d e a s t

• m

e e t

1-2 days

S t a n d a r d ( c

• n

t a i n e r s ) Wide angle (context) T e l e p h

• t
• (

c

• m

p

• n

e n t s ) 1 . C u r r e n t S i t u a t i

• n

W e h a v e a n e x i s t i n g I n t e r n e t B a n k i n g

• f

f e r i n g t h a t a l l

• w

s c u s t

• m

e r s t

• s

e c u r e l y v i e w i n f

• r

m a t i

• n

a b

• u

t t h e i r b a n k a c c

• u

n t s h e l d w i t h u s v i a t h e w e b . A l t h

• u

g h w e w e r e

• n

e

• f

t h e f i r s t t

• m

a r k e t w i t h s u c h a p r

• d

u c t , t h e s y s t e m i t s e l f i s a n u m b e r

• f

y e a r s

• l

d n

• w

a n d a s e r i e s

• f

p r

• b

l e m s h a s b e e n i d e n t i f i e d d u r i n g a c

• n

s u l t i n g e x e r c i s e t h a t w e r e c e n t l y i n i t i a t e d . I n s u m m a r y :

• T

h e s y s t e m

• n

l y p r

• v

i d e s c u s t

• m

e r s w i t h r e a d

• n

l y a c c e s s t

• i

n f

• r

m a t i

• n

a b

• u

t t h e i r b a n k a c c

• u

n t s . T h i s i n c l u d e s a c c

• u

n t b a l a n c e s , r e c e n t t r a n s a c t i

• n

s a n d r e c e n t s t a t e m e n t s .

• T

h e i n f

• r

m a t i

• n

p r e s e n t e d t

• c

u s t

• m

e r s i s s l i g h t l y

• u

t

• f
• d

a t e , b e c a u s e i n f

• r

m a t i

• n

f r

• m

t h e c

• r

e b a n k i n g s y s t e m i s e x p

• r

t e d t

• t

h e w e b s i t e

• n

a n i g h t l y b a s i s .

• T

r a n s a c t i

• n

a l r e q u e s t s a r e n

• t

p

• s

s i b l e t h r

• u

g h t h e s i t e , w i t h c u s t

• m

e r s i n s t e a d s e n d i n g a s e c u r e m e s s a g e t

• t

h e c a l l c e n t r e w i t h t h e i r r e q u e s t i n s t e a d . T h i s p r

• c

e s s i s

• p

e n t

• a

b u s e a n d f r a u d .

• T

h e n u m b e r

• f

f e a t u r e s s u p p

• r

t e d b y t h e

• f

f e r i n g i s l i m i t e d .

• T

h e t e c h n

• l
• g

y i s n

• l
• n

g e r s e e n a s “ l e a d i n g e d g e ” , i s h a r d t

• e

n h a n c e a n d c

• s

t l y t

• m

a i n t a i n . I n a d d i t i

• n

, t h e t e c h n

• l
• g

y h a s r e a c h e d “ e n d

• f

l i f e ” a n d i s n

• l
• n

g e r p r

• a

c t i v e l y s u p p

• r

t e d b y t h e v e n d

• r

.

• T

h e s y s t e m d

• e

s n ’ t m e e t c u r r e n t w e b s i t e a c c e s s i b i l i t y s t a n d a r d s . I n a r e c e n t s u r v e y ,

• u

r I n t e r n e t B a n k i n g s y s t e m w a s p e r c e i v e d a s p

• r

i n t e r m s

• f

t h e u s e r e x p e r i e n c e a n d t h e l e v e l

• f

i n f

• r

m a t i

• n

a v a i l a b l e t h r

• u

g h t h e w e b s i t e . W i t h

• u

r c

• m

p e t i t

• r

s n

• w
• f

f e r i n g f u l l y t r a n s a c t i

• n

a l s y s t e m s , t h e r e i s a r i s k t h a t w e w i l l l

• s

e b u s i n e s s . 2 . V i s i

• n

T h e b

• a

r d h a v e g i v e n u s t h e g

• a

h e a d t

• i

n i t i a t e a p r

• j

e c t t

• r

e p l a c e t h e c u r r e n t I n t e r n e t B a n k i n g s y s t e m , w h i c h w i l l n e e d t

• c
• i

n c i d e w i t h t h e c

• r

p

• r

a t e r e b r a n d i n g t h a t w i l l b e t a k i n g p l a c e i n 1 2 w e e k s . T h e r e p l a c e m e n t s y s t e m s h

• u

l d :

• P

r

• v

i d e c u s t

• m

e r s w i t h r e a l

• t

i m e a c c e s s t

• i

n f

• r

m a t i

• n

a b

• u

t t h e i r b a n k a c c

• u

n t s .

• P

r

• v

i d e c u s t

• m

e r s w i t h t h e a b i l i t y t

• p

e r f

• r

m c

• m

m

• n

t r a n s a c t i

• n

s t h r

• u

g h t h e w e b s i t e . T h i s i n c l u d e s m a k i n g p a y m e n t s , s e t t i n g u p s t a n d i n g

• r

d e r s , t r a n s f e r r i n g m

• n

e y a n d s

• n

.

• P

r

• v

i d e c u s t

• m

e r s w i t h a r i c h u s e r e x p e r i e n c e .

• M

e e t c u r r e n t w e b s i t e a c c e s s i b i l i t y s t a n d a r d s .

• B

e d e v e l

• p

e d u s i n g t h e n e w c

• r

p

• r

a t e w e b s i t e d e s i g n g u i d e l i n e s . B i g B a n k p l c I n t e r n e t B a n k i n g S y s t e m

SLIDE 68

The role of the software architect and the process of software architecture are

different

SLIDE 69 From chaos to self-organising Dedicated software architect Single point of responsibility for the technical aspects of the software project Everybody is a software architect Joint responsibility for the technical aspects of the software project

The role

SLIDE 70 From big design up front to evolutionary

The process

S

• f

t w a r e A r c h i t e c t u r e D

• c

u m e n t Big up front design Requirements capture, analysis and design complete before coding starts Evolutionary architecture The architecture evolves secondary to the value created by early regular releases of working software /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard { private DomainObject _object; private WizardPage _page; private WizardController _controller; public SomeWizard() { } ... }

SLIDE 71

Just enough

S

• f

t w a r e A r c h i t e c t u r e D

• c

u m e n t /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard { private DomainObject _object; private WizardPage _page; private WizardController _controller; public SomeWizard() { } ... } The role The process Understand how the significant elements fit together M i t i g a t e t h e k e y r i s k s Provide the foundations and vision to move forward

SLIDE 72

Let’s wrap up...

SLIDE 73

Yes, architecture provides

structure, firm foundations, vision and technical leadership

Does agile need architecture?

SLIDE 74

Yes, it helps software teams move away from

big design up front

and analysis paralysis

Does architecture need agile?

SLIDE 75

Define

the software architecture role and

collaborate

T a l k a b

• u

t a r c h i t e c t u r e i n y

• u

r

r e t r

• s

p e c t i v e s

SLIDE 76

Do you want to

code?

SLIDE 77

Software architecture documentation should

describe what

the code doesn’t

SLIDE 78

Effective sketches

are an excellent way to

communicate

software architecture

Macro (classes) T e l e p h

• t
• (

c

• m

p

• n

e n t s ) S t a n d a r d ( c

• n

t a i n e r s ) Wide angle (context)

SLIDE 79

Apply craftsmanship to

software architecture

Effective yet lightweight sketches and documentation S

• f

t w a r e s y s t e m s t h a t a c t u a l l y

work

SLIDE 80

We need to grow the

architects of tomorrow

SLIDE 81

you

simon.brown@codingthearchitecture.com @simonbrown on Twitter

Do whatever works for

(just don’t get distracted by shiny new things just because they’re shinier!)