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

.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.

E6cffbf3b7a5fbfee4707033ef1636f5?s=128

dotnetday

May 28, 2019
Tweet

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

  8. None
  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