An introduction to software architecture for agile developers. The first 28 slides are commented and/or are exercises which can be worked through solo.

1. What is (the point of)
software architecture?
Mark van Harmelen Chris F. Carroll
xp-manchester 2013

2. In the beginning ...
...
there
were
Algorithms
and
Data
In the beginning ... there were Turing machine
designs and a lambda calculus and then
programmable computers and algorithms and
Structures
data structures ...
By the 1960s, computers were so big that they
could hold more than one algorithm or program
in memory at a time.
It became apparent that ....

3. ... size matters ...
“... beyond the algorithms and data structures of the
computation; designing and specifying the overall
system structure emerges as a new kind of problem.
Structural issues include gross organization and
global control structure; protocols for
communication, synchronization, and data access;
assignment of functionality to design elements;
physical distribution; composition of design
elements; scaling and performance; and selection
among design alternatives.
This is the software architecture level of design.”
Garlan & Shaw 1993

4. Some rough-cut definitions of architecture:
“… the high level structures or organisation of
your code” (At design-time? run-time? both?)
“… all the rules & design decisions you have
get right up-front, because they are too
expensive to change later.”
the architecture of a system is ? rough cut definitions

5. Architects talk about stakeholders.
This expands on having a customer – the main stakeholder mentioned in the
agile manifesto – and includes end-users and all others with a stake in the
system. For instance, the help desk team; the application support developer
two years later; yourselves as the development team; the company’s CFO,
data protection officer, security manager ...
Architecture claims in general to be able to analyse a software system in
such a way as to make it possible to methodically address their various
concerns.
♣ Stakeholders & their Concerns
about a software-intensive systems
♣ (especially quality attributes)
♣ by designing, communicating, calculating,
understanding the system’s fundamental elements,
relationships, properties and principles
Key Ideas what does “fundamental” mean?

6. Software
Quality
Attributes
Calculate
Everything
Views &
Viewpoints ARCHITECTURALLY
SIGNIFICANT
REQUIREMENTS
MANAGE
DEPENDENCIES
Re-usable WITH AN
Architecture IRON FIST

7. Software
Quality
Attributes
Calculate
Everything
Views & ARCHITECTURALLY
SIGNIFICANT
Viewpoints REQUIREMENTS
This overview of software architecture is skewed towards things you
don’t always learn as a developer. In order of importance from top to
bottom:
Quality attributes: such as security, reliability, performance ...
Architecturally significant requirements: Some requirements demand
significant design effort or priority and others don’t.
Views and viewpoints: such as how the system look at runtime versus
design time
Calculate everything: estimates, budgets, quality attributes, risks ...
Managing dependencies: relationships between elements usually mean
one element will break if the other isn’t in place
Re-usable architecture: well-known patterns or tactics
MANAGE
DEPENDENCIES
Re-usable WITH AN
Architecture IRON FIST

8. you can’t communicate
You are not the Borg telepathically
You must communicate your architecture if you want anyone else to work with it.

9. Software Quality Attributes
performance availability reliability
usability efficiency scalability
security fault-tolerance
Functional Suitability, Accuracy, Interoperability, Security, Compliance, Reliability, Maturity, recoverability compliance
Fault Tolerance, Recoverability, Compliance, Operability, Appropriateness, Recognisability,
Ease of use, Learnability, Attractiveness, Technical accessibility, Compliance, Performance operability ease of use learnability
efficiency, Time Behaviour, Resource Utilisation, Compliance, Security, Confidentiality, Inte- confidentiality integrity
grity, Non-repudiation, Accountability, Authenticity, Compliance, Compatibility, Replace-
ability, Co-existence, Interoperability, Compliance, Maintainability, Modularity, Reusability, accountability authenticity
Analysability, Changeability, Modification stability, Testability, Compliance, Portability, ...
compatibility replaceability

10. Software Quality Attributes
This is the biggest topic in software architecture textbooks.
The claim is that we can get a handle on things like
performance, reliability, modifiability which are otherwise
quite intangible and hard to pin down. Even vast areas like
security can be analysed.
Software Architecture provides a way in that can give you
confidence that you are addressing the problem well.
performance availability reliability
usability efficiency scalability
security fault-tolerance
Functional Suitability, Accuracy, Interoperability, Security, Compliance, Reliability, Maturity, recoverability compliance
Fault Tolerance, Recoverability, Compliance, Operability, Appropriateness, Recognisability,
Ease of use, Learnability, Attractiveness, Technical accessibility, Compliance, Performance operability ease of use learnability
efficiency, Time Behaviour, Resource Utilisation, Compliance, Security, Confidentiality, Inte- confidentiality integrity
grity, Non-repudiation, Accountability, Authenticity, Compliance, Compatibility, Replace-
ability, Co-existence, Interoperability, Compliance, Maintainability, Modularity, Reusability, accountability authenticity
Analysability, Changeability, Modification stability, Testability, Compliance, Portability, ...
compatibility replaceability

11. Which view do you need? I’d like to design a boiler-room

12. Views and viewpoints. Any software intensive system – even a really small one –
is so complicated that no single way of looking at it can tell you everything, or
help you understand all you need to know.
When code builds on one machine but not another, thinking about classes and
methods will rarely resolve the issue; another way of seeing is required.
When on a running system, communication with an external service starts
failing, you might start by looking at the communication channels, firewall rules
and so on. So you need a view of the system which ‘sees’ this kind information –
which a class diagram doesn’t.
These pictures of the titanic answer some questions you might have about the
boiler room but don’t tell you what would happen if an iceberg scraped the side
of the ship.
Which view do you need? I’d like to design a boiler-room

13. }
estimate
measure
risk-evaluate
account for
cost-benefit-analyse everything
calculate
quantify
validate
budget
know everything if you don’t, who will?

14. You cannot get investors interested in your business plan unless you have
}
the numbers at your fingertips. This you may learn from watching Dragons’
Den.
estimate planning doesn’t answer everything. If you hire a company to build a
Sprint
motorway from Lancashire to Yorkshire, you don’t want a bid that can only
measure you that the first knowout ofgetting over the Pennines will have Not least
tell
because you already
mile
that
Manchester will cost a £1 million.
a quite
risk-evaluate on every team!
different cost base. The Poppendiecks, in their Lean book, suggest an
accountant
account forSo predict thealso giveyou may be confident that you’ll probably be
When you
wrong. you must
future,
some account of what risks and assumptions
cost-benefit-analyse
are involved.
everything a key trick
calculate often be, findof availability. It’s not the whole story about availability, but
Dealing with software qualities like performance and reliability,
will something you can measure. Up-time (“five nines”) is a
familiar measure
quantifythat tangible; and it istoone ofout what is the MTBF of cares about. Toyou use
it is
you might need find
the things a customer
a hard drive. If
calculate
validatewhen a replacement disk is being synchronised.
RAID you might need to find out what performance degradation you will get
budget yourgeneral point: Details andhas to get into the details and measure it to the
The
business then someone
precision matter. If, say, availability matters to
level detail that will answer the question.
know everything if you don’t, who will?

15. Architecturally Significant Requirements
Architecturally Significant
what matters first?
Requirements

16. Architecturally Significant Requirements
Can you build a car, and then put go faster things on it to make it go
faster? Or do you have to address ‘gofasterness’ right from the start?
If you have a set of user stories at the start of a new sprint, are they all
equally risky or do some stand out with a little flashing light in your head
that says, “ooh that’s a problem?”
A kind of triage is needed: identifying requirements you have to deal with
sooner otherwise you won’t be able to deal with it at all.
Continuous delivery is an example highlighted in agile: If you don’t get
your CI pipeline going early on, it gets harder and harder and costs you
more and more.
Architecturally Significant
what matters first?
Requirements

17. Manage dependencies before they manage you
Picture: Nature Reviews Neuroscience
dependency <=> relationship <=> communication dependency : It’s complicated

18. Manage dependencies before they mis-manage you
Components depend on each other in different ways.
Sometimes, it works on the CI machine but bombs out in live.
Or a version upgrade of one component breaks another one.
A component expects measurements in centimetres but gets
inches, so your $125 million Mars Orbiter crashes after years
of work ...
Manage dependencies before they mis-manage you.
Picture: Nature Reviews Neuroscience
dependency <=> relationship <=> communication dependency : It’s complicated

19. Re-usable architecture
fulfils the “hello world” requirement

20. Re-usable architecture
You do not need to re-invent REST architecture; someone
already invented it for you. As with design patterns, there are
architecture patterns which can be re-used and which might
even be bundled as a wizard in your IDE.
The risk with “cookie-cutter architecture” is that though you
may know how to use it well within areas you are familiar
with, you may misunderstand how to use it well when in
unfamiliar territory.
You still need the principles that will serve you when you
address a new unfamiliar area for which you have no ‘off the
shelf’ solution.
fulfils the “hello world” requirement

21. Software
Quality
Attributes
Calculate
Everything
Views &
Viewpoints ARCHITECTURALLY
SIGNIFICANT
REQUIREMENTS
MANAGE
DEPENDENCIES
Re-usable WITH AN
Architecture IRON FIST

22. Case Study – Vertical Search Internet Startup
A restless executive at an internet hotel booking
business has decided to set up a rival company,
and you've been headhunted to be the technical
leads, analysts and architects.
The business plan is of course “do what the
competition do!” So it's going to be a website on
which someone types a destination and gets a
list of places to stay. Fortunately we've got a
vertical search partner with a lot of hotel data on
a web service, so we first need to build the
website.
Case Study Scenario A vertical search start-up

23. Case Study – Vertical Search Internet Startup
The key business process: a customer comes to our
website and finds a place to stay; then does one of:
♣
books it via our booking system. We get average 25%
commission (if the commercial manager negotiates well).
♣
clicks a CPA affiliate link. We get average 15%
commission (if the affiliate network manager negotiates
well)
♣
clicks a CPC affiliate link. We get average 10p per click.
We expect 10,000 visitors per day after 4 months, rising to
30,000 per day after a year and growing 33% per year for
3 years thereafter. Average visitors views 4 pages and
does 1.2 searches
Also, we want to send everyone a text message linking to
our website so they can download the app version too.
Case Study Detail A vertical search start-up

24. Case Study – Vertical Search Internet Startup
In teams of 3-5. You have been appointed (as a group) as the CTO of this
start-up. You are responsible for all things IT.
Your challenge: Do a presentation in about 10 minutes time. You are
presenting to the whole company - the board, the development team –
and a couple of investors too.
Your task is give everyone the calm assurance that you have everything in
hand, that you know what you’re doing and you know how the IT
department will deliver a working system within a few months and be
able to expand it thereafter.
Some Thoughts
•You might describe the system you’re going to build?
•You’ll want your developers and infrastructure guys to be nodding
reassuringly. Puzzled and frowny staff do not give the CEO a nice warm
feeling.
•The board : CEO, CFO, Commercial Manager, Sales Manager. The
investor used to be on the board of a competitor. The sales manager is
all excited by Web3.0 or something.
•Your developers are good but they don’t have your experience with
webby stuff. Or services. Or databases...
Case Study Exercise A vertical search start-up

25. After the teams have done their presentation, try to analyse with the
wisdom of hindsight what did each team seem to think were the
important concerns to address?
Examples
Team A’s presentation emphasises speed to market – suggesting an
initial throw-away static website – as even higher priority than the
functional requirement of doing search.
Team B presented a plan using a load-balancer and web-farm to address
scalability
Team C pointed out where the system was extendable to add
functionality later.
These concerns form the prioritised ‘architecturally significant
requirements’. The list might look like this:
1. Speed to Market
2. Implement Search Functionality
3. Scalability
4. Extendibility
Architecturally Significant Requirements Case Study Review

26. Calculate Everything – Cost Benefit Analysis
Given this prioritised list of ‘architecturally significant requirements’
1. Speed to Market
2. Implement Search Functionality
3. Scalability
4. Extendibility
Let’s look at the first one first. ‘Speed to Market’ might be done by first
doing a throwaway static website; or by delivering a minimal non-
throwaway system.
Choosing between the two would require some kind of cost-benefit
analysis:
•How much revenue would they generate and when?
•How much would we learn that would help us later on?
•... and so on.
Calculate Everything – Cost Benefit Analysis Case Study Review

27. Manage Dependencies with an Iron Fist
Given this prioritised list of ‘architecturally significant requirements’
1. Speed to Market
2. Implement Search Functionality
3. Scalability
4. Extendibility
Look at the second and third requirements. If you first deliver the
functionality, could you then ‘add’ scalability to it afterwards? Or do you
need to address scalability first even though it’s not as high a priority as
getting the functionality done?
Manage Dependencies with an Iron Fist Case Study Review

28. Software Qualities – “Extendability”
Given this prioritised list of ‘architecturally significant requirements’
1. Speed to Market
2. Implement Search Functionality
3. Scalability
4. Extendibility
Consider the extendibility requirement. What constraints would you apply
to your design or your developers to ease the addition of new
functionality could be added to the site months or years later?
(Of course, as an experienced OO/Agile developer you may feel that this
is the question on which you’re an expert. You may be right).
Extendability aka Modifiability Case Study Review

29. Software
Quality
Attributes
Calculate
Everything
Views &
Viewpoints ARCHITECTURALLY
SIGNIFICANT
REQUIREMENTS
MANAGE
DEPENDENCIES
Re-usable WITH AN
Architecture IRON FIST

30. Views and Viewpoints

31. Which view do you need? I’d like to design a boiler-room

32. 4+1 (Kruchten, 1995) IBM developerworks

33. 4+1, Updated

34. Information View System Context
Entities, Relationships, Aggregate Roots
Lifecycle, Ownership / Relationships
Operational View
X +1 the more the merrier?

35. Software Quality Attributes
performance availability reliability
usability efficiency scalability
security fault-tolerance
Functional Suitability, Accuracy, Interoperability, Security, Compliance, Reliability, Maturity, recoverability compliance
Fault Tolerance, Recoverability, Compliance, Operability, Appropriateness, Recognisability,
Ease of use, Learnability, Attractiveness, Technical accessibility, Compliance, Performance operability ease of use learnability
efficiency, Time Behaviour, Resource Utilisation, Compliance, Security, Confidentiality, Inte- confidentiality integrity
grity, Non-repudiation, Accountability, Authenticity, Compliance, Compatibility, Replace-
ability, Co-existence, Interoperability, Compliance, Maintainability, Modularity, Reusability, accountability authenticity
Analysability, Changeability, Modification stability, Testability, Compliance, Portability, ...
compatibility replaceability

36. ♣ You’re phoned by a friend. A primary school teacher:
Who asks, “please send me an example of a hello world
application that I can show to a primary school class”
♣ Name twenty different ways you could fulfil this
requirement
Quick Quiz

37. ♣ You’re phoned by a friend. A primary school teacher:
Who asks, “please send me an example of a hello world
application that I can show to a primary school class.”
♣ One week later, the friend calls back,
“That was great! I’d also like …”
o … the kids to be able to go home and show it to their
parents
o … each kid to be able to modify it to do it in a different
language for their world culturalglobalmultilingualness day
Quick Quiz — 2

38. ♣ The functional requirements do not dictate the
architecture
(the requirement can be met in many ways by many
architectures)
♣ The architecture does constrain the non-functional
qualities : the quality attributes
quality attributes vs functionality architecture is ... ?

39. How can we work out which architecture will deliver ... performance availability reliability
usability scalability security fault-
tolerance compliance operability
ease of use learnability
confidentiality integrity ...
Software Quality Attributes

40. ♣ Invent the meaning of a quality attribute by
describing scenarios and defining measures
Consider proxy measures
♣
Research, agree and then mandate the tactics
you will use to achieve the quality
Software Quality Attributes first, define your terms

41. ♣ Performance
o Usually about timing:
“When X happens, Y must happen within N seconds”
♣ The Case Study
o How fast must the web server be able to serve
1) Search results
2) Other pages
♣ What tactics achieve performance?
Performance quality attributes : define it

42. ♣ Availability / Resilience
o Uptime
o Simple BAU scenarios
“When X fails, Y should happen and the system should
continue operating as normal”
(possibly within N seconds or hours)
o Attack Scenarios:
“When attack X happens, Y should happen and the
system should continue operating as normal”
♣ What tactics achieve availability?
Availability & Resilience quality attributes : define it

43. ♣ Modifiability / Maintainability / Evolution
o Could be measured as (estimated) cost or speed
♣ Are these reasonable measures of modifiability:
o “It should take no more than 30 seconds of effort to
correct a spelling error on the website”
o “Sprint velocity in months 12 to 24 of development
should be as good as in months 3 to 12”
Modifiability is ... quality attributes : measure it

44. Testability
♣ Is this a reasonable measure:
o “The percentage chance that a defect is discovered
on the first test run after the defect is introduced”
Testability is ... quality attributes : measure it

45. ♣ Testability
o “The percentage chance that a defect is discovered
on the first test run after the defect is introduced”
♣ If it’s too hard to measure, use a proxy measure:
o Test Coverage Percentage
o Cost/Time to do a complete test run
o ...
Using Proxy Measures quality attributes : measure it

46. ♣ What tactics achieve modifiability, maintainability,
testability?
♣ Do they give rise to any useful proxy measures?
o Measures for complexity, cohesion, coupling,
dependencies, ...
Modifiability & Testability quality attributes : tactics

47. “Assets”
Security—it’s a process.
Rozanski & Wood
Software Systems Architecture, 2011

48. ♣ Confidentiality
o Data is accessible only by those authorised
♣ Integrity
o Protection from unauthorised modification
♣ Availability
o You can get to it when you need it
_____________________________________
♣ Non-repudiation
o Actions can be proven to have taken place
♣ Accountability
o Actions can be traced to who did them
♣ Authenticity
o Identity can be proved to be the one claimed
ISO 27001 & 27002 Security : define it

49. ♣ Describe scenarios
♣ Define measures
♣ Research tactics
♣ Mandate the approach
Software Quality Attributes the bridge fulfilled the functional requirement

50. Definitions of architecture

51. ISO/IEC/IEEE 42010:2011
“The fundamental concepts or properties of a
system in its environment embodied in its
elements, relationships, and in the principles of
its design and evolution”
Architecture is ... what does fundamental mean?

52. SEI
The structure or structures of the system, which
comprise software elements, the externally
visible properties of those elements, and the
relationships among them.
Architecture is ... Bass, Clements, Kazman, 1997-2012

53. Kruchten 2009: The significant decisions about
♣
the organization of a software system,
♣
the selection of the structural elements and their interfaces by which
the system is composed together with their behavio[u]r as specified in
the collaboration among those elements,
♣
the composition of these elements into progressively larger
subsystems,
the architectural style that guides this organization, these elements and
their interfaces, their collaborations, and their composition
Architecture is ... Kruchten, updated 2009

54. Architecturally Significant Requirements

55. Architecturally Significant Requirements
♣ Most quality attributes are architecturally
significant if they matter at all
♣ Functionality? If it changes the design; or
costs a lot
♣ Yagni or Niagni?
Architecturally Significant
what matters, when?
Requirements

56. Re-usable architecture
fulfils the “hello world” requirement

57. standard patterns the re-usable kitteh pattern

58. think out of inside the box let’s not re-invent the wheel

59. Manage Dependencies with an Iron First

60. Manage dependencies before they manage you
dependency === relationship === communication dependency : It’s complicated

61. There are LOADS of kinds of dependency ...
♣ Design Time vs Build Time vs Runtime vs Operational
♣ One-way vs. Mutual vs. Transitive or Indirect
♣ X gets information from Y
♣ X needs functionality or service from Y
♣ X sends information to and therefore needs the definition of Y
♣ Syntax, semantic, sequence, location, id, existence,
QoS, resource usage
Dependency <=> Relationship <=> Communication
Manage Dependencies I need you in so many ways

62. }
estimate
measure
risk-evaluate
account for
cost-benefit-analyse everything
calculate
quantify
validate
budget
know everything if you don’t, who will?

63. Software
Quality
Attributes
MANAGE
DEPENDENCIES
WITH AN
Views & IRON FIST
Viewpoints ARCHITECTURALLY
SIGNIFICANT
REQUIREMENTS
Calculate
Everything
Re-usable
Architecture