SlideShare a Scribd company logo

XP-Manchester 2013 Software Architecture for Agile Developers Intro

Chris F Carroll
Chris F Carroll

The document discusses the significance of software architecture, outlining key elements such as quality attributes, architecturally significant requirements, views, and viewpoints necessary for effective system design. It emphasizes the importance of stakeholder concerns, communication, and dependency management to ensure systems can meet both functional and non-functional requirements. Through a case study of a vertical search startup, it illustrates the application of architectural principles in real-world scenarios.

TechnologyBusiness
1 of 63
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
What is (the point of) software architecture? Mark van Harmelen Chris F. Carroll xp-manchester 2013
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 ....
... 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
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
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?
Software Quality Attributes Calculate Everything Views & Viewpoints ARCHITECTURALLY SIGNIFICANT REQUIREMENTS MANAGE DEPENDENCIES Re-usable WITH AN Architecture IRON FIST
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
you can’t communicate You are not the Borg telepathically You must communicate your architecture if you want anyone else to work with it.
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
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
Which view do you need? I’d like to design a boiler-room
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
} estimate measure risk-evaluate account for cost-benefit-analyse everything calculate quantify validate budget know everything if you don’t, who will?
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?
Architecturally Significant Requirements Architecturally Significant what matters first? Requirements
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
Manage dependencies before they manage you Picture: Nature Reviews Neuroscience dependency <=> relationship <=> communication dependency : It’s complicated
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
Re-usable architecture fulfils the “hello world” requirement
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
Software Quality Attributes Calculate Everything Views & Viewpoints ARCHITECTURALLY SIGNIFICANT REQUIREMENTS MANAGE DEPENDENCIES Re-usable WITH AN Architecture IRON FIST
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
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
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
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
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
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
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
Software Quality Attributes Calculate Everything Views & Viewpoints ARCHITECTURALLY SIGNIFICANT REQUIREMENTS MANAGE DEPENDENCIES Re-usable WITH AN Architecture IRON FIST
Views and Viewpoints
Which view do you need? I’d like to design a boiler-room
4+1 (Kruchten, 1995) IBM developerworks
4+1, Updated
Information View System Context Entities, Relationships, Aggregate Roots Lifecycle, Ownership / Relationships Operational View X +1 the more the merrier?
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
♣ 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
♣ 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
♣ 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 ... ?
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
♣ 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
♣ 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
♣ 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
♣ 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
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
♣ 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
♣ 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
“Assets” Security—it’s a process. Rozanski & Wood Software Systems Architecture, 2011
♣ 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
♣ Describe scenarios ♣ Define measures ♣ Research tactics ♣ Mandate the approach Software Quality Attributes the bridge fulfilled the functional requirement
Definitions of architecture
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?
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
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
Architecturally Significant Requirements
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
Re-usable architecture fulfils the “hello world” requirement
standard patterns the re-usable kitteh pattern
think out of inside the box let’s not re-invent the wheel
Manage Dependencies with an Iron First
Manage dependencies before they manage you dependency === relationship === communication dependency : It’s complicated
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
} estimate measure risk-evaluate account for cost-benefit-analyse everything calculate quantify validate budget know everything if you don’t, who will?
Software Quality Attributes MANAGE DEPENDENCIES WITH AN Views & IRON FIST Viewpoints ARCHITECTURALLY SIGNIFICANT REQUIREMENTS Calculate Everything Re-usable Architecture

More Related Content

What's hot (6)

PDF
SOFTWARE PRODUCT DEVELOPMENT GOVERNANCE FRAMEWORK
Arul Nambi
 
PDF
SSBSE 2012 Keynote
Massimiliano Di Penta
 
PPTX
Limewood Event - VMware
BlueChipICT
 
DOCX
RKVLatestResume2015
Keith Vescovo
 
PDF
Modern Software Infrastructures Revisited
ibogicevic
 
PDF
Engineered Resilient Systems, overview and status, 31 october 2011
RNeches
 
SOFTWARE PRODUCT DEVELOPMENT GOVERNANCE FRAMEWORK
Arul Nambi
 
SSBSE 2012 Keynote
Massimiliano Di Penta
 
Limewood Event - VMware
BlueChipICT
 
RKVLatestResume2015
Keith Vescovo
 
Modern Software Infrastructures Revisited
ibogicevic
 
Engineered Resilient Systems, overview and status, 31 october 2011
RNeches
 

Similar to XP-Manchester 2013 Software Architecture for Agile Developers Intro (20)

PDF
Ten Advices for Architects
Eberhard Wolff
 
PDF
10 Hinweise für Architekten
adesso AG
 
PPTX
Software Architecture Intro
Sadhana Ghalsasi
 
PDF
2 - Architetture Software - Software architecture
Majong DevJfu
 
PDF
Software archiecture lecture03
Luktalja
 
PDF
UW Presentation - Architecture Trade-off Analysis Method
Shrikant Palkar
 
PDF
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
John Ortiz
 
PDF
2
Majong DevJfu
 
PPTX
Software Architecture: Why and What?
Chris F Carroll
 
PDF
Scott Whitmire - Just What is Architecture Anyway
iasaglobal
 
PDF
Software architecture for developers
Chinh Ngo Nguyen
 
PDF
Design concepts in concepts of engineering design
SureshvSuri1
 
PDF
Software Architecture and Design Introduction
Usman Khan
 
PPT
Unit 1
KRAMANJANEYULU1
 
PPTX
Designer engineering on the Data Science student
ArjunM99136
 
PDF
Architecture Description Languages: An Overview
elliando dias
 
PDF
Obeo thales@md day2011
MDDAY11
 
PPTX
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
MahmoudZidan53
 
PPTX
Software architecture simplified
Prasad Chitta
 
PPT
OO Development 1 - Introduction to Object-Oriented Development
Randy Connolly
 
Ten Advices for Architects
Eberhard Wolff
 
10 Hinweise für Architekten
adesso AG
 
Software Architecture Intro
Sadhana Ghalsasi
 
2 - Architetture Software - Software architecture
Majong DevJfu
 
Software archiecture lecture03
Luktalja
 
UW Presentation - Architecture Trade-off Analysis Method
Shrikant Palkar
 
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
John Ortiz
 
2
Majong DevJfu
 
Software Architecture: Why and What?
Chris F Carroll
 
Scott Whitmire - Just What is Architecture Anyway
iasaglobal
 
Software architecture for developers
Chinh Ngo Nguyen
 
Design concepts in concepts of engineering design
SureshvSuri1
 
Software Architecture and Design Introduction
Usman Khan
 
Unit 1
KRAMANJANEYULU1
 
Designer engineering on the Data Science student
ArjunM99136
 
Architecture Description Languages: An Overview
elliando dias
 
Obeo thales@md day2011
MDDAY11
 
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
MahmoudZidan53
 
Software architecture simplified
Prasad Chitta
 
OO Development 1 - Introduction to Object-Oriented Development
Randy Connolly
 
Ad

More from Chris F Carroll (6)

PDF
Software Technical Design for Information Security: A short intro for Tech Le...
Chris F Carroll
 
PDF
What is Security, anyway? Software architecture for information security part...
Chris F Carroll
 
PPTX
Deep Learning in 90 seconds. With a side of Algorithm Bias
Chris F Carroll
 
PDF
Agile Software Architecture
Chris F Carroll
 
PDF
Clojure (and some lisp) in 10 mins for OO developers
Chris F Carroll
 
PPT
Doing Architecture with Agile Teams IASA UK Summit 2013
Chris F Carroll
 
Software Technical Design for Information Security: A short intro for Tech Le...
Chris F Carroll
 
What is Security, anyway? Software architecture for information security part...
Chris F Carroll
 
Deep Learning in 90 seconds. With a side of Algorithm Bias
Chris F Carroll
 
Agile Software Architecture
Chris F Carroll
 
Clojure (and some lisp) in 10 mins for OO developers
Chris F Carroll
 
Doing Architecture with Agile Teams IASA UK Summit 2013
Chris F Carroll
 
Ad

Recently uploaded (20)

PDF
CIFDAQ Market Insights for July 7th 2025
CIFDAQ
 
PDF
Using FME to Develop Self-Service CAD Applications for a Major UK Police Force
Safe Software
 
PDF
Achieving Consistent and Reliable AI Code Generation - Medusa AI
medusaaico
 
PDF
Agentic AI lifecycle for Enterprise Hyper-Automation
Debmalya Biswas
 
PDF
How Startups Are Growing Faster with App Developers in Australia.pdf
India App Developer
 
PDF
Newgen Beyond Frankenstein_Build vs Buy_Digital_version.pdf
darshakparmar
 
PDF
"Beyond English: Navigating the Challenges of Building a Ukrainian-language R...
Fwdays
 
PDF
The Rise of AI and IoT in Mobile App Tech.pdf
IMG Global Infotech
 
PDF
Smart Trailers 2025 Update with History and Overview
Paul Menig
 
PDF
CIFDAQ Weekly Market Wrap for 11th July 2025
CIFDAQ
 
PDF
CIFDAQ Token Spotlight for 9th July 2025
CIFDAQ
 
PDF
IoT-Powered Industrial Transformation – Smart Manufacturing to Connected Heal...
Rejig Digital
 
PDF
New from BookNet Canada for 2025: BNC BiblioShare - Tech Forum 2025
BookNet Canada
 
PPTX
From Sci-Fi to Reality: Exploring AI Evolution
Svetlana Meissner
 
PDF
July Patch Tuesday
Ivanti
 
PDF
Biography of Daniel Podor.pdf
Daniel Podor
 
PDF
Fl Studio 24.2.2 Build 4597 Crack for Windows Free Download 2025
faizk77g
 
PDF
Building Real-Time Digital Twins with IBM Maximo & ArcGIS Indoors
Safe Software
 
PPTX
COMPARISON OF RASTER ANALYSIS TOOLS OF QGIS AND ARCGIS
Sharanya Sarkar
 
PDF
HubSpot Main Hub: A Unified Growth Platform
Jaswinder Singh
 
CIFDAQ Market Insights for July 7th 2025
CIFDAQ
 
Using FME to Develop Self-Service CAD Applications for a Major UK Police Force
Safe Software
 
Achieving Consistent and Reliable AI Code Generation - Medusa AI
medusaaico
 
Agentic AI lifecycle for Enterprise Hyper-Automation
Debmalya Biswas
 
How Startups Are Growing Faster with App Developers in Australia.pdf
India App Developer
 
Newgen Beyond Frankenstein_Build vs Buy_Digital_version.pdf
darshakparmar
 
"Beyond English: Navigating the Challenges of Building a Ukrainian-language R...
Fwdays
 
The Rise of AI and IoT in Mobile App Tech.pdf
IMG Global Infotech
 
Smart Trailers 2025 Update with History and Overview
Paul Menig
 
CIFDAQ Weekly Market Wrap for 11th July 2025
CIFDAQ
 
CIFDAQ Token Spotlight for 9th July 2025
CIFDAQ
 
IoT-Powered Industrial Transformation – Smart Manufacturing to Connected Heal...
Rejig Digital
 
New from BookNet Canada for 2025: BNC BiblioShare - Tech Forum 2025
BookNet Canada
 
From Sci-Fi to Reality: Exploring AI Evolution
Svetlana Meissner
 
July Patch Tuesday
Ivanti
 
Biography of Daniel Podor.pdf
Daniel Podor
 
Fl Studio 24.2.2 Build 4597 Crack for Windows Free Download 2025
faizk77g
 
Building Real-Time Digital Twins with IBM Maximo & ArcGIS Indoors
Safe Software
 
COMPARISON OF RASTER ANALYSIS TOOLS OF QGIS AND ARCGIS
Sharanya Sarkar
 
HubSpot Main Hub: A Unified Growth Platform
Jaswinder Singh
 

XP-Manchester 2013 Software Architecture for Agile Developers Intro

  • 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
  • 31. Which view do you need? I’d like to design a boiler-room
  • 32. 4+1 (Kruchten, 1995) IBM developerworks
  • 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
  • 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
  • 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