{"id":21236,"date":"2018-10-15T10:25:09","date_gmt":"2018-10-15T15:25:09","guid":{"rendered":"https:\/\/blog.planview.com\/modular-architectures-make-you-agile-in-the-long-run\/"},"modified":"2018-10-15T10:25:09","modified_gmt":"2018-10-15T15:25:09","slug":"modular-architectures-make-you-agile-in-the-long-run","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/modular-architectures-make-you-agile-in-the-long-run\/","title":{"rendered":"Project to Product: Modular Architectures Make You Agile in the Long Run"},"content":{"rendered":"
\n
\"Project<\/div>\n<\/figure>\n

Gene Kim, one of the authors of The DevOps Handbook<\/a>, once told me that organizations that require a developer to take 10 people out to lunch to get an API change done appear to have lower IT performance. We hypothesized that an overly high “lunch factor” would impede DevOps transformations, and added some questions on this to the 2017 State of DevOps Report to learn more about the role of architecture in DevOps. <\/span><\/i><\/p>\n

The conclusion in the report reads, “Loosely coupled architectures and teams are the strongest predictor of continuous delivery.” My colleagues Alan MacCormack, Carliss Baldwin, and Dan Sturtevant at the Harvard Business School have devised a way to measure and visualize architecture quality and its “cost of ownership” consequences that goes far beyond the “lunch factor.“<\/span><\/i><\/p>\n

My upcoming book, <\/span><\/i>Project to Product<\/span><\/i><\/a>, builds on these findings, examining the intersection between software architecture, organizational structure and business strategy.  A key foundation for the Flow Framework™<\/a> featured in the book is the state of the art in software architecture and how it relates to business value delivery. <\/span><\/i><\/p>\n

In the first guest post in this series, Dan Sturtevant – founder and CEO of Silverthread<\/a>, a company that <\/em>helps software leaders to improve cost of ownership, reduce cyber-risk, and gain control of complex software portfolios – summarizes some of the latest research and learnings on how architecture and modularity interact with value streams. —<\/span><\/i> Mik Kersten, co-founder and CEO, Tasktop<\/strong><\/span><\/i><\/p>\n

The <\/span>2017 State of DevOps Report <\/span><\/a>noted that loosely coupled architectures spur team performance by making it “easy to modify or replace any individual component or service without making corresponding changes to [those] that depend on it.”1 <\/sup><\/span>Put another way, systems with degraded modularity are incredibly difficult to change because pulling one thread always seems to lead to another headache. Engineers give up after months of fruitless investigation and failed changes. When architectural complexity proliferates, systems are no longer understandable. Teams can’t communicate about them, learning curves grow, morale plummets, and staff turnover increases.<\/span><\/p>\n

Over the past 15 years, our research team, led by Carliss Baldwin and Alan MacCormack at the Harvard Business School, have devised methods for measuring modularity and its erosion. We scanned thousands of code bases and found architectural flaws in many. We investigated how architecture degradation impacts business outcomes. This included studies of defects and safety,2 <\/sup><\/span>developer productivity and development staff turnover,<\/span>3 <\/sup>vulnerability,4<\/sup><\/span> the ability to drive new revenue,<\/span>5<\/sup> and de facto vendor lock-in.<\/span>6 <\/sup><\/span>Our team also recently founded Silverthread Inc. Over the past three years, Silverthread has helped more than 75 commercial and US federal government customers gain visibility, quantify the cost of ownership and risk, and regain control of their development projects.<\/span><\/p>\n

These experiences have convinced us that that long-term agility is possible only if you’re employing an agile product architecture. Not everyone shares this view. In the past decade, agile practitioners have focused intensely on improving software development processes and not so much on technical health. We’ve worked with several large organizations in which the application of lean principles produced underwhelming results. This is because velocity measurement, planning poker, attacking defect backlogs, Kanban cards, pair programming, or sprint-based planning does little to attack the root cause of problems that are inherently structural. If humans can’t easily understand or modify their code, teams might be using the best agile practices, but their ability to respond to market demands will be far from agile. Technical debt will weigh down the value stream’s performance.<\/span><\/p>\n

Here, I introduce sophisticated ways to visualize and quantify software modularity and its erosion. These techniques can help you identify architectural-complexity hotspots. I highlight research that has measured economic impact and helped organizations improve architectural outcomes. And I discuss how to use quantitative software design analysis to help teams decide if and when to refactor or rewrite software, using objective financial models of the likely return on investment (ROI).<\/span><\/p>\n

\n
\n

Table of Contents<\/p>\nToggle<\/span><\/path><\/svg><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n