About the Book
This book is a practical, pragmatic and lightweight guide to software architecture, specifically aimed at developers, and focussed around the software architecture role and process.
If you're looking for the C4 model, this has been moved to Software Architecture for Developers: Volume 2 - Visualise, document and explore your software architecture.
Read more Read less
Table of Contents
- 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?
- About the author
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
- 1. What is architecture?
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
- 19. Questions
- 7. The software architecture role
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
- Time and budget constraints
- Technology constraints
- People constraints
- Organisational constraints
- Are all constraints bad?
- Constraints can be prioritised
- Listen to the constraints
- 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. Questions
- 20. Architectural drivers
IV Agility and the essence of software architecture
30. 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
31. Quantifying risk
- Probability vs impact
- Prioritising risk
- 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
33. 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
- Understanding “agility”
- A good architecture enables agility
- Agility as a quality attribute
35. Introducing software architecture
- Software architecture needs to be accessible
- Some practical suggestions
- Making change happen
- The essence of software architecture
- 36. Questions
37. Appendix A: Financial Risk System
- Functional Requirements
- Non-functional Requirements
- 30. The conflict between agile and architecture - myth or reality?
Read More Read Less