Bundles
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
-
Feedback
Share this book
Copy embed codeTable of Contents
-
-
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?
- About the author
- Acknowledgements
-
Preface
-
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
- Authority
- 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
- 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. 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
-
32. 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
-
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
-
34. Agility
- 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
- Background
- Functional Requirements
- Non-functional Requirements
-
30. The conflict between agile and architecture - myth or reality?
Read More Read Less
About the Author
Simon Brown
Simon lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, specialising in software architecture and its role in modern software development teams. Simon is an award-winning speaker on the topic of software architecture and has provided consulting/training to software teams in over 20 countries, ranging from small startups through to global blue chip companies. He is the founder of Coding the Architecture, which is a website for hands-on software architects. He still codes too.
Websites: http://www.simonbrown.je and Coding the Architecture
Read more Read less