Software Architecture for Developers

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