Being a very brief history of how "architecture" become a thing in software, and of how it delivers on its core claim to fame, which is: Enabling you to Reason & Calculate about quite vague "Quality" requirements and thereby to achieve confidence of a successful system and happy customers

1. Chester Devs, 2015 Chris F Carroll
Software Architecture – Why and What?

2. In the beginning ... ...
there
were
algorithms;
computable
functions;
the lambda
calculus…

3. The Software Architectural
Qualities of a Proof on
Paper…
• Availability: 7–Nines Uptime
• Reliability/Robustness: no
moving parts, can survive drops,
collisions and earthquakes
• Parallel processing: Can be
copied and worked on by
multiple people in parallel (good
implementation of immutability)
• Can be geographically
distributed without loss of
performance
• But not, alas, extremely fast…

7. why architecture? because …
“… No-one replaces or re-writes a system
because of its functionally. It’s always because
of some quality failing – performance or
reliability, usability, or ease of modifiability”

8. The Claim of Software Architecture
To enable Reasoning about:
… the Quality Attributes of
Software-intensive Systems
… to meet Stakeholder’s Concerns
… using Architecture Descriptions
of the system’s fundamental
structure(s)
in terms of its elements, relationships, properties and principles
Why software architecture?

9. • What is a Quality Attribute?
• What does “Reasoning about” mean?
• What are Stakeholder Concerns?
• What is an Architecture Description
and how does it help?
4 Key Concepts The promise of Software Architecture

10. • What is a Quality Attribute?
• What does “Reasoning about” mean?
• What are Stakeholder Concerns?
• What is an Architecture Description
and how does it help?
4 Key Concepts The promise of Software Architecture

11. What is a Quality Attribute? Who defines quality?
“It’s not what you do, it’s the way that you do it”
affordability, availability, correctness,
deployability,efficiency, evolvability, extensibility,
fault-tolerance, main-tainability, modifiability,
reliability, resilience, responsiveness, robust-ness,
safety, scalability, securability, testability, usability,
…

12. What is a Quality Attribute? ISO 25010
“It’s not what you do, it’s the way that you do it”
accessibility, accountability, accuracy, adaptability, administrability, affordability, agility, auditability, autonomy,
availability, compatibility, composability, configurability, correctness, credibility, customizability, debugability,
degradability, determinability, demonstrability, dependability, deployability, discoverability, distributability,
durability, effectiveness, efficiency, evolvability, extensibility, failure transparency, fault-tolerance, fidelity, flexibility,
inspectability, installability, integrity, interchangeability, interoperability, learnability, maintainability, manageability,
mobility, modifiability, modularity, operability, orthogonality, portability, precision, predictability, process
capabilities, producibility, provability, recoverability, relevance, reliability, repeatability, reproducibility, resilience,
responsiveness, reusability, robustness, safety, scalability, seamlessness, self-sustainability, serviceability,
supportability, securability, simplicity, stability, standards compliance, survivability, sustainability, tailorability,
testability, timeliness, traceability, ubiquity, understandability, upgradability, usability

13. Many ways to get from A to B what about a horse?

14. Many ways to get from A to B how about a camel?

15. What is a Quality Attribute? but … what do all these words mean?
“It’s not what you do, it’s the way that you do it”
accessibility, accountability, accuracy, adaptability, administrability, affordability,
agility, auditability, autonomy, availability, compatibility, composability,
configurability, correctness, credibility, customizability, debugability, degradability,
determinability, demonstrability, dependability, deployability, discoverability,
distributability, durability, effectiveness, efficiency, evolvability, extensibility, failure
transparency, fault-tolerance, fidelity, flexibility, inspectability, installability, integrity,
interchangeability, interoperability, learnability, maintainability, manageability,
mobility, modifiability, modularity, operability, orthogonality, portability, precision,
predictability, process capabilities, producibility, provability, recoverability, relevance,
reliability, repeatability, reproducibility, resilience, responsiveness, reusability,
robustness, safety, scalability, seamlessness, self-sustainability, serviceability,
supportability, securability, simplicity, stability, standards compliance, survivability,
sustainability, tailorability, testability, timeliness, traceability, ubiquity,
understandability, upgradability, usability

16. Software Quality Attributes first, define your terms
Define what matters to you about a quality attribute
by either
Describing scenarios or
Defining measures (or proxy measures)
Then research the tactics/patterns/appliances you
can use to achieve the quality

17. Availability & Resilience
Availability / Resilience
o A common measure is up-time: “5-nines”
o A scenario for a failure event might be
“When an out-of-memory failure occurs, the app should
recycle, and the system should continue operating as
normal within 30 seconds.”
o Attack Scenarios:
“When attack X happens, Y should happen and the
system should continue operating as normal”
quality attributes : define it

18. Modifiability is ... quality attributes : measure it
Modifiability / Maintainability / Evolution
o Could be measured as (estimated) cost or speed
Are these reasonable measures of modifiability?
o “It should not require a change request and 14 day
wait to correct a spelling error on the website”
o “Sprint velocity after a year of development should be
at least as good as in months 3 to 12”

19. • What is a Quality Attribute?
• What does “Reasoning about…”
mean?
• What are Stakeholder Concerns?
• What is an Architecture Description and
how does it help?
4 Key Concepts The promise of Software Architecture

20. and even to predict
What is “Reasoning
about…”?
estimate
measure
risk-evaluate
account for
cost-benefit-analyse
calculate
quantify
validate
budget
everything

21. What is “Reasoning about…”? Show me the numbers
♣ Being able to describe, define,
measure, calculate, test and even
predict how a system will behave …
♣ … preferably in advance of paying
the full cost of delivery and preferably
before missing the timeframe in which
the system is still useful

22. Abstraction is the key to reasoning even if the seats are concrete

23. Abstraction: Number of seats I am not a number!
50

24. • What is a Quality Attribute?
• What does “Reasoning about…” mean?
• What are Stakeholder Concerns?
• What is an Architecture Description and
how does it help?
4 Key Concepts The promise of Software Architecture

25. 4 Key Concepts Such many stakeholders
Not only the customer & the end-user but also…

26. Reconciling conflicting stakeholder needs …

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

28. 4 Key Concepts The promise of Software Architecture
• What is a Quality Attribute?
• What does “Reasoning about…”
mean?
• What are Stakeholder Concerns?
• What is an Architecture Description
and how does it help?

29. Abstraction: Number of seats Maths: Reason by abstraction

30. Abstraction: Number of seats I am not a number!
50

31. Abstraction: power to weight ratio Maths: Reason by abstraction

32. Abstractions: power & weight Maths: Reason by abstraction
74kW 12t

33. Views and Viewpoints

34. Different viewpoints there is no all-encompassing viewpoint

35. Modifiability, Extensibility, Evolvability

36. Modifiability & Extensibility

37. Load balancing as a tactic for scaling

38. Load balancing as a tactic for scaling

40. 4+1, Updated

41. 20 years on … “6 + 0 + 1”
Rozanski & Woods, Software Systems Architecture, 2nd ed

42. The Claim of Software Architecture
To enable Reasoning about:
… the Quality Attributes of
Software-intensive Systems
… to meet Stakeholder’s Concerns
… using Architecture Descriptions
of the system’s fundamental
structure(s)
in terms of its elements, relationships, properties and principles
Why software architecture?

43. What is “The Architecture” of a
system?
rough cut definitions
“… the fundamental structures or
organisation of your code”
“… all the rules & design decisions you have
get right up-front, because they are too
expensive to change later.”

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

45. Architecture is ... what does fundamental mean?
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”

46. Architecture is ... Kruchten, updated 2009
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

47. How to produce an architecture A catalogue & a method
How can we design systems to meet quality
requirements?
1) A catalogue of off-the-shelf tactics,
components, appliances, patterns,
frameworks, reference architectures… with
known quality–impacts
2) A method for applying them when
designing your system

48. catalogues of patterns, tactics, …
A (very long) Reading List
http://bing.com/search?q=architecture+tactics
http://bing.com/search?q=reference+architectures
http://google.com/search?q=architecture+pattern
http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap28.html
Rozanski & Woods, Software Systems Architecture
Bass et al, Software Architecture in Practise
Buschmann et al,
Pattern-Oriented Software Architecture Vols 1–5
Blue Peter Architecture

49. Patterns,Tactics, Appliances Off the shelf architecture
Including …
Pipe and Filter Architecture, Blackboard Architecture, Hexagonal Architecture,
Layered Architecture, Service Oriented Architecture, Message Oriented
Distributed Architecture, Client-Server, Client-Proxy Server, Master-Slave,
Microservices, Reactor, Replication, Transactions, ACID, Eventual Consistency,
Subsystem Interface, RDBMS, NoSQL DB, Graph Database, Datawarehouse,
GUI, Command Line Interface, Batch Processing, Thread Pool, Activator, Factory,
Dependency Injection, File System, Web Application, Sharding, Horizontal
Scaling, Load Balancer, Message Queues, Publish-Subscribe, Request Broker,
Web Services, Desktop Applications, Mobile Apps, Virtual Machine, Model View
Controller, Domain Model, Domain Driven Design, Immutability, Caching, Proxy,
Facade, Bridge, Adapter, Mediator, Decorator, Command, Interpreter, Web Farm,
Web Garden, P2P, ORM, Data Mapper, Active Record, Tokens, Locks, Monitors,
Heartbeat, Error detection, Backup and DR, the InterWebs, LAN, WAN, AES, PKI,
Flash Drives, Gigabit Ethernet, WPA2-PSK

50. a method for designing an
architecture
1. Draw a box for the system. Surround it
with the external actors which/who must
interact with it.
2. List the Architecturally Significant
Requirements in priority order
3. Start at the top of the list and work down
4. For each requirement, Identify or Create a
Partition of the system which will meet
that quality requirement
5. Identify tactics/patterns/appliances which
achieve the Quality Requirement
6. Goto 2
Simplified from Bass et. al.

51. Simple Case Study No relation to Uber
Our New Startup
• sÜper is an application which will find other
sÜper users near you, and help you to
arrange a lift share.
• Business plan: Grow users to critical mass in
year 1, charge a fee from year 2 onwards

52. Functional & Quality Requirements
Key Functionality
•Based on the sUper user’s geolocation, find their nearest peers
•Enable communication & appointment making between
Quality Requirements
• Must be mobile/geo-based
• Must be very very simple & fast to use & not make
embarrassing mistakes
• Must be virally attractive
• Must (appear to) be reliable
• Available 24/7
• Must be cheap to build & maintain for the 1st year
• Must cope with viral growth in user base
• Must keep user data especially payment data secure
Are not un-related to each other

53. ASRs
Prioritised Architecturally Significant Requirements
1. Deployability: Must run on mobiles
2. Usability: Must be very very simple
3. Usability/Performance: Must be fast to use
4. Usability/Accuracy: Not make embarrassing mistakes
5. Low Initial Cost & Time to Market
6. Functionality: Communication between users
7. Functionality: Find nearby users
8. Scalability
9. Availability 24/7
because the architect said so …

54. 0. The Context Diagram

55. ASR 1. Deployable to Mobile Platforms

56. 2. Usability – Very Very Simple

57. 3. Usability – Performance

58. 4. Usability-Accuracy

59. 5. Low Initial Cost/Time to Market

60. 6. Key Functionality 1: Communication

61. 7. Key Functionality 2: Find Nearby Users

62. 8. Scalability

63. 9. Availability

64. Et voila. We have most of an architecture ….

65. Software Architecture thank you and good-bye
http:www.cafe-encounter.net/about/