$30 off During Our Annual Pro Sale. View Details »

Using Software Architecture Principles in Practice

Eoin Woods
October 20, 2016

Using Software Architecture Principles in Practice

Architects have to balance providing clear guidance for important decisions with the need to let people get on and build their aspects of the system without interference. Eoin Woods explores how architecture principles can help achieve this by making constraints and priorities clear without being unnecessarily prescriptive about how they are to be implemented.

Eoin Woods

October 20, 2016
Tweet

More Decks by Eoin Woods

Other Decks in Technology

Transcript

  1. Using Software
    Architecture Principles
    in Practice
    Eoin Woods - Endava

    @eoinwoodz

    View Slide

  2. BACKGROUND
    • Eoin Woods
    • CTO at Endava (technology services, 3300 people)
    • 10 years in product development - Bull, Sybase, InterTrust
    • 10 years in capital markets applications - UBS and BGI
    • Software engineer, then architect, now CTO
    • Author, editor, speaker, community guy

    View Slide

  3. COMMON CHALLENGES

    View Slide

  4. COMMON CHALLENGES
    • Understanding rationale for architecture & design
    • Maintaining knowledge over time
    • Relating contexts across enterprise / system / code
    • Guiding design without making the decisions
    • Minimal effective documentation

    View Slide

  5. COMMON SOLUTIONS
    • Lots of documentation
    • always out of date
    • “Listen to the code”
    • doesn't contain all of the information
    • Oral history
    • Fragile and easily lost or distorted

    View Slide

  6. UNCOMMON SOLUTIONS
    • Architecture design decisions
    • Architecture principles
    These practices are elegant solutions to capturing and communicating
    architectural knowledge
    Today we’ll talk about principles

    View Slide

  7. ARCHITECTURE PRINCIPLES

    View Slide

  8. ARCHITECTURE PRINCIPLES
    • What is a “principle” ?
    • a fundamental truth or proposition serving as the foundation for belief or action
    [OED]
    • An architecture principle is ….
    • a declarative statement made with the intention of guiding architectural
    design decisions in order to achieve one or more qualities of a system


    View Slide

  9. A (VERY) SIMPLE EXAMPLE
    • Use Tiered Architectures:

    Use application tiers to separate presentation, logic & data.

    Our rationale for this is:
    • data lives longer than applications; business logic lives longer than UIs
    • tiers separate aspects of the system to allow different rates of evolution
    • tiers allow variation of technology and qualities for different parts of systems (e.g. scalable
    servers, secure databases)
    • while more complex initially than two tier systems, this is outweighed by the benefits for
    all but the simplest cases

    View Slide

  10. REQUIREMENTS AND DECISIONS
    • Requirement - the desired system quality
    • normally measurable
    • Principle - a constraint or guide for decisions, reflecting the requirement(s)
    • applicable to a broad context (guides many decisions)
    • Decision - how something is to be achieved
    • bound to a specific narrow context

    View Slide

  11. PRINCIPLES ALIGN TEAMS
    Goal
    Requirement
    Principle
    Decision

    View Slide

  12. PRINCIPLES ALIGNING TEAMS
    Goal: allow product to be sold into regulated industries (unknown regulations)
    Requirement: allow deployment on premise and to “cloud” platforms
    Principles: 

    1. Do not use cloud specific services

    2. Only assume key/value storage for data stores
    Decisions:

    1. Initially deploy to AWS

    2. Do not use unique AWS services (e.g. SQS) 

    3. Use Aerospike for DB accessed via LibStore
    Guidance
    Rationale

    View Slide

  13. PRINCIPLES ALIGNING TEAMS
    Requirement: add new trading partner 2 in weeks, <= 50 days effort
    Principles:
    1. We prefer industry protocols, then standard in-house ones, 

    then ad-hoc point-to-point ones
    2. Partner specific detail must not pollute domain model - 

    where necessary then isolate in specific areas
    Decisions:
    1. Integrate using “Trader” model with partner extensions
    2. Integrate using RPC and pub/sub messaging

    3. For pub/sub use RabbitMQ, RPC use HTTP/JSON REST
    Guidance
    Rationale

    View Slide

  14. ARCHITECTURE PRINCIPLES IN PRACTICE

    View Slide

  15. USEFUL TYPES OF PRINCIPLE
    • Define a goal
    • “single visitor logon for all web sites”
    • Indicate a preference or constraint
    • “prefer 3rd party data formats, over
    in-house, over custom”
    • Avoid a specific technical problem
    • “use tiers to avoid UIs becoming
    bound to databases”
    • Encourage a practice
    • “our software must always be
    deployable at the end of a sprint”
    • Remind people of useful knowledge
    • “abstractions live longer than
    details” [Hunt &Thomas]

    View Slide

  16. DEFINING A PRINCIPLE
    • A good name
    • A clear description
    • A rationale
    • An example
    • and a counter-example
    • Applicability
    • if necessary for clarity
    • Implications
    • if not obvious

    View Slide

  17. ANOTHER EXAMPLE
    Name Prefer Standardised Message Protocols
    Description
    We prefer to use industry protocols for messaging, where this isn’t
    possible we use well defined in-house ones, only in the last resort do
    we use local ad-hoc protocols.
    Rationale
    Minimise concept (re)definition, maximise future integration options,
    allow flexible organisational structure
    Example
    Use FIX if that’s not possible, Equities wide standard transaction
    messages, otherwise, point-to-point ad-hoc fmt
    Applicability All inter-system business transactions across Markets IT
    Implications
    Teams need to understand the options; time needs to be taken to
    understand new protocols if needed

    View Slide

  18. PROPERTIES OF GOOD PRINCIPLES
    Constructive stated for a definite purpose, useful guide for decision making
    Reasoned rational, logical, consistent
    Well Articulated comprehensible by all of the necessary stakeholders
    Testable can check if you’ve followed it and where the exceptions are
    Significant not just a truism; would the opposite ever be the case?
    (Nick Rozanski)

    View Slide

  19. VIOLATING PRINCIPLES
    • Principles can’t always be followed
    • but when broken must be broken for justifiable reasons
    • i.e. benefits have to outweigh the costs
    • This doesn’t (necessarily) reduce their usefulness
    • reason for breaking a principle is valuable design information
    • many violations signal the need to revisit the principle
    • capturing the violation signals a non-standard decision

    View Slide

  20. PRACTICAL COMPLICATIONS
    Identification identifying meaningful principles, avoiding truisms
    Quantity avoiding excessive number (too many authors?)
    Description being clear, complete, succinct & understandable
    Validation difficult to validate and measure the value
    Communicating often difficult to understand & internalise
    Retrofitting difficult to apply principles usefully after the fact

    View Slide

  21. TO CONCLUDE

    View Slide

  22. CONCLUSIONS
    • Principles provide “laws” to guide the design process
    • useful at different levels of scale, help to create informed design decisions
    • Principles can provide traceability
    • link back to more abstract principles, requirements or goals
    • justifies decisions by reference to a particular context
    • Address some common challenges
    • maintain knowledge, capture rationale, provide context, …
    • elegant and minimal solution avoid lots of documents

    View Slide

  23. FINDING OUT MORE
    (Yes - really!)

    View Slide

  24. THANK YOU … QUESTIONS?
    Eoin Woods

    Endava

    [email protected]
    @eoinwoodz

    View Slide