Slide 1

Slide 1 text

Using Software Architecture Principles in Practice Eoin Woods - Endava
 @eoinwoodz

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

COMMON CHALLENGES

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

ARCHITECTURE PRINCIPLES

Slide 8

Slide 8 text

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


Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

PRINCIPLES ALIGN TEAMS Goal Requirement Principle Decision

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

ARCHITECTURE PRINCIPLES IN PRACTICE

Slide 15

Slide 15 text

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]

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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)

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

TO CONCLUDE

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

FINDING OUT MORE (Yes - really!)

Slide 24

Slide 24 text

THANK YOU … QUESTIONS? Eoin Woods
 Endava
 [email protected] @eoinwoodz