RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM...
Transcript of RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM...
![Page 1: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/1.jpg)
RAD: Really Awful Design - Really?
Rob Day & Eoin Woods Agile Conference, September 2005
![Page 2: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/2.jpg)
Slide 2 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Workshop Organisation
• Session Objectives & Introductions • RAD Origins – Some Architectural Musings • Software Architecture - Overview • Software Architecture in DSDM • Concept of an Architectural Filter • Working Groups • Consolidation & Review
![Page 3: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/3.jpg)
Slide 3 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Session Objectives
Purpose of the workshop: • To consider the role of architectural design in software
development projects, • Building on the experience of an earlier workshop at DSDM
Netherlands in 2004.
The prime deliverables will be:- 1. A list of factors to consider in the form of an "Architecture
Suitability Filter". 2. A recommendation as to whether or not the Architectural
Suitability Filter is a concept worth pursuing as a DSDM White Paper.
![Page 4: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/4.jpg)
Slide 4 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Introductions
Rob Day • Chief Technology Officer • mwr, a publisher of digital interactive learning resources • DSDM practitioner & trainer, member since 1996
Eoin Woods • Principal Consultant • Zuhlke Engineering, a technology solutions vendor • Co-author of “Software Systems Architecture, working with
Stakeholders using Viewpoints and Perspectives”
… and yourselves • name, role, organisation • Workshop objectives
![Page 5: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/5.jpg)
Slide 5 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
RAD Origins – Some Architectural Musings
• Introduction of GUI tools & DB tools • Focus on prototyping new front-end onto existing back-end • Naturally lead to adoption of 2-tier architecture • Generally implicit rather than crafted decision-making • Focus on KISS and document-lite approaches • DSDM conceived to re-dress the drift away from formality • DSDM focused on single project
![Page 6: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/6.jpg)
Slide 6 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Software Architecture – Overview
• Software Architecture – Definition • Software Architecture in Context • Architecture and Requirements • Quality Properties • Architecturally Significant • Context of the Role
![Page 7: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/7.jpg)
Slide 7 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Software Architecture - Definition
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them
Bass, Clements and Kazman (SEI) Software Architecture in Practice
![Page 8: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/8.jpg)
Slide 8 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Software Architecture in Context
Requirements
Design
The crucial bridge between requirements and design
Architecture
![Page 9: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/9.jpg)
Slide 9 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Architecture and Requirements
• Requirements frame the architectural problem – Stakeholder needs and desires
• Yet, architecture influences requirements – “The art of the possible” – Helps stakeholder understanding of risk/cost – Helps stakeholder understanding of possibilities
![Page 10: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/10.jpg)
Slide 10 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Architecture and Requirements
Requirements
Architecture
This interplay is core to the architectural process
Desires
Possibilities
![Page 11: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/11.jpg)
Slide 11 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Quality Properties
• The non-functional characteristics of the system (“-illities”) – Performance, Security, Maintainability, …
• Quality properties are crucial to stakeholders – Slow functions don’t get used – Unavailable systems cause business interruption – Security problems cause headlines – Unmaintainable systems become irrelevant – Yet often overlooked during requirements and design
![Page 12: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/12.jpg)
Slide 12 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Quality Properties
• Quality properties are often an afterthought
– Often expensive to “retro-fit” – Disruption to existing operations – May conflict with existing qualities
• Achieving quality properties is a key architectural task
– Understanding the real stakeholder needs – Making tradeoffs (e.g. usability vs. security)
![Page 13: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/13.jpg)
Slide 13 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Architecturally Significant
• Not all decisions are architectural
– Make decisions at the right point / level
• Significance generally depends on context
• Architecturally significant decisions
– Visible by those in other stakeholder groups – Have a system wide impact
![Page 14: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/14.jpg)
Slide 14 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Context of the Role
• Requirements engineer / analyst – Provides the architect with requirements and
acts as a proxy user • Project Manager
– Manages the overall project (including the architect) • Design Authority / Technical Lead
– Responsible for internal technical integrity & build – Role may well be undertaken by the architect
• Technology Authority – Provides specialist knowledge to the architect
![Page 15: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/15.jpg)
Slide 15 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Context of the Role
Architect
Requirements Analyst
Technical Lead
Project Manager
Technology Authority
![Page 16: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/16.jpg)
Slide 16 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Software Architecture in DSDM
• Products, People and Processes • SAD Template • DSDM & TOGAF White Paper • Architecture in Other Development Approaches
![Page 17: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/17.jpg)
Slide 17 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
DSDM – Products, People and Processes
• Business Study (refined thereafter)
prepared during
• System Architecture Definition
• Team leader • Developer • Tester
• Technical Coordinator
responsibility of
contribute to
• Design Prototypes • Performance/Capacity Prototypes
• Business Area Definition • Development Plan • Prioritised Requirements List
related to
related to
![Page 18: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/18.jpg)
Slide 18 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
SAD Template
DEVELOPMENT ENVIRONMENT Components Non functional requirements Reuse Hardware Testing Database or object model Developer’s day to day
TARGET ENVIRONMENT Components Licensing Network Hardware Migration Strategy Backup and recovery Operations
SYSTEM ARCHITECTURE Software architecture Interfaces Context Diagram Reuse Security
![Page 19: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/19.jpg)
Slide 19 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
DSDM & TOGAF White Paper
• TOGAF = The Open Group Architecture Framework • White Paper identifies similarities, differences and how facets of
each could be used with the other • Key points of synergy:
– TOGAF principles, especially “architectural” – TOGAF emphasises “Enterprise Architecture” – TOGAF “Business scenarios” complement DSDM facilitated
workshops – TOGAF has comprehensive material on modelling
“Architectural Views” – TOGAF details an Architectural Change Management
process to establish and support the Enterprise Architecture – TOGAF can contribute to completion of DSDM products
![Page 20: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/20.jpg)
Slide 20 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
TOGAF 8-Phase Lifecycle
A: Architecture
Vision B:
Business Architecture
D: Technology Architecture E:
Opportunities And Solutions
F: Migration Planning
H: Architecture
Change Management
C: Info System
Architectures
G: Implementation
Governance Requirements
![Page 21: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/21.jpg)
Slide 21 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Architecture in Other Development Approaches
• Rational Unified Process (RUP) – Architectural views (4+1 model) – Architectural prototypes – Elaboration phase (to de-risk project)
• eXtremeProgamming (XP) – Design as an ongoing process (with code-test-listen) – Write tests first – Simplest design that runs the test suite – Avoid predicting tomorrow’s problems – Architecture captured in a “system metaphor”
![Page 22: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/22.jpg)
Slide 22 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Concept of an Architecture Filter
• Similar in concept to the DSDM Suitability/Risk List – 10 “critical success factors” – 7 project situational factors – 18 “additional” questions
• How do the DSDM principles relate to architecture?
• What impact do architectural aspects have on a DSDM project? – From an organisational perspective – From a system perspective – From a project perspective – Any other perspectives?
![Page 23: RAD: Really Awful Design - Really? - Artechra– TOGAF “Business scenarios” complement DSDM facilitated workshops – TOGAF has comprehensive material on modelling “Architectural](https://reader034.fdocuments.us/reader034/viewer/2022050605/5fad1987b8a8ef52d3072d36/html5/thumbnails/23.jpg)
Slide 23 of 14 © Rob Day & Eoin Woods Agile Conference, September 2005
Workshop
• Team work: – to identify list of factors
• Group work – to consolidate, categorise and refine list of factors
• Group work – to consider potential for a white paper.