39,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
The Software Architect’s Handbook is a comprehensive guide to help developers, architects, and senior programmers advance their career in the software architecture domain. This book takes you through all the important concepts, right from design principles to different considerations at various stages of your career in software architecture.
The book begins by covering the fundamentals, benefits, and purpose of software architecture. You will discover how software architecture relates to an organization, followed by identifying its significant quality attributes. Once you have covered the basics, you will explore design patterns, best practices, and paradigms for efficient software development.
The book discusses which factors you need to consider for performance and security enhancements. You will learn to write documentation for your architectures and make appropriate decisions when considering DevOps. In addition to this, you will explore how to design legacy applications before understanding how to create software architectures that evolve as the market, business requirements, frameworks, tools, and best practices change over time.
By the end of this book, you will not only have studied software architecture concepts but also built the soft skills necessary to grow in this field.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 857
Veröffentlichungsjahr: 2018
Ähnliche
Software Architect's Handbook
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Merint MathewAcquisition Editor: Denim PintoContent Development Editor: Priyanka SawantTechnical Editor: Ketan KambleCopy Editor: Safis EditingProject Coordinator: Vaidehi SawantProofreader: Safis EditingIndexer: Priyanka DhadkeGraphics: Jason MonteiroProduction Coordinator: Aparna Bhagat
First published: August 2018
Production reference: 1290818
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78862-406-0
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Joseph Ingeno is a software architect who oversees a number of enterprise software applications. During his career, he has designed and developed software for a variety of different industries. He has extensive experience working on web, mobile, and desktop applications using different technologies and frameworks.
Joseph graduated from the University of Miami a with Master of Science and a Bachelor of Business Administration degrees in Computer Information Systems, and followed that with a Master of Software Engineering degree from Brandeis University.
He holds several certifications, including the Microsoft Certified Solutions Developer and the Professional Software Engineering Master Certification from the IEEE Computer Society.
About the reviewers
Gaurav Aroraahas done an MPhil in computer science. He is a Microsoft MVP, a lifetime member ofComputer Society of India(CSI), an advisory member of IndiaMentor, certified as a Scrum trainer/coach, XEN for ITIL-F, and APMG for PRINCE-F and PRINCE-P. He is an open source developer, a contributor to TechNet Wiki, and the founder of Ovatic Systems Private Limited. In his career of over 20 years, he has mentored thousands of students and industry professionals. Apart from that, he's written over 100 white papers for research scholars and various universities across the globe.
Anand B Pillai is a technophile by profession with 20 years' of experience in software development, design, and architecture. Over the years, he has worked with numerous companies in fields ranging from security, search engines, large-scale web portals and big data. He is a founder of the Bangalore Python Users' Group and is the author of Software Architecture with Python (PacktPub, April 2017). Anand is currently a VP of an engineering at the early-stage legal technology startup, Klarity Law. He happily resides with his family in Bangalore, India.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
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
Preface
Modern software systems are complex, and the software architect role is a challenging one. This book was written to help software developers transition into the role of a software architect, and to assist existing software architects to be successful in their role. It helps readers understand how being a software architect is different than being a developer and what it takes to be an effective software architect.
This comprehensive guide to software architecture begins by explaining what software architecture entails, the responsibilities of the software architect position, and what you will be expected to know. Software architects must have technical and non-technical skills, and they must have both breadth and depth of knowledge.
The book progress to covering non-technical topics such as the importance of understanding your organization's business, working in the context of an organization, and gathering requirements for software systems. It then takes a deep dive into technical topics such as software quality attributes, software architecture design, software development best practices, architecture patterns, how to improve performance, and security considerations.
After reading this book, you should have a familiarity with the many topics related to software architecture and understand how to be a software architect. Technologies and practices may change over time, but the book lays a strong foundation on which you can build a successful career as a software architect.
Who this book is for
This book is aimed at senior developers and software architects who want to learn how to be a successful software architect. Readers should be experienced software development professionals who want to advance in their career and become a software architect. It covers a wide range of topics that will help readers learn what it takes to be effective in the software architect role.
What this book covers
Chapter 1, The Meaning of Software Architecture, begins the book by providing a definition of software architecture. The book establishes what makes up a software architecture and the reasons why it is important to a software system. It also details the software architect role, including the responsibilities of software architects and what they are expected to know.
Chapter 2, Software Architecture in an Organization, focuses on software architecture in the context of an organization. It covers the different types of software architect roles and software development methodologies that you may encounter. Non-technical topics such as project management, office politics, and risk management are explained. The development of software product lines and the creation of architectural core assets are also covered.
Chapter 3, Understanding the Domain, discusses the business aspects of being a software architect. It covers topics such as familiarizing yourself with your organization's business, domain-driven design (DDD), and how to effectively elicit requirements for the software system from stakeholders.
Chapter 4, Software Quality Attributes, covers software quality attributes and their importance to a software architecture. Some common software quality attributes are presented, including maintainability, usability, availability, portability, interoperability, and testability.
Chapter 5, Designing Software Architectures, concentrates on the important topic of software architecture design. It details what is involved with architecture design and its importance to a software system. The chapter discusses different approaches to architecture design, the drivers for it, and the design principles that can be leveraged during the process.
The chapter presents the use of various systematic approaches to software architecture design, including attribute-driven design (ADD), Microsoft's technique for architecture and design, the architecture-centric design method (ACDM), and the architecture development method (ADM).
Chapter 6, Software Development Principles and Practices, describes proven software development principles and practices that can be used to build high-quality software systems. Concepts such as loose coupling and high cohesion are covered, as well as principles such as KISS, DRY, information hiding, YAGNI, and the Separation of Concerns (SoC).
The chapter includes a discussion of the SOLID principles, which include the single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion principles. The chapter closes with topics related to helping your team succeed, including unit testing, setting up development environments, pair programming, and reviewing deliverables.
Chapter 7, Software Architecture Patterns, discusses one of the most useful software architecture design concepts. Learning the architecture patterns that are available to you and when to properly apply them is a key skill for software architects. The chapter details a number of software architecture patterns, including layered architecture, event-driven architecture (EDA), Model-View-Controller (MVC), Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Command Query Responsibility Segregation (CQRS), and Service-Oriented Architecture (SOA).
Chapter 8, Architecting Modern Applications, explains the software architecture patterns and paradigms that are used with modern applications deployed to the cloud. After describing a monolithic architecture, the chapter details microservices architecture, serverless architecture, and cloud-native applications.
Chapter 9, Cross-Cutting Concerns, places its focus on functionality that is used in multiple areas of the system. It explains how to handle cross-cutting concerns in your applications. Topics covered include using Dependency Injection (DI), the decorator pattern, and aspect-oriented programming (AOP) to implement cross-cutting concerns. The chapter also provides a look at different cross-cutting concerns, including caching, configuration management, auditing, security, exception management, and logging.
Chapter 10, Performance Considerations, takes a close look at performance. It describes the importance of performance and techniques to improve it. Topics such as server-side caching and database performance are discussed. An examination of web application performance is included in the chapter, including coverage of HTTP caching, compression, minimizing and bundling of resources, HTTP/2, content delivery networks (CDNs), optimizing web fonts, and the critical rendering path.
Chapter 11, Security Considerations, covers the critical topic of software application security. Security concepts such as the confidentiality, integrity, and availability (CIA) triad and threat modeling are presented. The chapter provides readers with various principles and practices for creating software that is secure by design.
Chapter 12, Documenting and Reviewing Software Architectures, places its focus on software architecture documentation and reviewing software architectures. It describes the various uses for software architecture documentation and explains how to use UML to document a software architecture. The chapter discusses various software architecture review methods, including the software architecture analysis method (SAAM), architecture tradeoff analysis method (ATAM), active design review (ADM), and active reviews of intermediate designs (ARID).
Chapter 13, DevOps and Software Architecture, provides coverage of the culture, practices, tools, and culture of DevOps. The chapter explains key DevOps practices such as continuous integration (CI), continuous delivery (CD), and continuous deployment.
Chapter 14, Architecting Legacy Applications, provides readers with an understanding of how to work with legacy applications. The widespread use of legacy applications makes this topic important for software architects. The chapter covers refactoring legacy applications and how to migrate them to the cloud. It discusses modernizing build and deployment processes for legacy applications as well as how to integrate with them.
Chapter 15, The Soft Skills of Software Architects, is all about the soft skills that software architects should possess to be an effective software architect. After describing what soft skills are, the chapter proceeds to topics such as communication, leadership, negotiation, and working with remote resources.
Chapter 16, Evolutionary Architecture, teaches how to design software systems so that they have the ability to adapt to change. It explains that change is inevitable, so software architects should design software architectures that can evolve over time. The chapter explains some of the ways that change can be handled and it introduces the use of fitness functions to ensure that an architecture continues to meet its desired architectural characteristics as it undergoes change.
Chapter 17, Becoming a Better Software Architect, stresses to readers that the process of career development is an ongoing one. After becoming a software architect, one must seek to continuously gain new knowledge and improve their skills. The chapter details ways that a software architect can practice self-improvement, including continuous learning, participating in open source projects, writing your own blog, spending time teaching others, trying new technologies, continuing to write code, attending user groups and conferences, taking responsibility for your work, and attending to your general well-being.
To get the most out of this book
Although readers should have experience of software development, no specific prerequisites are required to begin reading this book. All of the information that you need is contained in the various chapters. The book does not require knowledge of any particular programming language, framework, or tool. The code snippets in the book that illustrate various concepts are written in C#, but they are simple enough that prior C# experience is not necessary.
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here:https://www.packtpub.com/sites/default/files/downloads/SoftwareArchitectsHandbook_ColorImages.pdf.
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
The Meaning of Software Architecture
A comprehensive look at software architecture must first begin with its definition. This chapter provides reasons as to why software architecture plays an important role in a software project, and the benefits of having a good architectural design.
It is also important to understand the stakeholders and team members who are affected by the software architecture of a system. The chapter will go into detail about the software architect's role, what software architects are supposed to know, and whether the role is right for you.
In this chapter, we will cover the following topics:
What is software architecture?
Why is software architecture important?
Who are the consumers of software architectures?
What is the software architect role?
What is software architecture?
What exactly is software architecture? You probably have your own ideas about what it is, based on your knowledge and experiences. Certainly, there are plenty of definitions out there. If you do an online search or ask various friends and colleagues, you will get varying answers. The definition is somewhat subjective and influenced by the viewpoints and perceptions of the individual who is providing the definition. However, there are some core concepts that are essential to software architecture, and before we delve into deeper topics, establishing a common understanding of what software architecture entails is imperative.
Using the word architecture for software originated from similarities with the construction industry. When the term was first used, the Waterfall software development methodology was common and it dictated that large, up-front designs needed to be completed before any code was written. Similar to the architecture of a building, which necessitates a lot of planning before construction takes place, so it was with software as well.
In modern software design, the relationship between the construction and software industries is no longer as close. Software methodologies now focus on developing software applications that are highly adaptable and can be changed easily over time, resulting in less of a need for rigid, upfront planning. However, software architecture still consists of early design decisions that can be difficult to change later.
ISO/IEC/IEEE 42010 standard definition
There is a standard definition for software architecture, which resulted from a joint effort between the International Organization for Standardization (ISO) and the Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 42010 systems and software engineering's architecture description is an international standard that defines software architecture as:
The standard makes the following main points:
A software architecture is a fundamental part of a software system
A software system is situated in an environment, and its software architecture takes into consideration the environment in which it must operate
An architecture description documents the architecture and communicates to stakeholders how the architecture meets the system's needs
Architecture views are created from the architecture description, and each view covers one or more architecture concerns of the stakeholders
What makes up a software architecture?
In the book, Software Architecture in Practice, 2nd Edition, a definition of software architecture is given as:
A software system contains structures, and this definition notes that a software system is made up of one or more of them. It is the combination of these that forms the overall software architecture. A large software project may have multiple teams working on it, each responsible for a particular structure.
Software architecture is an abstraction
Software architecture is an abstraction of a software system. The structures of a software system consist of its elements. Software architecture concerns itself with defining and detailing the structures, their elements, and the relationships of those elements with each other.
Software architecture focuses on the public aspects of the elements, and how they interact with each other. For elements, this may take the form of their public interfaces. It does not deal with the private implementation details of the elements. While the behavior of the elements does not have to be exhaustively documented, care should be taken in understanding how elements have to be designed and written so that they can properly interact with each other.
Software architecture is about the important stuff
Computer scientist Ralph Johnson, who co-authored Design Patterns: Elements of Reusable Object-Oriented Software, once said:
Software projects vary, and the amount of design effort, time, focus, and documentation devoted to particular aspects of a software architecture differ. Ultimately, software architecture consists of important design decisions that shape the system. It is made up of the structures and components that are significant to the quality, longevity, and usefulness of the system.
Software architecture consists of some of the earliest decisions that are made for a software system and some of the hardest to change. In modern software development, the architecture should anticipate change, and be designed in such a way as to maximize the potential of adapting and evolving to this change. We will be discussing evolutionary architecture in Chapter 16, Evolutionary Architecture.
Why is software architecture important?
Why should we care about software architecture anyway? Sometimes a developer just wants to jump right in and start coding.
Software architecture is the foundation of a software system. Like other types of engineering, the foundation has a profound effect on the quality of what is built on top of it. As such, it holds a great deal of importance in terms of the successful development, and eventual maintenance, of the system.
Software architecture is a series of decisions. Some of the earliest decisions come from designing the architecture, and these carry a high degree of importance because they affect the decisions that come after it.
Another reason software architecture is important is because all software systems have an architecture. Even if it comprised just one structure with one element, there is an architecture. There are software systems that don't have a formal design and others that don't formally document the architecture, but even these systems still have an architecture.
The greater the size and complexity of a software system, the more you will need a well thought-out architecture in order to succeed. Software architecture provides a number of benefits when done properly, which greatly increase the chances that the software system will succeed.
A proper foundation laid down by a software system's architecture yields a number of benefits. Let's take a deeper look at those benefits.
Defining a solution to meet requirements
Software strives to meet all functional, non-functional, technical, and operational requirements. Working closely with stakeholders, such as domain experts, business analysts, product owners, and end users, allows requirements to be identified and understood. A software architecture defines a solution that will meet those requirements.
Software architecture is the foundation for software, so software systems that lack a solid architecture make it more difficult to meet all of the requirements. Poor architectures will lead to implementations that fail to meet the measurable goals of quality attributes, and they are typically difficult to maintain, deploy, and manage.
Enabling and inhibiting quality attributes
Software architecture either enables quality attributes or inhibits them. Quality attributes are measurable and testable properties of a system. Some examples of quality attributes include maintainability, interoperability, security, and performance.
They are non-functional requirements of a software system as opposed to its features, which are functional requirements. Quality attributes and how they satisfy the stakeholders of the system are critical, and software architecture plays a large role in ensuring that quality attributes are satisfied. The design of a software architecture can be made to focus on certain quality attributes at the cost of others. Quality attributes may be in conflict with each other. A software architecture, when designed properly, sets out to achieve agreed-upon and validated requirements related to quality attributes.
Giving you the ability to predict software system qualities
When you look at a software architecture and its documentation, you can predict the software system's qualities. Making architecture decisions based on quality attributes makes it easier to fulfill those requirements. You want to start thinking about quality attributes as early as possible in the software development process as it is much more difficult (and costly) to make changes to fulfill them later. By thinking about them up front, and using modeling and analysis techniques, we can ensure that the software architecture can meet its non-functional requirements.
If you are not able to predict if a software system will fulfill quality attributes until it is implemented and tested, then costly and time-consuming rework may be necessary. A software architecture allows you to predict a software system's qualities and avoid costly rework.
Easing communication among stakeholders
Software architecture and its documentation allow you to communicate the software architecture and explain it to others. It can form the basis for discussions related to aspects of the project, such as costs and duration. We will discuss this topic further when we go into detail about software architecture in an organization.
A software architecture is abstract enough that many stakeholders, with little or no guidance, should be able to reason about the software system. Although different stakeholders will have different concerns and priorities in terms of what they want to know about the architecture, providing a common language and architecture design artifacts allows them to understand the software system. It is particularly useful for large, complex systems that would otherwise be too difficult to fully understand. As requirements and other early decisions are made for the software system, a formal software architecture plays an important role and facilitates negotiations and discussions.
Managing change
Changes to a software system are inevitable. The catalyst for change can come from the market, new requirements, changes to business processes, technology advances, and bug fixes, among other things.
Some view software architecture as inhibiting agility and would prefer to just let it emerge without up-front design. However, a good software architecture helps with both implementing and managing changes. Changes fall into one of the following categories:
Limited to a single element
Involve a combination of elements, but do not require any architectural changes
Require an architectural change
Software architecture allows you to manage and understand what it would take to make a particular change. Furthermore, a good architecture reduces complexity so that most of the changes that need to be made can be limited to a single element or just a few elements, without having to make architectural changes.
Providing a reusable model
An established architecture might be used again within an organization for other products in a product line, particularly if the products have similar requirements. We'll discuss an organization's product lines, reuse of architecture, and the benefits in the next chapter. For now, simply recognize that, once a software architecture is completed, documented, understood, and used in a successful implementation, it can be reused.
When code is reused, resources, such as time and money, are saved. More importantly, the quality of software that takes advantage of reuse is increased because the code has already been tested and proven. The increase in quality alone translates to savings in resources.
When a software architecture is reused, it is not just code that is reused. All of the early decisions that shaped the original architecture are leveraged as well. The thought and effort that went into the requirements necessary for the architecture, particularly non-functional requirements, may be applicable to other products. The effort that went into making those decisions does not necessarily have to be repeated. The experience gained from the original architectural design can be leveraged for other software systems.
When a software architecture is reused, it is the architecture itself, and not just the software product, that becomes an asset to the organization.
Imposing implementation constraints
A software architecture introduces constraints on implementation and restricts design choices. This reduces the complexity of a software system and prevents developers from making incorrect decisions.
If the implementation of an element conforms to the designed architecture, then it is abiding by the design decisions made by the architecture. Software architecture, when done properly, enables developers to accomplish their objectives and prevents them from implementing things incorrectly.
Improving cost and effort estimates
Project managers ask questions such as: When is it going to be done? How long is it going to take? How much is it going to cost? They need this type of information to properly plan resources and monitor progress. One of the many duties of a software architect is to assist project management by providing this type of information and assisting with determining the necessary tasks and estimates for those tasks.
The design of the software architecture itself affects what types of task will be necessary for implementation. As a result, work-breakdown of tasks is dependent on the software architecture and the software architect can assist project management with the creation of the tasks.
Two major approaches to project management estimation are as follows:
Top-down approach
: This starts with the final deliverables and goals and breaks them down into smaller packages of work
Bottom-up approach
: This starts with specific tasks first, and groups them together into packages of work
For some projects, a project manager may take a more top-down approach, while developers who are going to be working on specific tasks may take a bottom-up perspective. With the experience and knowledge that most software architects possess, they can potentially assist with either approach. A combination of these approaches, where tasks are looked at from both viewpoints, can lead to the best estimates.
It can be helpful when project managers, the software architect, and the developers work together to provide estimates. The most accurate estimates can be obtained by mutual discussions between team members until a consensus is achieved. Sometimes during the consensus building, someone on the team will provide an insight that others had not previously considered, allowing everyone to rethink their position and possibly revise their estimates.
A software system with accurate requirements that are reflected in the software architecture can avoid costly rework that would be necessary if key requirements were missed. In addition, a well-thought-out architecture reduces complexity, allowing it to be easily reasoned about and understood. Reduced complexity can result in more accurate cost and effort estimates.
Serves as training for team members
The system's architecture and its documentation serve as training for the developers on the team. By learning the various structures and elements of the system, and how they are supposed to interact, they learn the proper way in which the functionality is to be implemented.
A software development team may experience change, such as having new team members join or existing ones leave. The introduction and orientation of new members to a team often takes time. A well-thought-out architecture can make it easier for developers to transition to the team.
The maintenance phase of a software system can be one of the longest and costliest phases of a software project. Like new team members introduced during development, it is common for different developers to work on the system over time, including those introduced to maintain it. Having a solid architecture available to teach and bring aboard new developers can provide an important advantage.
Software architecture is not a silver bullet
The Mythical Man-Month by Frederick P. Brooks is one of the seminal texts in software project management. It contains various essays on software engineering. Although this book was written some time ago, and some of the references are now outdated, it provides thought-provoking advice about software development that is timeless and still applicable today:
Fred Brooks 1986 essay, No Silver Bullet – Essence and Accident in Software Engineering, which is included in the twentieth anniversary edition of the book, begins with this quote. It essentially conveys the idea that there is no silver bullet in software development.
