Software Architect's Handbook by Ingeno, Joseph -- Read -- Imperial Library of Trantor

Index

Title Page Copyright and Credits

Software Architect's Handbook

Dedication Packt Upsell

Why subscribe? PacktPub.com

Contributors

About the author About the reviewers Packt is searching for authors like you

Preface

Who this book is for What this book covers To get the most out of this book

Download the color images Conventions used

Get in touch

Reviews

The Meaning of Software Architecture

What is software architecture?

ISO/IEC/IEEE 42010 standard definition What makes up a software architecture? Software architecture is an abstraction Software architecture is about the important stuff

Why is software architecture important?

Defining a solution to meet requirements Enabling and inhibiting quality attributes Giving you the ability to predict software system qualities Easing communication among stakeholders Managing change Providing a reusable model Imposing implementation constraints Improving cost and effort estimates Serves as training for team members Software architecture is not a silver bullet

Who are the consumers of software architectures? What is the software architect role?

Software architects are technical leaders Software architects perform a number of duties Ivory tower software architects What are software architects expected to know? Don't be overwhelmed Is the software architect role right for you?

Summary

Software Architecture in an Organization

Types of software architects

Enterprise architect Solution architect Application architect Data architect/information architect Infrastructure architect Information security architect Cloud architect

Software development methodologies

The Waterfall model

Phases of the Waterfall methodology Issues with the Waterfall methodology

Agile software development methodologies

Agile values and principles An iterative methodology Adaptive rather than predictive Daily stand-up meetings

Project management

The importance of software project estimation Putting effort into the estimates Being a realist (or even a pessimist) Team and situational factors to consider Project schedule changes Getting a project back on schedule

Working overtime Reducing scope Adding resources Reallocating resources Identifying problem areas Acting as early as possible

Office politics

Understanding your organization's goals Addressing the concerns of others Assisting people with their goals Knowing when to compromise Being aware of cultural differences

Software risk management

Risk avoidance Transferring the risk to another party Risk mitigation Risk acceptance

Configuration management

Changing management

Software product lines

Benefits of a software product line Core assets of an organization Risks of product line engineering

Summary

Understanding the Domain

Developing business acumen

Familiarity with general business topics Understanding your organization's business

Domain-driven design

Encourages and improves communication What is a ubiquitous language? Entities, value objects, and aggregates

Entities Value objects Aggregates and root entities

Separating the domain into subdomains What are bounded contexts?

Requirements engineering

Types of software requirements

Business requirements Functional requirements Non-functional requirements Constraints

The importance of requirements engineering Software requirements must be measurable and testable Software requirements that affect architecture

Requirements elicitation

Techniques to elicit requirements

Interviews Requirements workshops Brainstorming Observation Focus groups Surveys Document analysis Prototyping Reverse engineering

Get access to the proper stakeholders

Summary

Software Quality Attributes

Quality attributes

External or internal Quality attributes and the SDLC Testing quality attributes

Maintainability

Types of software maintenance

Corrective maintenance Perfective maintenance Adaptive maintenance Preventive maintenance

Modifiability Extensibility and flexibility Scope of modifications Designing for maintainability

Reducing size Increasing cohesion Reducing coupling

Measuring maintainability

Lines of code (LOC) Cyclomatic complexity Depth of inheritance tree (DIT)

Usability

Allowing users to complete their tasks efficiently Learnability Providing useful feedback Accessibility Usability needs to be considered during requirements Usability testing Appealing visual design Providing a good help system Software must be useful, and not just usable

Availability

Calculating availability based on time Calculating availability based on request success rate Faults, errors, and failures Detecting faults

Ping/echo reply Heartbeat Timestamp Voting Sanity test/sanity checking Condition monitoring Self-tests

Recovering from faults

Exception handling Retry strategy Varying levels of redundancy Rollback Graceful degradation Ignoring faulty behavior

Preventing faults

Removal from service Transactions Increasing competence sets Exception prevention

Portability

Adaptability Installability Replaceability Internationalization and localization Maintaining portability

Interoperability

Challenges with interoperability Locating and exchanging information with another system Interoperability standards Interoperability testing

Testability

Controllability Observability Isolability Automatability Complexity of the software Importance of test documentation What makes a good tester?

Summary

Designing Software Architectures

Software architecture design

Making design decisions Software architecture design terms

Structure Element System Subsystem Module Component

The importance of software architecture design

Making key decisions Avoiding design decisions can incur technical debt Communicating the architecture to others Providing guidance to developers Influencing non-technical parts of the project

Top-down versus bottom-up design approaches

Top-down approach

Advantages of the top-down approach Disadvantages of the top-down approach

Bottom-up approach

Advantages of the bottom-up approach Disadvantages of the bottom-up approach

Which approach should I use?

Greenfield versus brownfield software systems

Greenfield systems Brownfield systems

Architectural drivers

Design objectives Primary functional requirements Quality attribute scenarios

Prioritizing quality attribute scenarios

Constraints Architectural concerns

Leveraging design principles and existing solutions

Selecting a design concept Software architecture patterns Reference architectures

Benefits of reference architectures Refactoring a reference architecture for your needs Creating your own reference architecture

Tactics Externally developed software

Buy or build?

Advantages/disadvantages of building Advantages/disadvantages of buying

Researching external software Should I use open source software (OSS)?

Advantages of using open source software Disadvantages of using open source software

Documenting the software architecture design

Sketching the architecture design Documenting the design rationale

Design rationale for design evaluation Design rationale for design verification Design rationale for design knowledge transfer Design rationale for design communication Design rationale for design maintenance Design rationale for design documentation Design rationale for design reuse

Using a systematic approach to software architecture design

A general model of software architecture design

Architectural analysis Architectural synthesis Architectural evaluation

Architecture design is an iterative process Selecting an architecture design process

Attribute-driven design (ADD)

Step 1 – Reviewing inputs Step 2 – Establishing the iteration goal and selecting inputs to be considered in the iteration Step 3 – Choosing one or more elements of the system to refine Step 4 – Choosing one or more design concepts that satisfy the inputs considered in the iteration Step 5 – Instantiating architectural elements, allocating responsibilities, and defining interfaces Step 6 – Sketching views and recording design decisions Step 7 – Performing analysis of current design and reviewing the iteration goal and design objectives Step 8 – Iterating if necessary

Microsoft's technique for architecture and design

Step 1 – Identifying architecture objectives Step 2 – Identifying key scenarios Step 3 – Creating application overview

Determining your application type Identifying your deployment constraints Identifying important architecture design styles Determining relevant technologies

Step 4 – Identifying key issues Step 5 – Defining candidate solutions

Architecture-centric design method (ACDM)

Step 1 – Discovering architectural drivers Step 2 – Establishing project scope Step 3 – Creating notional architecture Step 4 – Architectural review Step 5 – Production go/no-go Step 6 – Experiment planning Step 7 – Experimenting with and refining the architecture Production planning and production

Architecture development method (ADM)

The Open Group Architecture Framework (TOGAF)

TOGAF architecture domains TOGAF documentation

Phases of the ADM

Phase A – Architecture vision Phase B – Business architecture Phase C – Information systems architectures Phase D – Technology architecture Phase E – Opportunities and solutions Phase F – Migration planning Phase G – Implementation governance Phase H – Architecture change management

Tracking the progress of the software architecture's design

Using a backlog to track the architecture design progress Prioritizing the backlog

DIVE criteria

Dependencies Insure against risks Business value Estimated effort

Active and dynamic architecture backlogs

Summary

Software Development Principles and Practices

Designing orthogonal software systems

Loose coupling

Types of coupling

Content coupling Common coupling External coupling Control coupling Stamp coupling (data-structured coupling) Data coupling Message coupling No coupling

The Law of Demeter (LoD) / principle of least knowledge Designing for loose coupling

High cohesion

Types of cohesion

Coincidental cohesion Logical cohesion Temporal cohesion Procedural cohesion Communicational cohesion Sequential cohesion Functional cohesion

Designing for high cohesion

Minimizing complexity

KISS principle – "Keep It Simple, Stupid"

Origin of KISS Applying KISS to software Don't make it overly simple

DRY – "Don't Repeat Yourself"

Copy-and-paste programming Magic strings How to avoid duplication Don't make things overly DRY

Information hiding

Reasons for information hiding What needs to be exposed/hidden?

YAGNI – "You Aren't Gonna Need It"

Avoid over-engineering a solution Situations where YAGNI doesn't apply

Separation of Concerns (SoC)

Following SOLID design principles

Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP)

Inversion of Control (IoC) Dependency Injection (DI)

Benefits of DI DI patterns DI containers

Helping your team succeed

Unit testing

What are unit tests? Benefits of unit testing Properties of a good unit test

Atomic Deterministic Automated and repeatable Isolated and independent Easy to set up and implement Fast

The AAA pattern

Arrange Act Assert

Naming conventions for unit tests

Unit test class names Unit test method names

Code coverage for unit tests Keeping unit tests up to date

Setting up development environments

Providing a README file

Pair programming

Benefits of pair programming Using pair programming when it is needed

Reviewing deliverables

Code reviews Formal inspections

Roles for a formal inspection Inspection meeting and follow-up

Walkthroughs

Summary

Software Architecture Patterns

Software architecture patterns

Using software architecture patterns Overusing architecture patterns Understanding the difference between architecture styles and architecture patterns

Layered architecture

Open versus closed layers Tiers versus layers Advantages of layered architectures Disadvantages of layered architectures Client-server architecture (two-tier architecture)

Using stored procedures for application logic

N-tier architecture

Presentation tier Business tier Data tier

Event-driven architecture

Event channels

Message queues

The point-to-point channel pattern

Message topics

The publish-subscribe pattern

Event-driven architecture topologies

The mediator topology

Event mediator implementations

The broker topology

Event processing styles

Simple event processing (SEP) Event stream processing (ESP) Complex event processing (CEP)

Types of event-driven functionality

Event notification Event-carried state transfer Event-sourcing

The Model-View-Controller pattern

Model View Controller Advantages of the MVC pattern Disadvantages of the MVC pattern

The Model-View-Presenter pattern

Model View Presenter

The Model-View-ViewModel pattern

Model View ViewModel

The Command Query Responsibility Segregation pattern

The query model and the command model Using event-sourcing with CQRS Advantages of CQRS Disadvantages of CQRS

Service-oriented architecture

What makes SOA different from other distributed solutions? Benefits of using a SOA

Increases alignment between business and technology Promotes federation within an organization Allows for vendor diversity Increases intrinsic interoperability Works well with agile development methodologies

Cost-benefit analysis of SOA Challenges with SOA Key principles for service orientation

Standardized service contract Service loose coupling Service abstraction Service reusability Service autonomy Service statelessness Service discoverability Service composability

SOA delivery strategies

The top-down strategy The bottom-up strategy The agile strategy

Service-oriented analysis

Defining business automation requirements Identifying existing automation systems Modeling candidate services Service layers and service models

Task service Entity service Utility service

Service-oriented design

Service interface design Service interface granularity

Service registries Service descriptions Structuring namespaces Orchestration and choreography

Summary

Architecting Modern Applications

Monolithic architecture

Benefits of a monolithic architecture Drawbacks of a monolithic architecture

Microservice architecture

SOA done right Characteristics of microservice architecture

Small, focused services Well-defined service interfaces Autonomous and independently deployable services Independent data storage Better fault isolation Communicating with lightweight message protocols

Designing polyglot microservices

Polyglot programming Polyglot persistence Using too many technologies

Considering service granularity

Nanoservices

Sharing dependencies between microservices Stateless versus stateful microservices Service discovery

Using a service registry

Self-registration pattern Third-party registration pattern

Types of service discovery

Client-side discovery pattern Server-side discovery pattern

Using microservices is not for everyone

Serverless architecture

Function as a Service (FaaS) Backend as a Service (BaaS) Advantages of serverless architectures

Cost savings Scalable and flexible Focus on building your core products Polyglot development

Disadvantages of serverless architectures

Difficulties with debugging and monitoring Multitenancy issues Vendor lock-in Complexity of designing many functions Not as many runtime optimizations Still immature

Taking a hybrid approach to serverless Function deployment Function invocation

Synchronous request Asynchronous request (message queue) Message stream Batch job

Cloud-native applications

Reasons to move to the cloud

Reducing costs Greater flexibility and scalability Automatic updates Disaster recovery

What are cloud-native applications?

Containerized Dynamically orchestrated Microservices-oriented No downtime Continuous delivery Support for a variety of devices

Twelve-factor apps

Codebase Dependencies Configuration Backing services Build/Release/Run Processes Port binding Concurrency Disposability Development/production parity Logs Administrative processes

Summary

Cross-Cutting Concerns

Cross-cutting concerns General guidelines for cross-cutting concerns

Identifying cross-cutting concerns Using open-source and third-party solutions Maintaining consistency Avoiding scattered solutions Avoiding tangled solutions

Implementing cross-cutting concerns

Using dependency injection (DI) Using the decorator pattern

Aspect-oriented programming

Types of advice Weaving

Compile-time weaving Runtime weaving

Types of cross-cutting concerns

Caching Configuration management Auditing Security Exception management Logging

Understanding log levels Routing log entries Using Elastic Stack

Elasticsearch Logstash Kibana Beats

Cross-cutting concerns for microservices

Leveraging a microservice chassis Using the sidecar pattern

Summary

Performance Considerations

The importance of performance

Performance affects user experience

Bounce rate Conversion rate

Performance is a requirement Page speed affects search rankings

Defining performance terminology

Latency Throughput Bandwidth Processing time Response time Workload Utilization

Taking a systematic approach to performance improvement

Profiling an application

Instrumentation Statistical profilers

Analyzing the results Implementing changes Monitoring results

Server-side caching

Caching data in distributed applications

Using a private caching strategy Using a shared caching strategy

Priming the cache Invalidating cached data

Expiring data Evicting data

Cache usage patterns

Cache-aside pattern Read-through pattern Write-through pattern Write-behind pattern

Improving web application performance

Leveraging HTTP caching

Using a validation token Specifying cache-control directives

Taking advantage of compression

File compression

Lossless compression Lossy compression

Content-encoding (end-to-end) compression

Minifying resources Bundling resources Using HTTP/2

Multiplexing Server push Header compression Implementing HTTP/2

Using content delivery networks (CDNs) Optimizing web fonts Optimizing the critical rendering path

Database performance

Designing an efficient database schema

Normalizing a database Denormalizing a database Identifying primary and foreign keys Selecting the most appropriate data types

Using database indexes

Primary/clustered indexes Secondary/non-clustered indexes Having too many indexes

Scaling up and out Database concurrency

Database transactions Optimistic versus pessimistic concurrency control CAP theorem ACID model

Atomicity Consistency Isolation Durability

BASE model

Basic availability Soft state Eventual consistency

Summary

Security Considerations

Securing software systems

The three states of information The CIA triad

Confidentiality Integrity Availability

Threat modeling

Decomposing an application Identifying and categorizing potential threats

STRIDE threat model

Spoofing identity Tampering with data Repudiation Information disclosure Denial-of-service Elevation of Privilege

Prioritizing potential threats

DREAD risk assessment model

Damage potential Reproducibility Exploitability Affected users Discoverability

Responses to threats

Avoiding the risk Transferring the risk Accepting the risk Mitigating the risk Types of security control

Physical security controls Administrative controls Technical security controls Prevention Detection Response

Secure by design

Minimizing the attack surface Defense in depth Principle of least privilege (PoLP) Avoiding security by obscurity Keep software designs simple Secure by default Default deny Validating input Secure the weakest link Security must be usable Fail securely

Cryptography

Encryption

Symmetric (secret key) encryption Asymmetric (public key) encryption

Cryptographic hash functions

Identity and access management (IAM)

Authentication

What is multi-factor authentication (MFA)?

Authorization Storing plaintext passwords Storing encrypted passwords Storing hashed passwords Using domain authentication Implementing a centralized identity provider (IdP) OAuth 2/OpenID Connect (OIDC)

OAuth 2 roles Authenticating with the identity provider JSON web token (JWT)

Header Payload Signature

Authorizing with the authorization server

Most common web application security risks

Injection Broken authentication Sensitive data exposure XML external entity (XXE) attack Broken access control Security misconfiguration Cross-site scripting (XSS) Insecure deserialization Using components with known vulnerable components Insufficient logging and monitoring Unvalidated redirects and forwards

Summary

Documenting and Reviewing Software Architectures

Uses of software architecture documentation

Communicating your architecture to others Assisting the development team Educates team members Providing input for software architecture reviews Allowing for the reuse of architectural knowledge Help the software architect

Creating architecture descriptions (ADs)

Software architecture views

Software architecture notations

Informal software architecture notations Semiformal software architecture notations Formal software architecture notations

Including design rationales

Overview of the Unified Modeling Language (UML)

Types of modeling Class diagrams

Visibility Association Aggregation Composition Multiplicity Dependency Generalization/specialization Realization

Component diagrams Package diagrams Deployment diagrams Use case diagrams Sequence diagrams

Lifeline Activation boxes Messages Loops Optional flows Alternative flows

Activity diagrams

Start/end nodes Actions/Control flow Decision/merge nodes Fork/join nodes

Reviewing software architectures

Software architecture analysis method (SAAM)

Scenario-based analysis of software architecture SAAM steps

Step 1 – Develop scenarios Step 2 – Describe the architecture Step 3 – Classify and prioritize scenarios Step 4 – Evaluate scenarios Step 5 – Assess scenario interaction Step 6 – Create an overall evaluation

Architecture tradeoff analysis method (ATAM)

ATAM participant roles ATAM phases

Phase 0 – Partnership and preparation Phase 1 – Evaluation Phase 2 – Evaluation (continued) Phase 3 – Follow-up

Active design review (ADR)

ADR steps

Step 1 – Prepare the documentation for review Step 2 – Identify the specialized reviews Step 3 – Identify the reviewers needed Step 4 – Design the questionnaires Step 5 – Conduct the review

Active reviews of intermediate designs (ARID)

ARID participant roles ARID phases

Phase 1 – Pre-meeting Phase 2 – Review meeting

Summary

DevOps and Software Architecture

DevOps

CALMS

Culture Automation Lean Measurement Sharing

Why DevOps?

DevOps toolchain DevOps practices

Continuous integration (CI)

Automated builds

Software versioning

Automated testing

Continuous delivery (CD) Continuous deployment

Architecting for DevOps

Important quality attributes for DevOps Some architecture patterns complement DevOps

Deploying to the cloud

Cloud types

Public cloud Private cloud Hybrid cloud

Cloud models

Infrastructure as a service (IaaS) Containers as a Service (CaaS) Platform as a Service (PaaS) Serverless/Function as a Service (FaaS) Software as a Service (SaaS)

Summary

Architecting Legacy Applications

Legacy applications

Issues with legacy applications Why are legacy applications used? More than just code

Refactoring legacy applications

Making legacy code testable

Benefits of unit testing Refactoring for unit tests Where to start writing tests?

Removing redundant code

Unreachable code Dead code Commented-out code Duplicate code

Using tools to refactor Making small, incremental changes Transforming monoliths to microservices

Migrating to the cloud

The 6 R's

Remove (or retire) Retain Replatform Rehost Repurchase Refactor (or re-architect)

Moving to an agile approach Modernizing build and deployment processes

Automating the build and deployment processes Practicing continuous integration (CI) Practicing continuous delivery (CD) Updating the build tools

Integrating with legacy applications

Confirming the need for integration Determining the type of integration Sharing functionality between systems Performing data integration

Summary

The Soft Skills of Software Architects

Soft skills Communication

Communicating the architecture Communicating about quality attributes Communicating expectations The 7 Cs of communication

Clarity Conciseness Concreteness Courteousness Consideration Correctness Completeness

Listening skills

Hearing is not listening Showing empathy Tips for effective listening

Giving presentations

The 4 Ps of presentations

Plan Prepare Practice Present

Leadership

Getting others to follow you Dealing with challenges Being a technical leader Taking responsibility Focusing on others Delegating tasks Driving change Communication and leadership Mentoring others Leading by example Depending on others

Negotiation

How negotiation skills may be used Informal/formal negotiations

Working with remote resources

Benefits of using remote resources Challenges when using remote resources

Communication Cultural differences Impromptu meetings New employee onboarding Work quality Confidential company data

Summary

Evolutionary Architecture

Change is inevitable

Reasons for change Expecting change

Lehman's laws of software evolution

Lehman's software categories

S-type systems P-type systems E-type systems

The laws

Law I – Continuing change Law II – Increasing complexity Law III – Self-regulation Law IV – Conservation of organizational stability Law V – Conservation of familiarity Law VI – Continuing growth Law VII – Declining quality Law VIII – Feedback system

Designing evolutionary architectures

Making guided architectural changes

Fitness functions

Categories of fitness functions Examples of fitness functions

Making incremental changes Architectural changes across multiple dimensions Loosely coupled architectures Designing evolvable APIs

Applying Postel's Law to APIs

Using standards in your software system Last responsible moment (LRM)

Summary

Becoming a Better Software Architect

Practicing continuous learning

Improving the breadth and depth of your knowledge Avoiding the law of the instrument Finding the time for learning Ways to keep your skills sharp

Participating in open source projects

Creating your own open source project

Writing your own blog

Increasing your visibility Starting your own blog Things to avoid

Spending time teaching others

Finding opportunities to teach Being a mentor

Trying new technologies Continuing to write code

Assigning yourself coding tasks Working on your own project Reading code

Attending user groups and conferences

Presenting at a user group or conference Meeting new people

Taking responsibility for your work Attending to your well-being

Being proud of your work

Summary

Other Books You May Enjoy

Leave a review - let other readers know what you think

← Prev
Back
Next →

← Prev
Back
Next →