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

  • $40.00

    Regular Price

  • $45.00

    Suggested

2 Books

Learn more
Software Architecture for Developers
Project Management for IT People

Software architecture and IT project management

  • $40.00

    Regular Price

  • $30.00

    Suggested

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

A developer-friendly guide to software architecture, technical leadership and the balance with agility

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."

Five things every developer should know about software architecture

1. Software architecture isn't about big design up front

Software architecture has traditionally been associated with big design up front and waterfall-style projects, where a team would ensure that every last element of the software design was considered before any code was written. Software architecture is basically about the high-level structure of a software system and how you get to an understanding of it. This is about the significant decisions that influence the shape of a software system rather than understanding how long every column in the database should be.

2. Every software team needs to consider software architecture

Regardless of the size and complexity of the resulting product, every software team needs to consider software architecture. Why? Put simply, bad things tend to happen if they don't! If software architecture is about structure and vision, not thinking about this tends to lead to poorly structured, internally inconsistent software systems that are hard to understand, hard to maintain and potentially don't satisfy one or more of the important non-functional requirements such as performance, scalability or security. Explicitly thinking about software architecture provides you with a way to introduce technical leadership and stacks the odds of a successful delivery in your favour.

3. The software architecture role is about coding, coaching and collaboration

The image that many people have of software architects is of traditional "ivory tower" software architects dictating instructions to an unsuspecting development team. It doesn't need to be like this though, with modern software architects preferring an approach that favours coding, coaching and collaborative design. The software architecture role doesn't necessarily need to be undertaken by a single person plus coding is a great way to understand whether the resulting architecture is actually going to work.

4. You don't need to use UML

Again, traditional views of software architecture often conjure up images of huge UML (Unified Modeling Language) models that attempt to capture every last drop of detail. While creating and communicating a common vision is important, you don't need to use UML. In fact, you could argue that UML isn't a great method for communicating software architecture anyway. If you keep a few simple guidelines in mind, lightweight "boxes and lines" style sketches are an effective way to communicate software architecture.

5. A good software architecture enables agility

There's a common misconception that "architecture" and "agile" are competing forces, there being a conflict between them. This simply isn't the case though. On the contrary, a good software architecture enables agility, helping you embrace and implement change. Good software architectures aren't created by themselves though, and some conscious effort is needed.

Bitcoin?

Want to buy the book with Bitcoin? No problem, just e-mail me.

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