Software Architect's Handbook

Table of contents

1. Title Page
2. Copyright and Credits
   1. Software Architect's Handbook
3. Dedication
4. Packt Upsell
   1. Why subscribe?
   2. PacktPub.com
5. Contributors
   1. About the author
   2. About the reviewers
   3. Packt is searching for authors like you
6. Preface
   1. Who this book is for
   2. What this book covers
   3. To get the most out of this book
      1. Download the color images
      2. Conventions used
   4. Get in touch
      1. Reviews
7. The Meaning of Software Architecture
   1. What is software architecture?
      1. ISO/IEC/IEEE 42010 standard definition
      2. What makes up a software architecture?
      3. Software architecture is an abstraction
      4. Software architecture is about the important stuff
   2. Why is software architecture important?
      1. Defining a solution to meet requirements
      2. Enabling and inhibiting quality attributes
      3. Giving you the ability to predict software system qualities
      4. Easing communication among stakeholders
      5. Managing change
      6. Providing a reusable model
      7. Imposing implementation constraints
      8. Improving cost and effort estimates
      9. Serves as training for team members
      10. Software architecture is not a silver bullet
   3. Who are the consumers of software architectures?
   4. What is the software architect role?
      1. Software architects are technical leaders
      2. Software architects perform a number of duties
      3. Ivory tower software architects
      4. What are software architects expected to know?
      5. Don't be overwhelmed
      6. Is the software architect role right for you?
   5. Summary
8. Software Architecture in an Organization
   1. Types of software architects
      1. Enterprise architect
      2. Solution architect
      3. Application architect
      4. Data architect/information architect
      5. Infrastructure architect
      6. Information security architect
      7. Cloud architect
   2. Software development methodologies
      1. The Waterfall model
         1. Phases of the Waterfall methodology
         2. Issues with the Waterfall methodology
      2. Agile software development methodologies
         1. Agile values and principles
         2. An iterative methodology
         3. Adaptive rather than predictive
         4. Daily stand-up meetings
   3. Project management
      1. The importance of software project estimation
      2. Putting effort into the estimates
      3. Being a realist (or even a pessimist)
      4. Team and situational factors to consider
      5. Project schedule changes
      6. Getting a project back on schedule
         1. Working overtime
         2. Reducing scope
         3. Adding resources
         4. Reallocating resources
         5. Identifying problem areas
         6. Acting as early as possible
   4. Office politics
      1. Understanding your organization's goals
      2. Addressing the concerns of others
      3. Assisting people with their goals
      4. Knowing when to compromise
      5. Being aware of cultural differences
   5. Software risk management
      1. Risk avoidance
      2. Transferring the risk to another party
      3. Risk mitigation
      4. Risk acceptance
   6. Configuration management
      1. Changing management
   7. Software product lines
      1. Benefits of a software product line
      2. Core assets of an organization
      3. Risks of product line engineering
   8. Summary
9. Understanding the Domain
   1. Developing business acumen
      1. Familiarity with general business topics
      2. Understanding your organization's business
   2. Domain-driven design
      1. Encourages and improves communication
      2. What is a ubiquitous language?
      3. Entities, value objects, and aggregates
         1. Entities
         2. Value objects
         3. Aggregates and root entities
      4. Separating the domain into subdomains
      5. What are bounded contexts?
   3. Requirements engineering
      1. Types of software requirements
         1. Business requirements
         2. Functional requirements
         3. Non-functional requirements
         4. Constraints
      2. The importance of requirements engineering
      3. Software requirements must be measurable and testable
      4. Software requirements that affect architecture
   4. Requirements elicitation
      1. Techniques to elicit requirements
         1. Interviews
         2. Requirements workshops
         3. Brainstorming
         4. Observation
         5. Focus groups
         6. Surveys
         7. Document analysis
         8. Prototyping
         9. Reverse engineering
      2. Get access to the proper stakeholders
   5. Summary
10. Software Quality Attributes
    1. Quality attributes
       1. External or internal
       2. Quality attributes and the SDLC
       3. Testing quality attributes
    2. Maintainability
       1. Types of software maintenance
          1. Corrective maintenance
          2. Perfective maintenance
          3. Adaptive maintenance
          4. Preventive maintenance
       2. Modifiability
       3. Extensibility and flexibility
       4. Scope of modifications
       5. Designing for maintainability
          1. Reducing size
          2. Increasing cohesion
          3. Reducing coupling
       6. Measuring maintainability
          1. Lines of code (LOC)
          2. Cyclomatic complexity
          3. Depth of inheritance tree (DIT)
    3. Usability
       1. Allowing users to complete their tasks efficiently
       2. Learnability
       3. Providing useful feedback
       4. Accessibility
       5. Usability needs to be considered during requirements
       6. Usability testing
       7. Appealing visual design
       8. Providing a good help system
       9. Software must be useful, and not just usable
    4. Availability
       1. Calculating availability based on time
       2. Calculating availability based on request success rate
       3. Faults, errors, and failures
       4. Detecting faults
          1. Ping/echo reply
          2. Heartbeat
          3. Timestamp
          4. Voting
          5. Sanity test/sanity checking
          6. Condition monitoring
          7. Self-tests
       5. Recovering from faults
          1. Exception handling
          2. Retry strategy
          3. Varying levels of redundancy
          4. Rollback
          5. Graceful degradation
          6. Ignoring faulty behavior
       6. Preventing faults
          1. Removal from service
          2. Transactions
          3. Increasing competence sets
          4. Exception prevention
    5. Portability
       1. Adaptability
       2. Installability
       3. Replaceability
       4. Internationalization and localization
       5. Maintaining portability
    6. Interoperability
       1. Challenges with interoperability
       2. Locating and exchanging information with another system
       3. Interoperability standards
       4. Interoperability testing
    7. Testability
       1. Controllability
       2. Observability
       3. Isolability
       4. Automatability
       5. Complexity of the software
       6. Importance of test documentation
       7. What makes a good tester?
    8. Summary
11. Designing Software Architectures
    1. Software architecture design
       1. Making design decisions
       2. Software architecture design terms
          1. Structure
          2. Element
          3. System
          4. Subsystem
          5. Module
          6. Component
    2. The importance of software architecture design
       1. Making key decisions
       2. Avoiding design decisions can incur technical debt
       3. Communicating the architecture to others
       4. Providing guidance to developers
       5. Influencing non-technical parts of the project
    3. Top-down versus bottom-up design approaches
       1. Top-down approach
          1. Advantages of the top-down approach
          2. Disadvantages of the top-down approach
       2. Bottom-up approach
          1. Advantages of the bottom-up approach
          2. Disadvantages of the bottom-up approach
       3. Which approach should I use?
    4. Greenfield versus brownfield software systems
       1. Greenfield systems
       2. Brownfield systems
    5. Architectural drivers
       1. Design objectives
       2. Primary functional requirements
       3. Quality attribute scenarios
          1. Prioritizing quality attribute scenarios
       4. Constraints
       5. Architectural concerns
    6. Leveraging design principles and existing solutions
       1. Selecting a design concept
       2. Software architecture patterns
       3. Reference architectures
          1. Benefits of reference architectures
          2. Refactoring a reference architecture for your needs
          3. Creating your own reference architecture
       4. Tactics
       5. Externally developed software
          1. Buy or build?
             1. Advantages/disadvantages of building
             2. Advantages/disadvantages of buying
          2. Researching external software
          3. Should I use open source software (OSS)?
             1. Advantages of using open source software
             2. Disadvantages of using open source software
    7. Documenting the software architecture design
       1. Sketching the architecture design
       2. Documenting the design rationale
          1. Design rationale for design evaluation
          2. Design rationale for design verification
          3. Design rationale for design knowledge transfer
          4. Design rationale for design communication
          5. Design rationale for design maintenance
          6. Design rationale for design documentation
          7. Design rationale for design reuse
    8. Using a systematic approach to software architecture design
       1. A general model of software architecture design
          1. Architectural analysis
          2. Architectural synthesis
          3. Architectural evaluation
       2. Architecture design is an iterative process
       3. Selecting an architecture design process
    9. Attribute-driven design (ADD)
       1. Step 1 – Reviewing inputs
       2. Step 2 – Establishing the iteration goal and selecting inputs to be considered in the iteration
       3. Step 3 – Choosing one or more elements of the system to refine
       4. Step 4 – Choosing one or more design concepts that satisfy the inputs considered in the iteration
       5. Step 5 – Instantiating architectural elements, allocating responsibilities, and defining interfaces
       6. Step 6 – Sketching views and recording design decisions
       7. Step 7 – Performing analysis of current design and reviewing the iteration goal and design objectives
       8. Step 8 – Iterating if necessary
    10. Microsoft's technique for architecture and design
        1. Step 1 – Identifying architecture objectives
        2. Step 2 – Identifying key scenarios
        3. Step 3 – Creating application overview
           1. Determining your application type
           2. Identifying your deployment constraints
           3. Identifying important architecture design styles
           4. Determining relevant technologies
        4. Step 4 – Identifying key issues
        5. Step 5 – Defining candidate solutions
    11. Architecture-centric design method (ACDM)
        1. Step 1 – Discovering architectural drivers
        2. Step 2 – Establishing project scope
        3. Step 3 – Creating notional architecture
        4. Step 4 – Architectural review
        5. Step 5 – Production go/no-go
        6. Step 6 – Experiment planning
        7. Step 7 – Experimenting with and refining the architecture
        8. Production planning and production
    12. Architecture development method (ADM)
        1. The Open Group Architecture Framework (TOGAF)
           1. TOGAF architecture domains
           2. TOGAF documentation
        2. Phases of the ADM
           1. Phase A – Architecture vision
           2. Phase B – Business architecture
           3. Phase C – Information systems architectures
           4. Phase D – Technology architecture
           5. Phase E – Opportunities and solutions
           6. Phase F – Migration planning
           7. Phase G – Implementation governance
           8. Phase H – Architecture change management
    13. Tracking the progress of the software architecture's design
        1. Using a backlog to track the architecture design progress
        2. Prioritizing the backlog
           1. DIVE criteria
              1. Dependencies
              2. Insure against risks
              3. Business value
              4. Estimated effort
        3. Active and dynamic architecture backlogs
    14. Summary
12. Software Development Principles and Practices
    1. Designing orthogonal software systems
       1. Loose coupling
          1. Types of coupling
             1. Content coupling
             2. Common coupling
             3. External coupling
             4. Control coupling
             5. Stamp coupling (data-structured coupling)
             6. Data coupling
             7. Message coupling
             8. No coupling
          2. The Law of Demeter (LoD) / principle of least knowledge
          3. Designing for loose coupling
       2. High cohesion
          1. Types of cohesion
             1. Coincidental cohesion
             2. Logical cohesion
             3. Temporal cohesion
             4. Procedural cohesion
             5. Communicational cohesion
             6. Sequential cohesion
             7. Functional cohesion
          2. Designing for high cohesion
    2. Minimizing complexity
       1. KISS principle – "Keep It Simple, Stupid"
          1. Origin of KISS
          2. Applying KISS to software
          3. Don't make it overly simple
       2. DRY – "Don't Repeat Yourself"
          1. Copy-and-paste programming
          2. Magic strings
          3. How to avoid duplication
          4. Don't make things overly DRY
       3. Information hiding
          1. Reasons for information hiding
          2. What needs to be exposed/hidden?
       4. YAGNI – "You Aren't Gonna Need It"
          1. Avoid over-engineering a solution
          2. Situations where YAGNI doesn't apply
       5. Separation of Concerns (SoC)
    3. Following SOLID design principles
       1. Single Responsibility Principle (SRP)
       2. Open/Closed Principle (OCP)
       3. Liskov Substitution Principle (LSP)
       4. Interface Segregation Principle (ISP)
       5. Dependency Inversion Principle (DIP)
          1. Inversion of Control (IoC)
          2. Dependency Injection (DI)
             1. Benefits of DI
             2. DI patterns
             3. DI containers
    4. Helping your team succeed
       1. Unit testing
          1. What are unit tests?
          2. Benefits of unit testing
          3. Properties of a good unit test
             1. Atomic
             2. Deterministic
             3. Automated and repeatable
             4. Isolated and independent
             5. Easy to set up and implement
             6. Fast
          4. The AAA pattern
             1. Arrange
             2. Act
             3. Assert
          5. Naming conventions for unit tests
             1. Unit test class names
             2. Unit test method names
          6. Code coverage for unit tests
          7. Keeping unit tests up to date
       2. Setting up development environments
          1. Providing a README file
       3. Pair programming
          1. Benefits of pair programming
          2. Using pair programming when it is needed
       4. Reviewing deliverables
          1. Code reviews
          2. Formal inspections
             1. Roles for a formal inspection
             2. Inspection meeting and follow-up
          3. Walkthroughs
    5. Summary
13. Software Architecture Patterns
    1. Software architecture patterns
       1. Using software architecture patterns
       2. Overusing architecture patterns
       3. Understanding the difference between architecture styles and architecture patterns
    2. Layered architecture
       1. Open versus closed layers
       2. Tiers versus layers
       3. Advantages of layered architectures
       4. Disadvantages of layered architectures
       5. Client-server architecture (two-tier architecture)
          1. Using stored procedures for application logic
       6. N-tier architecture
          1. Presentation tier
          2. Business tier
          3. Data tier
    3. Event-driven architecture
       1. Event channels
          1. Message queues
             1. The point-to-point channel pattern
          2. Message topics
             1. The publish-subscribe pattern
       2. Event-driven architecture topologies
          1. The mediator topology
             1. Event mediator implementations
          2. The broker topology
       3. Event processing styles
          1. Simple event processing (SEP)
          2. Event stream processing (ESP)
          3. Complex event processing (CEP)
       4. Types of event-driven functionality
          1. Event notification
          2. Event-carried state transfer
          3. Event-sourcing
    4. The Model-View-Controller pattern
       1. Model
       2. View
       3. Controller
       4. Advantages of the MVC pattern
       5. Disadvantages of the MVC pattern
    5. The Model-View-Presenter pattern
       1. Model
       2. View
       3. Presenter
    6. The Model-View-ViewModel pattern
       1. Model
       2. View
       3. ViewModel
    7. The Command Query Responsibility Segregation pattern
       1. The query model and the command model
       2. Using event-sourcing with CQRS
       3. Advantages of CQRS
       4. Disadvantages of CQRS
    8. Service-oriented architecture
       1. What makes SOA different from other distributed solutions?
       2. Benefits of using a SOA
          1. Increases alignment between business and technology
          2. Promotes federation within an organization
          3. Allows for vendor diversity
          4. Increases intrinsic interoperability
          5. Works well with agile development methodologies
       3. Cost-benefit analysis of SOA
       4. Challenges with SOA
       5. Key principles for service orientation
          1. Standardized service contract
          2. Service loose coupling
          3. Service abstraction
          4. Service reusability
          5. Service autonomy
          6. Service statelessness
          7. Service discoverability
          8. Service composability
       6. SOA delivery strategies
          1. The top-down strategy
          2. The bottom-up strategy
          3. The agile strategy
       7. Service-oriented analysis
          1. Defining business automation requirements
          2. Identifying existing automation systems
          3. Modeling candidate services
          4. Service layers and service models
             1. Task service
             2. Entity service
             3. Utility service
       8. Service-oriented design
          1. Service interface design
          2. Service interface granularity
       9. Service registries
       10. Service descriptions
       11. Structuring namespaces
       12. Orchestration and choreography
    9. Summary
14. Architecting Modern Applications
    1. Monolithic architecture
       1. Benefits of a monolithic architecture
       2. Drawbacks of a monolithic architecture
    2. Microservice architecture
       1. SOA done right
       2. Characteristics of microservice architecture
          1. Small, focused services
          2. Well-defined service interfaces
          3. Autonomous and independently deployable services
          4. Independent data storage
          5. Better fault isolation
          6. Communicating with lightweight message protocols
       3. Designing polyglot microservices
          1. Polyglot programming
          2. Polyglot persistence
          3. Using too many technologies
       4. Considering service granularity
          1. Nanoservices
       5. Sharing dependencies between microservices
       6. Stateless versus stateful microservices
       7. Service discovery
          1. Using a service registry
             1. Self-registration pattern
             2. Third-party registration pattern
          2. Types of service discovery
             1. Client-side discovery pattern
             2. Server-side discovery pattern
       8. Using microservices is not for everyone
    3. Serverless architecture
       1. Function as a Service (FaaS)
       2. Backend as a Service (BaaS)
       3. Advantages of serverless architectures
          1. Cost savings
          2. Scalable and flexible
          3. Focus on building your core products
          4. Polyglot development
       4. Disadvantages of serverless architectures
          1. Difficulties with debugging and monitoring
          2. Multitenancy issues
          3. Vendor lock-in
          4. Complexity of designing many functions
          5. Not as many runtime optimizations
          6. Still immature
       5. Taking a hybrid approach to serverless
       6. Function deployment
       7. Function invocation
          1. Synchronous request
          2. Asynchronous request (message queue)
          3. Message stream
          4. Batch job
    4. Cloud-native applications
       1. Reasons to move to the cloud
          1. Reducing costs
          2. Greater flexibility and scalability
          3. Automatic updates
          4. Disaster recovery
       2. What are cloud-native applications?
          1. Containerized
          2. Dynamically orchestrated
          3. Microservices-oriented
          4. No downtime
          5. Continuous delivery
          6. Support for a variety of devices
       3. Twelve-factor apps
          1. Codebase
          2. Dependencies
          3. Configuration
          4. Backing services
          5. Build/Release/Run
          6. Processes
          7. Port binding
          8. Concurrency
          9. Disposability
          10. Development/production parity
          11. Logs
          12. Administrative processes
    5. Summary
15. Cross-Cutting Concerns
    1. Cross-cutting concerns
    2. General guidelines for cross-cutting concerns
       1. Identifying cross-cutting concerns
       2. Using open-source and third-party solutions
       3. Maintaining consistency
       4. Avoiding scattered solutions
       5. Avoiding tangled solutions
    3. Implementing cross-cutting concerns
       1. Using dependency injection (DI)
       2. Using the decorator pattern
    4. Aspect-oriented programming
       1. Types of advice
       2. Weaving
          1. Compile-time weaving
          2. Runtime weaving
    5. Types of cross-cutting concerns
       1. Caching
       2. Configuration management
       3. Auditing
       4. Security
       5. Exception management
       6. Logging
          1. Understanding log levels
          2. Routing log entries
          3. Using Elastic Stack
             1. Elasticsearch
             2. Logstash
             3. Kibana
             4. Beats
    6. Cross-cutting concerns for microservices
       1. Leveraging a microservice chassis
       2. Using the sidecar pattern
    7. Summary
16. Performance Considerations
    1. The importance of performance
       1. Performance affects user experience
          1. Bounce rate
          2. Conversion rate
       2. Performance is a requirement
       3. Page speed affects search rankings
    2. Defining performance terminology
       1. Latency
       2. Throughput
       3. Bandwidth
       4. Processing time
       5. Response time
       6. Workload
       7. Utilization
    3. Taking a systematic approach to performance improvement
       1. Profiling an application
          1. Instrumentation
          2. Statistical profilers
       2. Analyzing the results
       3. Implementing changes
       4. Monitoring results
    4. Server-side caching
       1. Caching data in distributed applications
          1. Using a private caching strategy
          2. Using a shared caching strategy
       2. Priming the cache
       3. Invalidating cached data
          1. Expiring data
          2. Evicting data
       4. Cache usage patterns
          1. Cache-aside pattern
          2. Read-through pattern
          3. Write-through pattern
          4. Write-behind pattern
    5. Improving web application performance
       1. Leveraging HTTP caching
          1. Using a validation token
          2. Specifying cache-control directives
       2. Taking advantage of compression
          1. File compression
             1. Lossless compression
             2. Lossy compression
          2. Content-encoding (end-to-end) compression
       3. Minifying resources
       4. Bundling resources
       5. Using HTTP/2
          1. Multiplexing
          2. Server push
          3. Header compression
          4. Implementing HTTP/2
       6. Using content delivery networks (CDNs)
       7. Optimizing web fonts
       8. Optimizing the critical rendering path
    6. Database performance
       1. Designing an efficient database schema
          1. Normalizing a database
          2. Denormalizing a database
          3. Identifying primary and foreign keys
          4. Selecting the most appropriate data types
       2. Using database indexes
          1. Primary/clustered indexes
          2. Secondary/non-clustered indexes
          3. Having too many indexes
       3. Scaling up and out
       4. Database concurrency
          1. Database transactions
          2. Optimistic versus pessimistic concurrency control
          3. CAP theorem
          4. ACID model
             1. Atomicity
             2. Consistency
             3. Isolation
             4. Durability
          5. BASE model
             1. Basic availability
             2. Soft state
             3. Eventual consistency
    7. Summary
17. Security Considerations
    1. Securing software systems
       1. The three states of information
       2. The CIA triad
          1. Confidentiality
          2. Integrity
          3. Availability
    2. Threat modeling
       1. Decomposing an application
       2. Identifying and categorizing potential threats
          1. STRIDE threat model
             1. Spoofing identity
             2. Tampering with data
             3. Repudiation
             4. Information disclosure
             5. Denial-of-service
             6. Elevation of Privilege
       3. Prioritizing potential threats
          1. DREAD risk assessment model
             1. Damage potential
             2. Reproducibility
             3. Exploitability
             4. Affected users
             5. Discoverability
       4. Responses to threats
          1. Avoiding the risk
          2. Transferring the risk
          3. Accepting the risk
          4. Mitigating the risk
          5. Types of security control
             1. Physical security controls
             2. Administrative controls
             3. Technical security controls
             4. Prevention
             5. Detection
             6. Response
    3. Secure by design
       1. Minimizing the attack surface
       2. Defense in depth
       3. Principle of least privilege (PoLP)
       4. Avoiding security by obscurity
       5. Keep software designs simple
       6. Secure by default
       7. Default deny
       8. Validating input
       9. Secure the weakest link
       10. Security must be usable
       11. Fail securely
    4. Cryptography
       1. Encryption
          1. Symmetric (secret key) encryption
          2. Asymmetric (public key) encryption
       2. Cryptographic hash functions
    5. Identity and access management (IAM)
       1. Authentication
          1. What is multi-factor authentication (MFA)?
       2. Authorization
       3. Storing plaintext passwords
       4. Storing encrypted passwords
       5. Storing hashed passwords
       6. Using domain authentication
       7. Implementing a centralized identity provider (IdP)
       8. OAuth 2/OpenID Connect (OIDC)
          1. OAuth 2 roles
          2. Authenticating with the identity provider
          3. JSON web token (JWT)
             1. Header
             2. Payload
             3. Signature
          4. Authorizing with the authorization server
    6. Most common web application security risks
       1. Injection
       2. Broken authentication
       3. Sensitive data exposure
       4. XML external entity (XXE) attack
       5. Broken access control
       6. Security misconfiguration
       7. Cross-site scripting (XSS)
       8. Insecure deserialization
       9. Using components with known vulnerable components
       10. Insufficient logging and monitoring
       11. Unvalidated redirects and forwards
    7. Summary
18. Documenting and Reviewing Software Architectures
    1. Uses of software architecture documentation
       1. Communicating your architecture to others
       2. Assisting the development team
       3. Educates team members
       4. Providing input for software architecture reviews
       5. Allowing for the reuse of architectural knowledge
       6. Help the software architect
    2. Creating architecture descriptions (ADs)
       1. Software architecture views
          1. Software architecture notations
             1. Informal software architecture notations
             2. Semiformal software architecture notations
             3. Formal software architecture notations
          2. Including design rationales
       2. Overview of the Unified Modeling Language (UML)
          1. Types of modeling
          2. Class diagrams
             1. Visibility
             2. Association
             3. Aggregation
             4. Composition
             5. Multiplicity
             6. Dependency
             7. Generalization/specialization
             8. Realization
          3. Component diagrams
          4. Package diagrams
          5. Deployment diagrams
          6. Use case diagrams
          7. Sequence diagrams
             1. Lifeline
             2. Activation boxes
             3. Messages
             4. Loops
             5. Optional flows
             6. Alternative flows
          8. Activity diagrams
             1. Start/end nodes
             2. Actions/Control flow
             3. Decision/merge nodes
             4. Fork/join nodes
    3. Reviewing software architectures
       1. Software architecture analysis method (SAAM)
          1. Scenario-based analysis of software architecture
          2. SAAM steps
             1. Step 1 – Develop scenarios
             2. Step 2 – Describe the architecture
             3. Step 3 – Classify and prioritize scenarios
             4. Step 4 – Evaluate scenarios
             5. Step 5 – Assess scenario interaction
             6. Step 6 – Create an overall evaluation
       2. Architecture tradeoff analysis method (ATAM)
          1. ATAM participant roles
          2. ATAM phases
             1. Phase 0 – Partnership and preparation
             2. Phase 1 – Evaluation
             3. Phase 2 – Evaluation (continued)
             4. Phase 3 – Follow-up
       3. Active design review (ADR)
          1. ADR steps
             1. Step 1 – Prepare the documentation for review
             2. Step 2 – Identify the specialized reviews
             3. Step 3 – Identify the reviewers needed
             4. Step 4 – Design the questionnaires
             5. Step 5 – Conduct the review
       4. Active reviews of intermediate designs (ARID)
          1. ARID participant roles
          2. ARID phases
             1. Phase 1 – Pre-meeting
             2. Phase 2 – Review meeting
    4. Summary
19. DevOps and Software Architecture
    1. DevOps
       1. CALMS
          1. Culture
          2. Automation
          3. Lean
          4. Measurement
          5. Sharing
       2. Why DevOps?
    2. DevOps toolchain
    3. DevOps practices
       1. Continuous integration (CI)
          1. Automated builds
             1. Software versioning
          2. Automated testing
       2. Continuous delivery (CD)
       3. Continuous deployment
    4. Architecting for DevOps
       1. Important quality attributes for DevOps
       2. Some architecture patterns complement DevOps
    5. Deploying to the cloud
       1. Cloud types
          1. Public cloud
          2. Private cloud
          3. Hybrid cloud
       2. Cloud models
          1. Infrastructure as a service (IaaS)
          2. Containers as a Service (CaaS)
          3. Platform as a Service (PaaS)
          4. Serverless/Function as a Service (FaaS)
          5. Software as a Service (SaaS)
    6. Summary
20. Architecting Legacy Applications
    1. Legacy applications
       1. Issues with legacy applications
       2. Why are legacy applications used?
       3. More than just code
    2. Refactoring legacy applications
       1. Making legacy code testable
          1. Benefits of unit testing
          2. Refactoring for unit tests
          3. Where to start writing tests?
       2. Removing redundant code
          1. Unreachable code
          2. Dead code
          3. Commented-out code
          4. Duplicate code
       3. Using tools to refactor
       4. Making small, incremental changes
       5. Transforming monoliths to microservices
    3. Migrating to the cloud
       1. The 6 R's
          1. Remove (or retire)
          2. Retain
          3. Replatform
          4. Rehost
          5. Repurchase
          6. Refactor (or re-architect)
    4. Moving to an agile approach
    5. Modernizing build and deployment processes
       1. Automating the build and deployment processes
       2. Practicing continuous integration (CI)
       3. Practicing continuous delivery (CD)
       4. Updating the build tools
    6. Integrating with legacy applications
       1. Confirming the need for integration
       2. Determining the type of integration
       3. Sharing functionality between systems
       4. Performing data integration
    7. Summary
21. The Soft Skills of Software Architects
    1. Soft skills
    2. Communication
       1. Communicating the architecture
       2. Communicating about quality attributes
       3. Communicating expectations
       4. The 7 Cs of communication
          1. Clarity
          2. Conciseness
          3. Concreteness
          4. Courteousness
          5. Consideration
          6. Correctness
          7. Completeness
       5. Listening skills
          1. Hearing is not listening
          2. Showing empathy
          3. Tips for effective listening
       6. Giving presentations
          1. The 4 Ps of presentations
             1. Plan
             2. Prepare
             3. Practice
             4. Present
    3. Leadership
       1. Getting others to follow you
       2. Dealing with challenges
       3. Being a technical leader
       4. Taking responsibility
       5. Focusing on others
       6. Delegating tasks
       7. Driving change
       8. Communication and leadership
       9. Mentoring others
       10. Leading by example
       11. Depending on others
    4. Negotiation
       1. How negotiation skills may be used
       2. Informal/formal negotiations
    5. Working with remote resources
       1. Benefits of using remote resources
       2. Challenges when using remote resources
          1. Communication
          2. Cultural differences
          3. Impromptu meetings
          4. New employee onboarding
          5. Work quality
          6. Confidential company data
    6. Summary
22. Evolutionary Architecture
    1. Change is inevitable
       1. Reasons for change
       2. Expecting change
    2. Lehman's laws of software evolution
       1. Lehman's software categories
          1. S-type systems
          2. P-type systems
          3. E-type systems
       2. The laws
          1. Law I – Continuing change
          2. Law II – Increasing complexity
          3. Law III – Self-regulation
          4. Law IV – Conservation of organizational stability
          5. Law V – Conservation of familiarity
          6. Law VI – Continuing growth
          7. Law VII – Declining quality
          8. Law VIII – Feedback system
    3. Designing evolutionary architectures
       1. Making guided architectural changes
          1. Fitness functions
             1. Categories of fitness functions
             2. Examples of fitness functions
       2. Making incremental changes
       3. Architectural changes across multiple dimensions
       4. Loosely coupled architectures
       5. Designing evolvable APIs
          1. Applying Postel's Law to APIs
       6. Using standards in your software system
       7. Last responsible moment (LRM)
    4. Summary
23. Becoming a Better Software Architect
    1. Practicing continuous learning
       1. Improving the breadth and depth of your knowledge
       2. Avoiding the law of the instrument
       3. Finding the time for learning
       4. Ways to keep your skills sharp
    2. Participating in open source projects
       1. Creating your own open source project
    3. Writing your own blog
       1. Increasing your visibility
       2. Starting your own blog
       3. Things to avoid
    4. Spending time teaching others
       1. Finding opportunities to teach
       2. Being a mentor
    5. Trying new technologies
    6. Continuing to write code
       1. Assigning yourself coding tasks
       2. Working on your own project
       3. Reading code
    7. Attending user groups and conferences
       1. Presenting at a user group or conference
       2. Meeting new people
    8. Taking responsibility for your work
    9. Attending to your well-being
       1. Being proud of your work
    10. Summary
24. Other Books You May Enjoy
    1. Leave a review - let other readers know what you think