The Architect's Blind Spot - Ilionx Dev Days 2019
- 1. @p3pijn The Architect's Blind Spot: How to align architecture and organizational structure to better your products, processes and people Pepijn van de Kamp @p3pijn
- 2. @p3pijn Greater flexibility Shorter lead times Higher scalability Lower costs Trends in software architecture are about handling increased expectations
- 3. @p3pijn “Software development is a technical activity conducted by human beings.” Niklaus Wirth
- 4. @p3pijn Social dynamics are everywhere Especially in our software organizations…
- 5. @p3pijn Social dynamics are everywhere Especially in our software organizations… Dependencies ARCHITECTURE Conway’s Law Feedback Loops Team size Channels Overcomplexification Politics Trust Value congruence Communication Intrinsic motivation Knowledge distribution Team distribution
- 6. @p3pijn The architect’s blind spot How is the implementation of our product evolving? Does our architecture allow us to deliver software efficiently? Are we creating and retaining the right knowledge?
- 7. @p3pijn Skillset for the organization-aware architect Oversee personal & tool-based feedback loops Align organization & architecture Influence knowledge creation & retention Analysis techniques
- 9. @p3pijn Plan versus Reality The design Website Accounts Savings Loans Batch processing Storage External systems The implementation Website (and data validation) Savings Batch processing Storage External systems Pension LoginAccounts Loans
- 10. @p3pijn Where did it go wrong? Designed architecture Implemented architecture
- 11. @p3pijn Tower syndrome What the %$#& are they doing?? What do they want??? What do they want??? Broad view Architects Ivory tower Poor visibility Poor visibility
- 13. @p3pijn Broken feedback loops Without governing the software architecture of a system, its implementation will evolve following the path of least resistance
- 14. @p3pijn The result of lack of architectural governance… Unintended dependencies Loss of initial structure Cyclic dependencies Tightly coupled architecture
- 15. @p3pijn Need for architectural governance in the real world
- 16. @p3pijn Coupling of a Core banking system 10 MLOC of COBOL/JCL 25 years of evolution Currently 250 developers Original structure has eroded Changing this system is very slow & very costly Tightly coupled architectures can bring business to a halt
- 17. @p3pijn Feedback on software products Personal feedback Subjective Timeliness depends on availability of reviewer Sensitive to context Specific suggestions Tool-based feedback Objective Fast and scalable Generic suggestions Combine tool-based measurement with manual review and discussion
- 18. @p3pijn Tool-based feedback for developers Example: Capturing architecture characteristics as ArchUnit test cases Controllers Services Persistence Example from https://github.com/TNG/ArchUnit-Examples
- 19. @p3pijn Feedback Loops Blindspot How is the implementation of our product evolving? Symptoms Gap between design and implementation Tightly coupled architecture Caused by Broken or missing feedback loops Best practice Introduce personal and/or tool-based feedback tailored to the need of the stakeholder
- 20. @p3pijn Part II: Aligning organization & architecture
- 21. @p3pijn Conway’s Law Organizations produce system designs that reflect their communication structures Team A Team B Team C Component A Component B Component C Organization System Design Mel Conway, 1967
- 22. @p3pijn High performing teams Aligning team organization with software architecture is paramount to being efficient
- 23. @p3pijn Components in a typical 3-tier architecture Source: SIG benchmark ■ Architecture Component ■ Datastore ■ Dependency Data Access Business Logic UI 30% 40% 30% Components as implemented in system X Data Access Business Logic UI 85% 10% 5% Front-end Team Back-end Team DBA
- 24. @p3pijn Duplication of work Making assumptions API evolution breaks consumers Coordination overhead Changes propagate No end-to-end responsibility Team per layer Team per functional sliceMulti-team component No code ownership Parallel work Defect prone Common team topologies Different team topologies have their own trade-offs
- 25. @p3pijn Misalignment of organization & architecture can bring business to a halt Coordination overhead Long lead times High defect rates Parallel work Lack of code ownership Who owns this problem?
- 26. @p3pijn Team 1 Team 2 Team 3 Team 4 DA B C E H F G I Maneuvers for improving alignment of organization & architecture • Split up or merge architectural components • Introduce a dedicated team • Promote autonomy & team ownership • Limit coordination overhead & parallel work Mapping of teams to architecture components
- 27. @p3pijn “Rabobank constructed a physical model of its organization and IT systems to understand architecture and find improvements” Rabobank Case https://www.linkedin.com/pulse/bian-models-aid-construction-rabobank- builds-3d-model-hans-tesselaar/ Mapping of teams to architecture components in a large IT landscape
- 28. @p3pijn Aligning organization & architecture Blindspot Does our architecture allow us to deliver software efficiently? Symptom Long lead times / high defect rates Caused by Misalignment between teams and architecture components Coordination overhead between teams Best practice Map teams to architecture components to find opportunities for better alignment Reduce dependencies & parallel work
- 29. @p3pijn Part III: Knowledge Creation & Retention
- 30. @p3pijn A model to reason about knowledge < Generalist > <Specialist> Breadth of knowledge Depthofexpertise T-shaped profiles McKinsey & Co. 1980
- 31. @p3pijn Emphasizes the problem domain Allows for picking a technology that fits problem Developers become • specialists in a functional area • generalists in the technology stack Emphasizes the solution domain Layer dictates the technology Developers become • specialists in a technology • generalists in functional areas Technology-focused knowledge creation Functional-focused knowledge creation
- 32. @p3pijn A jack of all trades …is a master of none? Mastery takes practice To full-stack of not to full-stack?
- 33. @p3pijn What knowledge do you want to build in your organization? • Communication skills • Work ethics Generalist • Front-end • Back-end (C#/Java/…) • Network/Infra • Integration • Database • Mainframe Technologist Breadth of knowledge Depth of expertise • Software Engineering principles • Full-stack / ability to familiarize with new technology • Medical • Payments • Government • Insurance • Search • Utilities • … Domain expert • Reliability • Performance • Security • Maintainability • UX Quality expert
- 34. @p3pijn Knowledge retention Who owns this problem? Knowledge risk in the IT organizations is typically hard to identify
- 35. @p3pijn Knowledge retention Key developer leaves company Productivity drop Loss of investment 0% 25% 50% 75% 100% Component I Component H Component G Component F Component E Component D Component C Component B Component A % of commits made by active / former developers Available knowledge per component (based on commit history < 3 years) active developers former developers Steer on knowledge transfer on strategic components when onboarding new developers
- 36. @p3pijn 1995 1998 2001 2004 2007 2010 2013 2016 2019 Introduced new functionality Change to existing functionality Fixed defect Knowledge retention History of code changes in a 20+ year old COBOL mainframe Developer with >10 years of knowledge of the code- base returns to the team
- 37. @p3pijn Knowledge Creation & Retention Blindspot Are we creating and retaining the right knowledge? Symptom Teams lack understanding of problem domain Drop in productivity when specific people leave the team Caused by Architecture dictates technology and emphasizes solution domain Dependency on specific people with knowledge monopoly Best practice Understand how architecture drives knowledge creation Monitor available knowledge of strategic components
- 38. @p3pijn Analysis techniques for the organization-aware architect Software Repository Mining Team analysis Value Stream Mapping Process Mining
- 39. @p3pijn Mining version control and issue tracker systems Underestimated goldmines of behavioral data Which components are taking up most of our time and resources? Which components can be classified bottlenecks? Who works on which parts of the codebase? Are there any knowledge monopolies? Are we depending too much on certain key players? How full-stack are we actually?
- 40. @p3pijn https://github.com/ishepard/pydriller Software Repository Mining PyDriller: Python Framework for Mining Git Repositories @lucbrandts Who did what, when and in which file? @lucbrandts@p3pijn
- 41. @p3pijn Find bottlenecks and outliers by mapping your value stream Example from https://www.netobjectives.com/blogs/why-kanban-board-value-stream-map-scrum-board-isnt-and-what-tells-us Value adding activity Waiting time REWORK EXCESSIVE WAITING TIME
- 42. @p3pijn Process Mining Compare the perceived process with the actual process Issue ID Date / Time Status DEFECT-017 1/2/2019 11:01 Created STORY-2451 1/2/2019 12:01 Code Review DEFECT-017 1/5/2019 14:31 Planned STORY-2451 1/2/2019 13:07 To do DEFECT-017 1/7/2019 14:31 In Progress STORY-2451 1/7/2019 14:45 In Progress DEFECT-017 1/7/2019 17:29 Done STORY-2451 1/7/2019 14:45 Done DEFECT-017 1/8/2019 9:31 Code Review STORY-2451 1/8/2019 9:44 Code Review DEFECT-017 1/8/2019 10:05 Merged DEFECT-017 1/8/2019 10:07 Deployed https://fluxicon.com/disco/
- 43. @p3pijn A model for assessing organizational effectiveness Alignment Knowledge Trust Autonomy Feedback Loops Net promoter score Value Stream Mapping Conway’s Law Knowledge Mining Culture Sub-characteristics SIG metrics Organizational Effectiveness 30401 Knowledge Management Systems
- 44. @p3pijn Summary Tightly coupled architecture Plan vs Reality Full-stack? Analysis techniques Map teams & components Broken feedback loops Technology / Functional focused architectures
- 45. @p3pijn What should you do tomorrow? Improve the feedback loop between your architecture team and development teams by combining personal and tool-based feedback Draw a mapping of development teams to architecture components to find opportunities for improving alignment and autonomy Assess knowledge availability within your development teams Become a data-driven socio-technical architect: Leverage analysis techniques on behavioral data sources to drive decisions around architecture in your organization
- 47. @p3pijn Pepijn van de Kamp p.vandekamp@sig.eu softwareimprovementgroup.com @p3pijn