Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Democratising Software Architecture

100 views

Published on

Today’s mainstream acceptance of Agile+DevOps as the preferred way of working once again raises questions of what architecture work is and who does it. It simultaneously challenges much of our previously accepted wisdom, preferring architecture to be a “shared commons” across the development organisation, while demanding a sophisticated level of software architecture practice to deliver on the promises of Agile+DevOps.

One way of describing this situation is the need to “democratise” software architecture so it becomes a shared responsibility rather than a centralised impediment to rapid delivery. In this talk we’ll examine the challenges of software architecture in today’s modern distributed teams and ask how we might make the architecture of their systems a shared responsibility to allow them to achieve the software architecture that they need at the speed that they need it.

Published in: Software
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Democratising Software Architecture

  1. 1. Democratising Software Architecture Eoin Woods Endava @eoinwoodz ICSA 2019, Hamburg, March 2019 1
  2. 2. Eoin Woods • Endava’s CTO, based in London • 10+ years in product dev - Bull, Sybase, InterTrust • 10 years in capital markets applications - UBS and BGI • Software engineer, then architect, now CTO • Software engineer in theory & practice (BSc, MSc, recently PhD) • Author, editor, speaker, community guy
  3. 3. 3 DISCLAIMER These are my views based on my experience in the domains I have worked in. Others may differ in their views !
  4. 4. EVOLVING SOFTWARE ARCHITECTURE 4
  5. 5. 5 ages of software Systems Intelligent Connected (2020s) Internet is the System (2010s) Internet Connected (2000s) Distributed Monoliths (1990s) Monolithic (1980s)
  6. 6. Architecture has changed too Computing Era Architecture Concern Monolithic Era => Structuring programs Distributed Monoliths Era => Architecture emerges Internet-Connected Era => Quality properties Internet-is-the-System Era => Architecture at speed Intelligent Connected Era => … ?
  7. 7. Historical Context • Central small group • Organisation of large pieces • Relatively static connections • Largely completed before implementation • Structures, qualities, stakeholders, technology choices 7 https://donmaclennan.com/
  8. 8. What has changed? 8 FLUID EVOLVING ARCHITECTURE DevOps Microservices Cloud Agile
  9. 9. What is the problem? 9 ? ? !! ? !! !! ? !!
  10. 10. Our traditional model is of less value • Constant evolution => less ”certainty” early in lifecycle • Less decided early in lifecycle => less value in thorough ”up front” architecture 10 • Autonomous teams => independent activity • Independent activity => constant parallel decision making • Constant decisions => architect overload => blocks progress
  11. 11. Is architecture still needed? 11 • Difficult quality attributes • Stakeholders don’t go away • Still have tradeoffs • Cross cutting concerns across many independent elements • BUT traditional ”structural” focus may need to change Cross-Cutting Concerns Tradeoffs Stakeholders Quality Attributes Yes!
  12. 12. WHAT PRACTITIONERS DO 12
  13. 13. Software Architecture in Practice • Empowered cross-functional teams • Less “architects” more “engineers” • Lightweight description – C4, ADRs • Code Analysis – dependency visibility • Runtime Analysis – dependency visibility, trends • Informal description – Wiki, PowerPoint, Visio • Modelling – occasional use of UML and Archimate 13
  14. 14. C4 Model • Simon Brown’s accessible 4-view model for software architecture • Context • Containers • Component • Code (class diagram - optional) • Optional Landscape, Dynamic and Deployment views • Structurizr tool • Widely recognized in industry 14 c4model.com
  15. 15. Architecture Decision Records • Old idea “rediscovered” by Michael Nygard in 2011 • Simple textual decision records using templates • Stored with the code • Nygard’s form: • Title, Status, Context, Decision & Consequences 15 thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions github.com/joelparkerhenderson/architecture_decision_record
  16. 16. Code Analysis • Generally static code analysis • Open source tools dominate • SonarQube in particular • “Code doesn’t lie” • Main architectural aspect is dependency analysis 16
  17. 17. Runtime Analysis • Response to dynamic nature of microservices • Distributed monitoring & tracing • Jaeger, Zipkin • Prometheus + Grafana • Log aggregation & analysis - ELK • AppDynamics & NewRelic • “Production is reality” 17
  18. 18. Visio, PowerPoint, Wiki, … • Where most ADs end up • Quality varies from useless to very valuable • Familiar & highly accessible • Usually custom syntax and semantics • Interpretation, precision and consistency often limited 18
  19. 19. Modelling: UML and Archimate • Rare choice today • Their genericity is a difficulty • UML good base for a DSL … but significant investment needed • Archimate useful for EA but not really solution or software arch • Tools can get in the way • Can actually be a communication barrier 19
  20. 20. A NEW APPROACH 20
  21. 21. 21 Architecture is a skill not a role Principles, styles & patterns over structures Delegate & share wherever possible ”Little and often” (and adapt) Aim for “shared commons” Stream of decisions, not “one off” architecture Architecture Work in the New World
  22. 22. 22 Architecture work in every sprint Decisions, principles, styles, patterns Deliver decisions as they are needed Form an inclusive architecture group Practical tests to validate architecture work Keep the architecture ”close to the code” Key Practices
  23. 23. 23 RDCA (Risk & Cost Driven Architecture) Eltjo Poort, CGI eltjopoort.nl
  24. 24. Architecturally Evident Code • George Fairbanks • Code reflects the architecture • Names, structures line up • Changes code packaging • Can affect testing • Often “messes up” architecture! • Can be hard to check • ArchUnit 24
  25. 25. Common Problems • Sharing and managing architecture information (AKM) • Lack of artefacts => misunderstanding, knowledge loss • Understanding the system-wide view • Resistance to any design work (“we’re agile”) • Desire for a ”complete” architecture up front • Enterprise architects (!) 25
  26. 26. FOR RESEARCH 26
  27. 27. Research vs Practice Disconnection RESEARCH PRACTICE Models and theories Technologies, patterns, code Architecture as separate activity Architecture as dev activity Completed architecture Just enough architecture Solving idealised problems Focus on today’s delivery Papers, academic conferences Github, blogs, conferences Validation via small survey Validation by production operation27
  28. 28. Some Suggestions WHILE PLANNING WHILE RESEARCHING Link to industry projects Prioritise flow of change to production Understand practice through OSS Codify ideas in code, patterns, templates Watch industry event topics* Be sensitive to adoption effort vs validation level Attend industry events* Be aware of standard tools Consider motivation & validation 28 * QCON, SATURN, DevTernity, JAX, NDC, …
  29. 29. TO CONCLUDE 29
  30. 30. Software development is changing: so will software architecture 30 Agile + DevOps change how we WORK Cloud + Containers change how we BUILD Less “Upfront” Architecture Quality Attributes, Tradeoffs, Stakeholders Flow Of Decisions & Guidance Changes to Architect’s Work Changes to Architect Training
  31. 31. Architect: From Purveyor of Wisdom … 31
  32. 32. … to Trusted Leader and Advisor 32
  33. 33. Eoin Woods Endava eoin.woods@endava.com @eoinwoodz 33 THANK YOU …

×