Accelerate Chapter 5 Discussion Points

Chapter 5 of Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, covers architecture and its impact on continuous delivery practices:

• The architecture of your software and the services it depends on can be a significant barrier to increasing both the tempo and stability of the release process and the systems delivered
• Can DevOps and continuous delivery be applied to systems other than web based, such as mainframe, firmware, etc.?
• High performance is possible with all kinds of systems, provided that systems and teams are loosely coupled
• Types of systems and delivery performance
• Software being built corresponded with low performers in only two situations:
• Software being built, or services to interact with, was custom software developed by another company (e.g., an outsourcing partner)
• Underlines the importance of bringing this capability in house
• Mainframe systems
• Outside of these two cases, there was no significant correlation between software being built and delivery performance
• Focus on deployability and testability
• There are two architectural characteristics that are important to achieving high performance:
• We can do most of our testing without requiring an integrated environment
• We can and do deploy or release our application independently of other applications/services it depends on
• To achieve these characteristics, design systems are loosely coupled -- that is, can be changed and validated independently of each other.
• According to the 2017 analysis, the biggest contributor to continuous delivery was when teams can:
• Make large-scale changes to the design of their system without the permission of somebody outside the team
• Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams
• Complete their work without communicating and coordinating with people outside their team
• Deploy and release their product or service on demand, regardless of other services it depends upon
• Do most of their testing on demand, without requiring an integrated test environment
• Perform deployments during normal business hours with negligible downtime
• Organizations should evolve their team and organizational structure to achieve the desired architecture
• The goal is for your architecture to support the ability of teams to get their work done without requiring high-bandwidth communication between teams
• This doesn't mean that teams shouldn't work together, but it's rather: 
• To ensure that the available communication bandwidth isn't overwhelmed by fine-grained decision-making at the implementation level
• So we can instead use that bandwidth for discussing higher-level shared goals and how to achieve them
• A loosely coupled architecture enables scaling
• If we achieve a loosely coupled, well-encapsulated architecture with a matching organizational structure:
• We can achieve better delivery performance, increasing tempo and stability while reducing burnout and pain of deployment
• We can substantially grow the size of our engineering organization and substantially increase productivity as we do so
• This is based off the measurement of number of deploys per day per developer
• As the number of developers increases:
• Low performers deploy with decreasing frequency
• Medium performers deploy at a constant frequency
• High performers deploy at a significantly increasing frequency
• Allow teams to choose their own tools
• There is a downside to lack of flexibility: it prevents teams from 
• Choosing technologies that will be most suitable for their particular needs
• Experimenting with new approaches and paradigms to solve their problems
• When teams can decide which tools they use, it contributes to software delivery performance and, in turn, to organizational performance
• There is a place for standardization, particularly around the architecture and configuration of infrastructure
• Teams that build security into their work do better at continuous delivery
• A key element of this is ensuring that information security teams make preapproved, easy-to-consume libraries, packages, toolchains, and processes available
• When tools provided actually make life easier for the engineers who use them, they will adopt them of their own free will
• This is a much better approach than forcing them to use tools that have been chosen for the convenience of other stakeholders
• A focus on usability and customer satisfaction is just as important when building tools for internal customers as it is for external customers
• Allowing your engineers to choose whether or not to use them ensures that we keep ourselves honest in this respect
• Architects should focus on engineers and outcomes, not tools or technologies
• What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don't achieve the outcomes and enable the behaviors that we care about
• What is important is enabling teams to make changes to their products or services without depending on other teams or systems