Recommended
Recommended
More Related Content
Similar to The Architect's Blind Spot - SACON New York 2019
Similar to The Architect's Blind Spot - SACON New York 2019 (20)
Recently uploaded
Recently uploaded (20)
The Architect's Blind Spot - SACON New York 2019
- 1. @lucbrandts@p3pijn The Architect's Blind Spot: How to align architecture and organizational structure to better your products, processes and people Pepijn van de Kamp Luc Brandts @lucbrandts@p3pijn
- 2. @lucbrandts@p3pijn “Software development is a technical activity conducted by human beings.” Niklaus Wirth
- 3. @lucbrandts@p3pijn Social dynamics are everywhere Especially in our architectural designs…
- 4. @lucbrandts@p3pijn Social dynamics are everywhere Especially in our architectural designs… Dependencies ARCHITECTURE Conway’s Law Feedback Loops Team size Channels Overcomplexification Politics Trust Value congruence Communication Intrinsic motivation Knowledge distribution Team distribution
- 5. @lucbrandts@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?
- 6. @lucbrandts@p3pijn Skillset for the organization-aware architect Oversee personal & tool-based feedback loops Align organization & architecture Influence knowledge creation & retention Analysis techniques
- 8. @lucbrandts@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
- 9. @lucbrandts@p3pijn Where did it go wrong? Designed architecture Implemented architecture
- 10. @lucbrandts@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
- 12. @lucbrandts@p3pijn Broken feedback loops Without governing the software architecture of a system, its implementation will evolve following the path of least resistance
- 13. @lucbrandts@p3pijn The result of lack of architectural governance… Unintended dependencies Loss of initial structure Cyclic dependencies Tightly coupled architecture
- 14. @lucbrandts@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
- 15. @lucbrandts@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
- 16. @lucbrandts@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
- 17. @lucbrandts@p3pijn Part II: Aligning organization & architecture
- 18. @lucbrandts@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
- 19. @lucbrandts@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
- 20. @lucbrandts@p3pijn Technology-focused architecture & organization Team characteristics • No end-to-end overview of solution • Dependent on downstream teams • Coordination overhead between teams • Distance to customer increases with every technology layer Data Store Data Access Business Logic UI
- 21. @lucbrandts@p3pijn Functional-focused architecture & organization Team characteristics • End-to-end responsible for a functional area • Reduced coordination overhead due to autonomy (for the risk of duplication of work) • No increased distance to customer Functional Area Functional Area Functional Area Functional Area
- 22. @lucbrandts@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?
- 23. @lucbrandts@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
- 24. @lucbrandts@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
- 25. @lucbrandts@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
- 26. @lucbrandts@p3pijn Part III: Knowledge Creation & Retention
- 27. @lucbrandts@p3pijn A model to reason about knowledge < Generalist > <Specialist> Breadth of knowledge Depthofexpertise T-shaped profiles McKinsey & Co. 1980
- 28. @lucbrandts@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
- 29. @lucbrandts@p3pijn A jack of all trades …is a master of none?Mastery takes practice To full-stack of not to full-stack?
- 30. @lucbrandts@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
- 31. @lucbrandts@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
- 32. @lucbrandts@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
- 33. @lucbrandts@p3pijn Analysis techniques for the organization-aware architect Software Repository Mining Team analysis Value Stream Mapping Process Mining
- 34. @lucbrandts@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?
- 35. @lucbrandts@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
- 36. @lucbrandts@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. @lucbrandts@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
- 38. @lucbrandts@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/
- 39. @lucbrandts@p3pijn A model for assessing organizational effectiveness Value Congruence Knowledge Trust Dependencies Feedback Loops Analysis Satisfaction Survey Value Stream Mapping Conway’s Law Knowledge Mining Cameron & Quinn Sub-characteristics SIG metrics Organizational Effectiveness 30401 Knowledge Management Systems
- 40. @lucbrandts@p3pijn Summary Tightly coupled architecture Plan vs Reality Full-stack? Analysis techniques Map teams & components Broken feedback loops Technology / Functional focused architectures
- 41. @lucbrandts@p3pijn What should you do tomorrow? Improve the feedback loop between your architecture team and development teams by using 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
- 43. @lucbrandts@p3pijn Pepijn van de Kamp p.vandekamp@sig.eu Luc Brandts l.brandts@sig.eu softwareimprovementgroup.com @p3pijn @lucbrandts
Editor's Notes
- Almost every technical issue is a consequence of organizational issues. We tend to mistake organizational problems for technical issues. As a consequence, we are busy treating the symptoms of technical issues, when we should probably focus more on the real cause of our problems - organizational effectiveness. So when we translate this into the logic we just saw, I believe this is closer to reality.
- Especially in our architectures... If we know what these factors are doing to our technical endeavours, we will be able to improve how we collaborate, communicate effectively and build the best products possible.
- Especially in our architectures... If we know what these factors are doing to our technical endeavours, we will be able to improve how we collaborate, communicate effectively and build the best products possible.
- The architecture blindspot: hij ziet niet de afhankelijkheid van zijn technische architectuur met de organisatiestructuur en inrichting.
- Analyzed a 100 software systems on a yearly basis Analyze the architecture: components and interconnections, interview developers and architects We compare the designed architecture to the implementation More often than not, we encounter the following situation
- Response we get often is surprise: architects: is this really how we have implemented it? Gap between design and implementation Deviating from design is not necessarily a bad thing as long as it is a conscious decision (and the design is updated) How does this happen?
- So, where did it go wrong? If there’s one thing that we learned ... Human interaction and behaviour. 3 versions of the design. And those 3 need to be aligned. That’s where communication comes in. feedback loops. Start with the essence
- This is been discussed already at the keynotes and in a couple of sessions: The architect in the Ivory Tower. Dictating architecture requirements and developers trying to grasp what is really needed and how to get the job done. Not accessible for interactions with developers. Sometimes the architect is even located on a different floor, or even worse, in a different office in another location. Translated into a feedback loop, that would look something like this:
- We see it all the time: architects designing a landscape or system in isolation - distorted feedback loop. Architect might not receive any feedback at all gap between the designed and implemented architecture Solution: be more closely involved in the implementation of an architecture Make sure the desired quality properties of a system are indeed met
- PEPIJN
- - No governance - No clear boundaries and architectural constraints - After a couple of years the implemented architecture might look like this - Initial developers left to other projects - This is what happens to software systems while doing maintenance if there is no governance - How did this happen: one line of code at a time
- - Personal feedback is given on an interpersonal level—people discussing code, products, or processes and identifying where things can be improved. - Tool-based feedback, such as static analysis, provides you with code-level feedback and tells you where to improve your code (or specific parts of your code) to increase quality. Personal feedback is often specific for projects, more sensitive to context, and offers concrete suggestions to implement. Tool-based feedback enables faster feedback loops, allows for scalability by iteration, and is more objective. But which form of feedback is better? - Not mutually exclusive: combine them!
- Also mentioned a couple of times already in other talks: ArchUnit Fast feedback on architecture deviations Emphasize: this is direct feedback
- Conways law It is simply the natural order of things: a design that leads to least friction Suggests that if organization and design are not aligned this is against the natural order of things It is like swimming against the current or walking uphill, you are still moving forward, but less efficient Example: everything in 1 file when you are working alone
- - Team composition can also have significant impact on how an architecture evolves Benchmark of systems with 3 tier architecture “To allow for effective division of work, source code needs to be divided into components of relatively equal size” Sometimes we come across the situation on the right what happened here? (“logic and data access code had leaked to the front-end”)
- 2 extremes of architecture and organization The classical layered architecture where every component is being built by a team specialized in the technology used in the layer Technology focused architecture and organization Separation of concerns, but change typically touches every layer
- Other extreme is an architecture of vertically sliced architecture, often related to a functional area Multi disciplinary team specialized in the functional area Change typically only touches 1 vertical slice, other components and teams not involved There is less need to align, can work more independently of the other teams. Antipattern: reinvent the wheel
- We just saw 2 toy samples of a layered tehnology focused architecture and vertical functional focused architecture and organization Architectures in the real world are typically a bit more complicated and can have characteristics of both styles To find opportunities for optimizing the fit of an architecture to a team structure: create a map - Refactoring an architecture can be painful, but typically less painful than changing organizational structure
- Everyone in these teams has a lot of knowledge. The trick is to unravel these hidden treasures called knowledge networks. Lots of this knowledge is explicit, but maybe even more tacit knowledge. We often intuitively feel or know who has a lot of knowledge around a certain topic, but some things might stay hidden treasures. It’s almost impossible to have a clear map on knowledge distribution. Documentation is often not the highest priority - especially since we all started working Agile, leading to a lot of knowledge not being made explicit. Lots of architects own a lot of tacit knowledge. Which is hard to codify anyway. But what happens when they leave and documentation was not one of their highest priorities? It’s very valuable to know what knowledge exists in a team or organization and how that knowledge is distributed.
- Architecture can drive knowledge creation T-shaped profile can help to reason about this. Generalist knowledge: breadth Specialist knowledge: depth
- So let’s look again at the 2 extremes: Technology focused architecture: solution domain Dev’s learn about technology, programming language, frameworks, patterns Since they implement features for all kinds of functional areas they become generalists on this aspect Functional focused: knowledge creation in problem domain: the functional area Less emphasis on technology, can pick a technology that fits the functional area best Generalists in the tech stack: a term that we frequently see is full stack
- Becoming a master of a certain technology takes time, a lot of time. Studies say that properly playing a violin can take up to 10 years. It is the same with technologies and frameworks, mastery takes time. Although the full stack is a nice thought, can we really be masters of a full stack?
- Full stack is a term from the era when we used to classify developers by technology Certifications emphasized this: Certified Java Professional or Microsoft Certified Technology Specialist Functional focused architectures promote developers to become more technology independent and become a domain expert. Opportunity to market yourself as a software engineer with expertise in a certain domain
- What about knowledge retention? Trend is to document only the bare minimum and let code itself serve as documentation dependent on the knowledge of certain key developers? Actively steering on knowledge transfer can limit the risk
- Architects need to become familiar with analysis techniques that can provide them with the necessary organizational insights
- It’s called version control. The best thing is, when you retract this information from the source code and version control systems, you can map it to your architectures and systems. You can identify dependencies and see where you should maybe make some team changes or architectural changes. Version control systems include a time dimension, and a huge amount of behavioral or social data. It tells you exactly who worked on which systems, when changes were made and which systems require the most work for example. You can also extract who has a lot of knowledge about a system and come up with a plan B for when that person might leave your company. Are you depending on one key-person too much? You see, this is all very valuable data.
- Who can be abstracted to which team and file can be abstracted to which architecture component or which technology
- Goal: have as little waiting time and rework as possible Architect: what is the cause for waiting time? Team structure? Coordination effort? Which components have most rework? Parallel work? Bad code quality?