Software Architecture and Decision-Making Leveraging Leadership, Technology, and Product Management to Build Great Products (Srinath Perera) (Z-Library)

📄 File Format: PDF

💾 File Size: 3.2 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

(This page has no text content)

📄 Page 3

About This eBook ePUB is an open, industry-standard format for eBooks. However, support of ePUB and its many features varies across reading devices and applications. Use your device or app settings to customize the presentation to your liking. Settings that you can customize often include font, font size, single or double column, landscape or portrait mode, and figures that you can click or tap to enlarge. For additional information about the settings and features on your reading device or app, visit the device manufacturer’s Web site. Many titles include programming code or configuration examples. To optimize the presentation of these elements, view the eBook in single-column, landscape mode and adjust the font size to the smallest setting. In addition to presenting code and configurations in the reflowable text format, we have included images of the code that mimic the presentation found in the print book; therefore, where the reflowable format may compromise the presentation of the code listing, you will see a “Click here to view code image” link. Click the link to view the print-fidelity code image. To return to the previous page viewed, click the Back button on your device or app.

📄 Page 4

Software Architecture and Decision-Making

📄 Page 5

Software Architecture and Decision-Making Leveraging Leadership, Technology, and Product Management to Build Great Products Srinath Perera

📄 Page 6

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at corpsales@pearsoned.com or (800) 382-3419. For government sales inquiries, please contact governmentsales@pearsoned.com. For questions about sales outside the U.S., please contact intlcs@pearson.com. Visit us on the Web: informit.com/aw Library of Congress Control Number: 2023946912 Copyright © 2024 Pearson Education, Inc. Hoboken, NJ Cover image: wowomnom/Shutterstock; AVA AVA/Shutterstock All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, request forms and the appropriate contacts within the Pearson Education Global Rights & Permissions Department, please visit

📄 Page 7

www.pearson.com/permissions. ISBN-13: 978-0-13-824973-1 ISBN-10: 0-13-824973-3 $PrintCode

📄 Page 8

Pearson’s Commitment to Diversity, Equity, and Inclusion Pearson is dedicated to creating bias-free content that reflects the diversity of all learners. We embrace the many dimensions of diversity, including but not limited to race, ethnicity, gender, socioeconomic status, ability, age, sexual orientation, and religious or political beliefs. Education is a powerful force for equity and change in our world. It has the potential to deliver opportunities that improve lives and enable economic mobility. As we work with authors to create content for every product and service, we acknowledge our responsibility to demonstrate inclusivity and incorporate diverse scholarship so that everyone can achieve their potential through learning. As the world’s leading learning company, we have a duty to help drive change and live up to our purpose to help more people create a better life for themselves and to create a better world. Our ambition is to purposefully contribute to a world where: Everyone has an equitable and lifelong opportunity to succeed through learning. Our educational products and services are inclusive and represent the rich diversity of learners. Our educational content accurately reflects the histories and experiences of the learners we serve. Our educational content prompts deeper discussions with learners and motivates them to expand their own learning (and worldview). While we work hard to present unbiased content, we want to hear from you about any concerns or needs with this Pearson product so that we can investigate and address them. Please contact us with concerns about any potential bias at https://www.pearson.com/report- bias.html.

📄 Page 9

This book is dedicated to my family: Miyuru, Basilu, and Nithika. Your presence brings color and purpose to my life. And to my parents, whose unwavering love and trust continue to astonish and uplift me. I also extend my heartfelt gratitude to Frank for your steadfast support throughout this journey to its realization. Your insights were invaluable in shaping the core idea of this book.

📄 Page 10

Contents 1 Introduction to Software Leadership Role of Judgment Goal of This Book Part I: Introduction Part II: Essential Background Part III: System Design Part IV: Putting Everything Together 2 Understanding Systems, Design, and Architecture What Is Software Architecture? How to Design a System Five Questions Question 1: When Is the Best Time to Market? Question 2: What Is the Skill Level of the Team? Question 3: What Is Our System’s Performance Sensitivity? Question 4: When Can We Rewrite the System? Question 5: What Are the Hard Problems? Seven Principles: The Overarching Concepts Principle 1: Drive Everything from the User’s Journey Principle 2: Use an Iterative Thin Slice Strategy Principle 3: On Each Iteration, Add the Most Value for the Least Effort to Support More Users Principle 4: Make Decisions and Absorb the Risks Principle 5: Design Deeply Things That Are Hard to Change but Implement Them Slowly Principle 6: Eliminate the Unknowns and Learn from the Evidence by Working on Hard Problems Early and in Parallel Principle 7: Understand the Trade-offs Between Cohesion and Flexibility in the Software Architecture Designing for an Online Bookstore

📄 Page 11

Designing for the Cloud Summary 3 Mental Models for Understanding and Explaining System Performance A Computer System Models for Performance Model 1: Cost of Switching to the Kernel Mode from the User Mode Model 2: Operations Hierarchy Model 3: Context Switching Overhead Model 4: Amdahl’s Law Model 5: Universal Scalability Law (USL) Model 6: Latency and Utilization Trade-offs Model 7: Designing for Throughput with the Maximal Useful Utilization (MUU) Model Model 8: Adding Latency Limits Optimization Techniques CPU Optimization Techniques I/O Optimization Techniques Memory Optimization Techniques Latency Optimization Techniques Intuitive Feel for Performance Leadership Considerations Summary 4 Understanding User Experience (UX) General UX Concepts for Architects Principle 1: Understand the Users Principle 2: Do as Little as Possible Principle 3: Good Products Do Not Need a Manual: Its Use Is Self-Evident Principle 4: Think in Terms of Information Exchange Principle 5: Make Simple Things Simple Principle 6: Design UX Before Implementation

📄 Page 12

UX Design for Configurations UX Design for APIs UX Design for Extensions Leadership Considerations Summary 5 Macro Architecture: Introduction History of Macro Architecture Modern Architectures Macro Architectural Building Blocks Leadership Considerations Summary 6 Macro Architecture: Coordination Approach 1: Drive Flow from Client Approach 2: Use Another Service Approach 3: Use Centralized Middleware Approach 4: Implement Choreography Leadership Considerations Summary 7 Macro Architecture: Preserving Consistency of State Why Transactions? Why Do We Need to Go Beyond Transactions? Going Beyond Transactions Approach 1: Redefining the Problem to Require Lesser Guarantees Approach 2: Using Compensations Best Practices Leadership Considerations Summary 8 Macro Architecture: Handling Security User Management Interaction Security

📄 Page 13

Authentication Techniques Authorization Techniques Common Interaction Security Scenarios for an App Storage, GDPR, and Other Regulations Security Strategy and Advice Performance and Latency Zero-Trust Approach Take Caution When Running User-Provided Code Blockchain Topics Other Topics Leadership Considerations Summary 9 Macro Architecture: Handling High Availability and Scale Adding High Availability Replication Fast Recovery Understanding Scalability Scaling for a Modern Architecture: Base Solution Scaling: The Tools of Trade Scale Tactic 1: Share Nothing Scale Tactic 2: Distribution Scale Tactic 3: Caching Scale Tactic 4: Async Processing Building Scalable Systems Approach 1: Successive Bottleneck Elimination Approach 2: Shared-Nothing Design Leadership Considerations Summary 10 Macro Architecture: Microservices Considerations Decision 1: Handling Shared Database(s)

📄 Page 14

Solution 1: One Microservice Updating the Database Solution 2: Two Microservices Updating the Database Decision 2: Securing Microservices Decision 3: Coordinating Microservices Decision 4: Avoiding Dependency Hell Backward Compatibility Forward Compatibility Dependency Graphs Loosely Coupled, Repository-Based Teams as an Alternative to Microservices Leadership Considerations Summary 11 Server Architectures Writing a Service Understanding Best Practices for Writing a Service Understanding Advanced Techniques Using Alternative I/O and Thread Models Understanding Coordination Overhead Efficiently Saving Local State Choosing a Transport System Handling Latency Separating Reads and Writes Using Locks (and Signaling) in Applications Using Queues and Pools Handling Service Calls Using These Techniques in Practice CPU-Bound Applications (CPU >> Memory and No I/O) Memory-Bound Applications (CPU + Bound Memory and No I/O) Balanced Applications (CPU + Memory + I/O) I/O-Bound Applications (I/O + Memory > CPU) Other Application Categorizations

📄 Page 15

Leadership Considerations Summary 12 Building Stable Systems Why Do Systems Fail, and What Can We Do About Them? How to Handle Known Errors Handling Unexpected Load Handling Resource Failures Handling Dependencies Handling Human Changes Common Bugs Resource Leaks Deadlocks and Slow Operations How to Handle Unknown Errors Observability Bugs and Testing Graceful Degradation Leadership Considerations Summary 13 Building and Evolving the Systems Getting Your Hands Dirty Get the Basics Right Understand the Design Process Make Decisions and Absorb Risks Demand Excellence Communicating the Design Evolving the System: How to Learn from Your Users and Improve the System Leadership Considerations Summary Index

📄 Page 16

About the Author I started my architecting journey as an Apache open-source developer and have continued that for 20 years. I learned a lot by watching and later participating in architecture discussions in developer lists for those open-source projects, which is a great place for an aspiring architect to start. I have played a major role in the architecture of Apache Axis2, Apache Airavata, WSO2 CEP (Siddhi), and WSO2 Choreo. I have designed two SOAP engines and worked closely with four. I was (and continue to be) a committer (a developer who can commit to a code base) for Apache Axis, Axis2, Apache Geronimo, and Apache Airavata. I joined WSO2 in 2009. WSO2 products are used by many Fortune 500 companies such as airlines, banks, governments, and so on. At WSO2, I played an architecture review role for 10+ projects and 100+ releases. I reviewed hundreds of customer-solution architectures and deployments and sat in on thousands of architecture reviews. At WSO2, when we faced a problem that could not be resolved by the immediate team, we set up a war room, where a hand-picked team restlessly attacked the problem. I have been in many war rooms and have led several, which have made me painfully aware of mistakes made in the software architecture. I’ve had a front row seat to world-class technical leadership and have also built many systems and learned from mistakes. Later switching to analytics and AI-related topics, I co-designed WSO2 Siddhi and envisioned and shaped the AI features in WSO2 Choreo. Throughout this time, I published 40+ peer- reviewed research articles, which have been referenced by thousands of other research publications. I hope you enjoy this book. Given the central role software plays in the world today, I will be content if this book helps make you a better software architect, knowing that I have contributed to better software that will be the lifeblood of the world for many years.

📄 Page 17

Register your copy of Software Architecture and Decision-Making on the InformIT site for convenient access to updates and/or corrections as they become available. To start the registration process, go to informit.com/register and log in or create an account. Enter the product ISBN (9780138249595) and click Submit. Look on the Registered Products tab for an Access Bonus Content link next to this product, and follow that link to access any available bonus materials. If you would like to be notified of exclusive offers on new editions and updates, please check the box to receive email from us.

📄 Page 18

1 Introduction to Software Leadership When we are developing software systems, our goal is to build systems that meet quality standards and that provide the highest return on investment (ROI) in the long run or in a predefined time horizon. This, in turn, becomes the goal of software architecture, which is the blueprint for building software systems. Here, ROI is not just about being economical. If spending more on the product results in more revenue, consider that a good ROI. On the other hand, shoddy design leads to numerous changes later, ultimately costing a lot more. Good software architecture balances both extremes and maximizes ROI. Architectural design includes many things—for example, finding the right abstractions, deciding which features to include, determining the depth of each feature, setting quality of service (QOS) parameters, establishing the degree of flexibility, timing, and user experience. Role of Judgment As software architects, we learn about abstractions, architecture styles, and patterns. We study their pros and cons, which one to use in a given situation, and how to compose them with an awareness of pitfalls, negative examples, and use cases. However, many errors are made not because we do not understand these things. Most design mistakes are caused by a lack of judgment, not by a lack of knowledge. Here, judgment refers to the ability to make considered decisions or arrive at sensible conclusions optimizing for the most important outcome. I have seen this outcome again and again in my 20 years of architecting systems. Here are the common mistakes I’ve found: Trying to incorporate too many features required by the user’s journey

📄 Page 19

Making the design too flexible or too consistent, which impacts future changes Limiting depth, which significantly affects user experience (UX) Solving useless problems for the end user Inadequately focusing on the user’s journey and experience Missing delivery timetables We make most of these mistakes because we do not know about the future, about the users who will use the system, and about how the system works at the edge of its capabilities. Here, I see the need for judgment. I see leadership challenges, not technical challenges! Let’s explore what I mean by that. To me, leadership is about managing uncertainty, bringing order to chaos, providing hope for a better future, and progressing toward that future. Consider the following: A leader is a dealer in hope. —Napoleon Bonaparte This is not to say leaders must be omniscient and always know what the future will bring, but they should have a vision of the future; they should manage uncertainty in such a way that minimizes risk. Leaders should communicate their vision and its implementation to others and shepherd them toward that vision. Let me repeat the same statement from an architect’s point of view. It is not to say software architects must be omniscient and always know how a system will be used and what it should have, but they should have a vision of the overall solution. They should manage uncertainty in such a way that minimizes risk. Leaders should communicate their vision and implementation to the team and guide them toward building the system and then operating it. I am not saying that knowledge is not important for an architect. It is. However, judgment plays a key role too. Sadly, knowledge is commonplace, whereas judgment is not. I have seen a lot of good books and articles about software architectural concepts: Bob Martin’s books, Gregor Hohpe’s books, and Martin Fowler’s blogs, to name a few. Yet, they focus mainly

📄 Page 20

on knowledge and less on judgment. I have also seen a lot of good books on leadership: The Hard Things About Hard Things by Ben Horowitz, Trillion Dollar Coach by Eric Schmidt et al., Team of Teams: New Rules of Engagement for a Complex World by Stanley McChrystal, Good Strategy, Bad Strategy by Richard Rumelt, and other books by Jocko Willink, to name a few. They discuss judgment but only at a general level, not at a technical level. There is a gap between good leadership and good software architectural judgment. Goal of This Book This book discusses the gap between the two—leadership and software architectural judgment. It describes software leadership and how we can use it to the best advantage when building our systems. As mentioned, my experience shows that many of our architectural mistakes come from the gap between knowledge and judgment. This is not a book about how to manage your team, nor is it a book about engineering management or about HR and how to build the team. It’s also not a book about strategy. Further, this book does not cover how to create a vision. You must have a vision—your own or one shared by your cofounders or executive board members. Although there is a lot written about vision, I am not sure it can be explained sufficiently. This is a technical book, so it is a book about technical judgment. It explains principles and concepts I believe a senior architect must understand deeply and discusses how to employ those principles to manage uncertainty. This is a book about how technical leaders/architects should think and how to oversee their product by managing uncertainty. For example, one thesis of this book is to think deeply but implement slowly. Another example is that leaders must define the scope, taking up the yoke of uncertainty without passing it down to coworkers. Questions and principles discussed in this book help us manage uncertainty and provide a framework for making decisions.