.NET Day 19 - Software Architecture in the Agile World by Urs Enzler

Software architecture stands for stability and far-reaching decisions. How should that be possible in flexible and agile software development? I’ll show you in this presentation how a software architecture can be evolved iteratively and incrementally ,how decisions can be deferred to the right moment and some agile architecture patterns. You’ll learn how agile architectures enable quick changes, simple architecture validation and always deployable running systems.

Transcript

1. bbv Software Services AG ARCHITEKTUR, ABER BITTE AGIL! URS ENZLER @ursenzler www.bbv.ch
2. Max the architect
3. NEW PRODUCT find team members to staff a team
4. KNOW-HOW PORTFOLIO .Net: WPF, EF UX: Usability Testing Testing: Exploratory Testing Emma Max Software Architecture: ATAM RE: agile RE TEAM NEEDS .Net: EF Software Architecture RE: agile RE MATCH
5. Version 1 in-house Version 2 as a service
6. CHALLENGE Where to start when there is just a product idea?
7. INITIAL REQUIREMENTS WORKSHOP
9. CHALLENGE Incremental &and iterative. INCREMENTAL ITERATIVE
10. in-house support scaling low infrastructure costs multitenancy as a service needs rewrite for “as a service”
11. DECOMPOSITION AND COMPOSITION PROBLEM DOMAIN DECOMPOSITION DATA TRANSACTIONS COMPOSITION COUPLING COMPENSATION OWNERSHIP OVERALL SIMPLICITY
12. DECOMPOSITION COMPOSITION
13. TEAM
14. SIMPLIFICATION PARTIAL WORKFLOWS FAKES HAPPY PATH FEATURE CUT
15. CHALLENGE How to make decisions with little knowledge? UNCERTAINTY
16. SPLIT AND DEFER ABSTRACTION WILFUL IGNORANCE SIMPLIFICATION DECISION DELEGATION
17. PERSISTENCE 1. DOM only in-memory 2. File (serialized DOM) 3. Database here you know about - size of data - load - throughput SIMPLIFICATION WILLFULL IGNORANCE ABSTRACTION
18. USER INTERFACE 1. build business logic independent of UI 2. design and implement UI, and call business logic here you know about - needed data - workflows - business needs DECISION DELEGATION
19. CHALLENGE How to change things without breaking them?
20. The state or quality of being simple - easy to understand or explain. SIMPLICITY
21. SIMPLICITY UNDERSTANDABILITY CHANGEABILITY REFACTORABILITY
22. INDICATORS OF SIMPLICITY Small size Low number of contained concepts Low number of interactions
23. ASPECTS OF SIMPLICITY •Bounded •Conciseness •Expressiveness •Readable •Understandable •Unsurprising •Self-explanatory •Reassuring
24. ABSTRACT CONCRETE SPECIFIC GENERIC SIMPLE DIFFICULT SIMPLICITY INSIGHT SIMPLER MODEL/TECHNOLOGY
25. EXECUTABLE SPECS TDD / ATDD / BDD
26. Use Cases Interface Adapters Frameworks & Drivers Entities Direction of Dependencies UI External Interfaces DB Web Program Flow CLEAN ARCHITECTURE replaceable details testable Tests
27. Add Skill Employee Skill Team UI DB Tests Staff Team
28. CHALLENGE How to get fast feedback?
29. CONTINUOUS DELIVERY
30. TEAM ARCHITECTURE WORKSHOP
31. ARCHITECTURE ASSESSMENT
32. CHALLENGE Requirements and technologies change!
33. FLEXIBILITY supports change exchangable parts
34. SEPARATION OF CONCERNS change in one concern has very limited range of side-effects
35. SOFTWARE REFLECTS USER’S MENTAL MODEL
36. EVOLVABILITY matches current needs open for future needs
37. 50 users single server 10’000 users server farm
38. MULTI-TENANCY OPTIMIZE INFRASTRUCTURE COSTS SCALING SECURITY VALIDATION EMPLOYEE DATA (JSON) TEAM DATA (JSON) ALGORITHM NICE UI ALGORITHM Simplification: json is human writable Simplification: no parametrization no simplification anymore Assumption: no errors A POSSIBLE EVOLUTION PATH DB
39. CHALLENGE No time for improvements!
40. http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ FUTURE PAST BUSINESS TECHNICAL SUPPORT BUGS TECHNICAL DEBT ARCHITECTURAL INNOVATION FEATURES ? % ? % ? % ? % PRODUCT PRIORITISATION QUADRANTS
41. PROBLEM DOMAIN DECOMPOSE ADAPT TRACER-BULLET FEEDBACK RELEASE COMPOSE
42. VISION INITIAL REQUIREMENTS WORKSHOP WHERE TO START? INCREMENTAL / ITERATIVE DECOMPOSITION / COMPOSITION SIMPLIFICATION DECISIONS SPLIT AND DEFER CHANGE WITHOUT BREAKING EXECUTABLE SPECS SIMPLICITY CLEAN ARCHITECTURE FAST FEEDBACK AND ADAPT CONTINUOUS DELIVERY ARCHITECTURE WORKSHOP ASSESSMENTS CHANGE NO TIME FLEXIBILITY: MENTAL MODEL, SEPARATION OF CONCERNS EVOLVABILITY: EVOLUTION PATHS PRODUCT PRIORITISATION QUADRANTS PROBLEM DOMAIN DECOMPOSE ADAPT TRACER-BULLET FEEDBACK RELEASE COMPOSE
43. URS ENZLER urs.enzler@bbv.ch twitter: @ursenzler blog: www.planetgeek.ch www.bbv.ch/blog OSS lead: Appccelerate user group: www.dotnet-zentral.ch Architektur in agilen Projekten bbv Academy: http://www.bbv.ch/de/bbv-academy.html