Preface
Software architecture has a bad reputation
Agile aspirations
So you think you’re an architect?
The frustrated architect
About the book
Why did I write the book?
A new approach to software development?
Five things every developer should know about software architecture
About the author
Software architecture training
Acknowledgements
I What is software architecture?
1. What is architecture?
As a noun
As a verb
2. Types of architecture
What do they all have in common?
3. What is software architecture?
Application architecture
System architecture
Software architecture
Enterprise architecture - strategy rather than code
4. Architecture vs design
Making a distinction
Understanding significance
5. Is software architecture important?
A lack of software architecture causes problems
The benefits of software architecture
Does every software project need software architecture?
6. Questions
II The software architecture role
7. The software architecture role
1. Architectural Drivers
2. Designing Software
3. Technical Risks
4. Architecture Evolution
5. Coding
6. Quality Assurance
Collaborate or fail
Technical leadership is a role, not a rank
Create your own definition of the role
8. Should software architects code?
Writing code
Building prototypes, frameworks and foundations
Performing code reviews
Experimenting and keeping up to date
The tension between software architects and employers
You don’t have to give up coding
Don’t code all the time
9. Software architects should be master builders
State of the union
Back in time
Did master builders actually build?
Ivory towers?
Divergence of the master builder role
Achieving the role
Architects need to work with the teams
10. From developer to architect
Experience is a good gauge but you need to look deeper
The line is blurred
Crossing the line is our responsibility
11. Broadening the T
Deep technology skills
Breadth of knowledge
Software architects are generalising specialists
Software architecture is a technical career
12. Soft skills
Stay positive
13. Software development is not a relay sport
“Solution Architects”
Somebody needs to own the big picture
14. Software architecture introduces control?
Provide guidance, strive for consistency
How much control do you need?
Control varies with culture
A lever, not a button
15. Mind the gap
Developers focus on the low-level detail
Architects dictate from their ivory towers
Reducing the gap
A collaborative approach to software architecture
16. Where are the software architects of tomorrow?
Coaching, mentoring and apprenticeships
We’re losing our technical mentors
Software teams need downtime
17. Everybody is an architect, except when they’re not
Everybody is an architect
Except when they’re not
Does agile need architecture?
18. Software architecture as a consultant
Domain knowledge
Authority
19. Questions
III Designing software
20. Architectural drivers
1. Functional requirements
2. Quality Attributes
3. Constraints
4. Principles
Understand their influence
21. Quality Attributes (non-functional requirements)
Which are important to you?
22. Working with non-functional requirements
Capture
Refine
Challenge
23. Constraints
Time and budget constraints
Technology constraints
People constraints
Organisational constraints
Are all constraints bad?
Constraints can be prioritised
Listen to the constraints
24. Principles
Development principles
Architecture principles
Beware of “best practices”
25. Technology is not an implementation detail
1. Do you have complex non-functional requirements?
2. Do you have constraints?
3 Do you want consistency?
Deferral vs decoupling
Every decision has trade-offs
26. More layers = more complexity
Non-functional requirements
Time and budget - nothing is free
27. Collaborative design can help and hinder
Experience influences software design
28. Software architecture is a platform for conversation
Software development isn’t just about delivering features
29. SharePoint projects need software architecture too
1. Many SharePoint implementations aren’t just SharePoint
2. Non-functional requirements still apply to SharePoint solutions
3. SharePoint projects are complex and require technical leadership too
4. SharePoint solutions still need to be documented
Strong leadership and discipline aren’t just for software development projects
30. Questions
IV Communicating design
31. We have a failure to communicate
Abandoning UML
Agility requires good communication
32. The need for sketches
Test driven development vs diagrams
Why should people learn how to sketch?
Sketching isn’t art
Sketches are not comprehensive models
Sketching can be a collaborative activity
33. Ineffective sketches
The shopping list
Boxes and no lines
The “functional view”
The airline route map
Generically true
The “logical view”
Deployment vs execution context
Too many assumptions
Homeless Old C# Object (HOCO)
Choose your own adventure
Stormtroopers
Should have used a whiteboard!
Creating effective sketches
34. C4: context, containers, components and classes
A common set of abstractions
Summarising the static view of your software
Common abstractions over a common notation
Diagrams should be simple and grounded in reality
35. Context diagram
Intent
Structure
Motivation
Audience
Example
36. Container diagram
Intent
Structure
Motivation
Audience
Example
37. Component diagram
Intent
Structure
Motivation
Audience
Example
38. Shneiderman’s mantra
Overview first (context and container diagrams)
Zoom and filter (component diagrams)
Details on demand (class diagrams)
Understanding a large and/or complex software system
39. Technology choices included or omitted?
Drawing diagrams during the design process
Drawing diagrams retrospectively
Architecture diagrams should be “conceptual”
Make technology choices explicit
40. Would you code it that way?
Shared components
Layering strategies
Diagrams should reflect reality
41. Software architecture vs code
Abstraction allows us to reduce detail and manage complexity
We talk about components but write classes
An architecturally-evident coding style
Package by layer
Package by feature
The model-code gap
Packaging by component
Layers are an implementation detail
Aligning software architecture and code
42. Software architecture as code
Auto-generating software architecture diagrams
Why isn’t the architecture in the code?
Auto-generating the software architecture model
Creating a software architecture model as code
Visualising the software architecture model
Software architecture as code opens opportunities
The road ahead
43. You don’t need a UML tool
There are many types of UML tool
The simplest thing that could possibly work
Uses for UML
There is no silver bullet
44. Effective sketches
Titles
Labels
Shapes
Responsibilities
Lines
Colour
Borders
Layout
Orientation
Keys
Diagram review checklist
Listen for questions
45. C4++
Enterprise context
User interface mockups and wireframes
Domain model
Sequence and collaboration diagrams
Business process and workflow models
Infrastructure model
Deployment model
And more
46. C4 - FAQ
System names on context diagrams
Should I use actors or boxes for external systems?
Mixing levels of abstraction
Shared components
Utility components
47. Questions
V Documenting software
48. The code doesn’t tell the whole story
The code doesn’t portray the intent of the design
Supplementary information
49. Software documentation as a guidebook
1. Maps
2. Sights
3. History and culture
4. Practical information
Keep it short, keep it simple
Beware of the “views”
Product vs project documentation
50. Context
Intent
Structure
Motivation
Audience
Required
51. Functional Overview
Intent
Structure
Motivation
Audience
Required
52. Quality Attributes
Intent
Structure
Motivation
Audience
Required
53. Constraints
Intent
Structure
Motivation
Audience
Required
54. Principles
Intent
Structure
Motivation
Audience
Required
55. Software Architecture
Intent
Structure
Motivation
Audience
Required
56. External Interfaces
Intent
Structure
Motivation
Audience
Required
57. Code
Intent
Structure
Motivation
Audience
Required
58. Data
Intent
Structure
Motivation
Audience
Required
59. Infrastructure Architecture
Intent
Structure
Motivation
Audience
Required
60. Deployment
Intent
Structure
Motivation
Audience
Required
61. Operation and Support
Intent
Structure
Motivation
Audience
Required
62. Decision Log
Intent
Structure
Motivation
Audience
Required
63. Questions
VI Agility and the essence of software architecture
64. The conflict between agile and architecture - myth or reality?
Conflict 1: Team structure
Conflict 2: Process and outputs
Software architecture provides boundaries for TDD, BDD, DDD, RDD and clean code
Separating architecture from ivory towers and big up front design
65. Quantifying risk
Probability vs impact
Prioritising risk
66. Risk-storming
Step 1. Draw some architecture diagrams
Step 2. Identify the risks individually
Step 3. Converge the risks on the diagrams
Step 4. Prioritise the risks
Mitigation strategies
When to use risk-storming
Collective ownership
67. Just enough up front design
It comes back to methodology
You need to do “just enough”
How much is “just enough”?
Firm foundations
Contextualising just enough up front design
68. Agility
Understanding “agility”
A good architecture enables agility
Agility as a quality attribute
Creating agile software systems in an agile way
69. Introducing software architecture
Software architecture needs to be accessible
Some practical suggestions
Making change happen
The essence of software architecture
70. Questions
VII Appendix A: Financial Risk System
71. Financial Risk System
Background
Functional Requirements
Non-functional Requirements
VIII Appendix B: Software Guidebook for techtribes.je