Agile Software Architecture Workshop

OutlineWhat is software architecture?

Designing software architectures

Communicating architecture

Agile software architecture

Workshop

As juniors, pull together something new.As seniors, practice new solutions and architectures.

As operations, create a deeper understanding and define a common language with our engineers.

This is for us devops team.

Main References

Other Materials

What is software architecture?

Software architecture is basically the structure of your code. How you define the variables to be used and how you group

them in to classes in such a way that your code will be readable to any audience or programmer.

Common Conceptions

It is the overall design of the System or Product we are developing. This does not only include the System Design, meaning the form of the code of the product, but also all the tools and the processes that

will help complete the product or system.

Common Conceptions

Software ArchitectureAs a noun:

Structure, interaction of components, foundations, infrastructure, solutions, eagle’s eye view

Software ArchitectureAs a verb:

Creating a vision and making design decisions

Requirements drive architecture

Software architecture, besides code

https://leanpub.com/software-architecture-for-developers/read

Logging and exception handling

Security; non-repudiation, integrity

SLO

Audit and other regulatory

requirements.

Sociability with other software systems.

Operational requirements

Consistency of structure

VISION

Design choices

It is not big design up front

A 1k-length book on diagrams and articles is really sad.

We can have lightweight architecture for agile teams.

Good architecture enables agility.

The software architect is a leader.

Leads by building consensus, particularly in the form of competing design requirements. It is up to the architect to make good solid

judgement calls.

Kartik Ayyar’s answer in Quora.com

From Simon Brown’s Software Architecture for Developers

Software Architecture as DesignFUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

EXPLORING THE DESIGN SPACE

Big Ball of Mud“… is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle…

These systems show unmistakable signs of unregulated growth, and repeated, expedient repair…

The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition.”

http://www.laputan.org/mud/

Requirements Engineering

Process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

Examples of RequirementsUser requirements:

The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.

System requirements:

On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated.

The system shall automatically generate the report for printing after 17.30 on the last working day of the month.

A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs.

If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit.

Access to all cost reports shall be restricted to authorized users listed on a management access control list

Types of Requirements

FUNCTIONAL REQUIREMENTS

Describe what the system is supposed to do

“Features”, as succinct as a user story, or as specific as a SBI

The system shall do … [give clean/detected, give category, give source]

NON-FUNCTIONAL REQUIREMENTS

Describe what the system is supposed to be

“Qualities” of a system, ex. guarantees SLA of 99.999%, open-source, usable

The system shall be … [99.999% SLA, scalable, releasing monthly]

Examples of Non-Functional Requirements

Performance and Space RequirementsCAN BE SPECIFIED AT THE O-NOTATION (HIGHLY DETAILED)

CAN BE SPECIFIED VIA SLO AND GIGABYTES REQUIRED (JUST RIGHT)

And my personal favorite… Agility

Anticipating future improvements, mitigating risk, creating a feedback loop

But more on that later.

Exploring the design space

The space of possible designs. This is a good design exercise for the team!

Sample exploration

Parallel Messaging

Series Messaging

Distributed Database

Data in Message

MongoDB

MySQL Cluster

Other NoSQL DB

[Agile] Design principles

Reduce coupling

Design for flexibility

Anticipate change

Some architectural patternsMultilayers

Pipe and filters

Message oriented

Microservices

Pipe and FiltersLittle components “decorating” the output one at a time

Swap components and none will be the wiser

http://www.site.uottawa.ca/school/research/lloseng/

MicroservicesDivide into “small”, reliable interfaces and mash together to produce interesting results

“Fail easy, fail fast”

Communicating Design

Understanding design is communicating design.

Focus on the communication of the solution rather than the solution itself

“Sadly, we as an industry has a failure to communicate.” –Simon Brown

Who uses UML?Sketches are good enough, right? Right?

Due to the nature of our team, we don’t actually need to visualize the design to other people. Hence no need for UML.

Although I agree that UML is useful for designing, I think prototyping is a faster design tool.

Moving fast needs fast communication.

(next slides from Simon Brown’s Software Architecture for Developers)

The shopping list

Stormtroopers

Airlines Route

Choose your own adventure

Should have used a whiteboard

Eh?

Good sketches facilitate good discussions.

TitlesShort and meaningful

LinesClear relationships, color coded or

has notes if necessary

LayoutYou can use sticky notes instead.

ColorAdd in legends if needed.

DescriptionAdd in a short description if the

component is sufficiently complex.

CohesionThings that are alike should be seen together, like databases.

C4 DiagramsIt’s typically difficult to show everything in one go.

Overview first, zoom in.

Diagrams are to help the audience navigate.

A software system is made up of containerseach of which contains one or more componentswhich in turn are implemented by one or more classes.

ContextWhat are we building?

Who is it for?

How does it coexist with others in the IT ecosystem?

ContainersWhat are the high level tech decisions?

How do the containers communicate with each other?

Where do the different workgroups work on?

ComponentsWhat are the most important components and how is it done?

Other ITIL-esque processes can then follow

Agile Software Architecture

Agility? Moving fast, embracing change, releasing often, getting feedback.

Unfortunately, not all agile teams build software that is agile.

Observation – Orientation – Decision – Action LoopFaster than the adversary.

http://www.dnipogo.org/fcs/pdf/adolph_2006_agile%20lessons_final.pdf

Good architecture enables agility.

“Base your architecture on requirements, travel light and prove your architecture with concrete experiments.”

- Scott Ambler

Travelling Light – Just enoughTOO LITTLE

No common understanding where the system boundaries are.

Inability to do the elevator pitch.

No thoughts on the non-functional requirements.

No thoughts on the risks involved.

TOO MUCH

Unnecessary detail in long documents

Writing code or pseudo-code.

No flexibility with the design choices.

Analysis paralysis.

Just Enough Architecture

Firm Foundations

StructureUnderstand the different

elements and their relationships based on the requirements.

------------Team discussions

VisionCreate and communicate the

“big picture”-----------------

C4 Diagrams, Use Case diagrams, Entity Diagrams

RisksIdentify and mitigate the biggest

risks.---------------

Risk-storming, documentation and experimentation

RiskConsequences of actions taken in the face of uncertainty.

Time and human resource constraints

Technology choice

Process workflow

Customer satisfaction A risk is a known problem beforehand. Risks should have mitigation plans. If you ignore risks, more likely you’ll encounter lots of problems.

Architecture is not a relay sport.

Architecture evolves.

Somebody should own it, and change it as uncertainties are cleared.

Do experiments and live feedback throughout the project lifetime.

Technical leadership and coaching is needed on all stages of the project.

Discuss what software architecture is.

Include architecture in retrospectives.

Practice.

Architectural Kata30-45 minutes of planning, 10 minutes of presentation

Prove to the others your solution works

Any tech, can make assumptions, no all-star team

Constructive criticisms only!

I am the sales guy

DeliverablesHigh level description and architecture – the elevator pitch

Non-functional requirements and their solutions

Use Case Diagrams and their respective 4C Diagrams (until the components only)◦ (Include the technology choices!)

Soft PBI timelines – dates of feature deliveries

GRID Food NetworkA Philippine restaurant food chain wants to enable orders through the Internet.

Users: millions+, 99.999% SLA (~8 hours, 45 minutes of downtime a year)

Requirements:

Users will place their order, then be given a time to pick up their order and directions to the shop which must integrate with Google Maps;

If the shop offers a delivery service, dispatch the driver with the order to the user;

Mobile-device accessibility;

Occasionally offer national promotionals/specials through Facebook, Twitter and Zomato API;

Daily offers of local promotionals/specials with Foursquare.

Accept payment online or in person/on delivery

Integrate with the company’s customer relationship management (loyalty cards) by sending it all customer data with their orders

Integrate with the company’s supply chain management system by sending it all orders from all branches

ReferencesSoftware Architecture for Developers - https://leanpub.com/software-architecture-for-developers/read

Lecture slides accompanying the book: Object-Oriented Software Engineering: Practical Software Development using UML and Java http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/LlosengCh09E2.ppt

Assorted slides from CS 260, Advanced Software Engineering, in UP Diliman

Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.