Software Architecture for Developers cover page
Software Architecture for Developers

Software Architecture for Developers

Technical leadership by coding, coaching, collaboration, architecture sketching and just enough up front design


A developer-friendly, practical and pragmatic guide to lightweight software architecture, technical leadership and the balance with agility.
  • $17.50

    Minimum

  • $25.00

    Suggested

Bundles

Software Architecture for Developers
Working with Legacy Systems

Software architecture, for systems old and new

  • $27.50

    Regular Price

  • $27.50

    Bundle Price

2 Books

Learn more
Software Architecture for Developers
Project Management for IT People

Software architecture and IT project management

  • $27.50

    Regular Price

  • $25.00

    Bundle Price

2 Books

Learn more

Packages

The Book

  • PDF

  • EPUB

  • MOBI

  • $17.50

    Minimum

  • $25.00

    Suggested

The Book - 10 copy license

A discounted edition of the book for up to 10 readers.

  • PDF

  • EPUB

  • MOBI

  • $150.00

    Suggested

About the Book

This book is a practical and pragmatic guide to lightweight software architecture for developers. You'll learn:

  • The essence of software architecture.
  • Why the software architecture role should include coding, coaching and collaboration.
  • The things that you *really* need to think about before coding.
  • How to visualise your software architecture using simple sketches.
  • A lightweight approach to documenting your software.
  • Why there is *no* conflict between agile and architecture.
  • What "just enough" up front design means.
  • How to identify risks with risk-storming.

JavaRanch awarded the book 10/10 - "Highly recommended reading."

Please note: this is not a book about technology, design patterns, architectural styles, etc.

Read More

Table 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?
      • 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

Read More

About the Author

The Leanpub Unconditional, No Risk, 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks. We process the refunds manually, so they may take a few days to show up.
See full terms