CTO Meetup, August 2016

1. s
mPsychology GmbH
Jonathan Holloway Co-Founder I CTO
CTO Meetup
The Role of The Architect

2. s
Welcome….

3. s
Tonight
1
Few points in the presentation where would like some feedback
Questions - At the end please : ) or maybe at the end of each section…

4. s
Some caveats
Architecture is contentious - various perspectives
Basis for presentation is on:
• TOGAF architecture framework training/certification
• Company based experience - over one or two companies
• Based on various books (will list at the end):
• Ambler - agile modelling
• Brown - architecture for software developers

5. s
Architecture - Scope
Role of the Architect Solution Mapping
Technical Architecture
Non Functional
Requirements

6. s
Before I Start…
Just a quick survey, straw person poll
How many people here code?
How many people are involved in an architectural role?

7. s
Role of the Architect

8. s
What does an architect do?
It depends…
Let’s look at some common architecture definitions
1 2 3 4 5

9. s
Architecture Definitions
Enterprise Architecture - huh?
Map business drivers and strategy onto projects, optimise processes etc..
Solutions Architecture
Business analysis, plan to a component level
Technical Architecture
Design of components, how they interact (with the solutions architect)
1 2 3 4 5

10. s
What does an architect do?
Role taken up by someone in a team? < I like this one
Understand the architectural drivers, design a technical strategy
Understand things which are costly to change
Understand how things evolve and how difficult that is
Know how to map between what’s there today and a target architecture
Understand the bigger picture
Communicate
Mitigate risks on a project
1 2 3 4 5

11. s
Where does an architect fit on a project?
1. Product Owner - what
2. Architect Owner - how
3. Project Manager - when
A conversation and negotiation between all three on a project is important
1 2 3 4 5

12. s
We use productboard.com currently to plan:
• Feature Development and Release Management
• Roadmap - visual generation of a roadmap (no more powerpoints)
That covers the functional side, how do we cover the other aspects?
• Design the framework into which the features fit
• Maybe the feature doesn’t fit yet
As an architect define how your system will evolve
1 2 3 4 5

13. s
Do you end up with a consistent structure that people agree on?
Do features get implemented in the same way?
What is the impact to software quality?
Are the non-functionals well understood?
Are people communicating?
Is there governance around what to do technically?
What happens if you don’t have the architect role?
1 2 3 4 5

14. s
Architecture Frameworks
There are frameworks that aim to map business drivers onto technology
implementation at various different levels
TOGAF, Zachman provide enterprise architecture guidance
Overkill? For most projects - probably. Good principles.
Lightweight frameworks also available (e..g LEAF)
But these do not describe technical architecture
or how to run the project
1 2 3 4 5

15. s
Architect Anti Patterns
Some anti-patterns
The Ivory Tower/Seagull Architect
• No coding experience or detached from system
• Draw a diagram and throw it over the wall
Technical Architect/Developer Forever
• Just code, don’t communicate, everybody else is wrong : )
There has to be a balance between design and code
1 2 3 4 5

16. s
Solutions, Modelling and Stuff

17. s
Mapping High Level Solutions
Knowing how to map a problem onto a high level solution,
There are some important architectural aspects to consider:
• Infrastructure - Hosted, Cloud, Hybrid
• Platform - Monolith, Microservice (Big difference)
• Architectural Style - Pipes and Filters, Transaction Script, Domain Driven
• Application Packaging - application, infrastructure, util
• Naming Conventions - so so important, should match
1 2 3 4 5

18. s
Views
Architecture is about viewpoints
1 2 3 4 5

19. s
BDAT (Split the Architecture into Views)
1 2 3 4 5

20. s
Models
Models help to express the architecture
e.g. User Experience - personas, wireframes and usability testing
Models that are relatively little effort to update are good
e.g. Swagger/Open API specification provides a specification that you can
generate code from.
1 2 3 4 5

21. s
How Much Do I Model?
Produce models only when you need them
Bare minimum for requirements - just enough
No Design vs Agile Design vs Big Up Front Design
Agile Modelling provides a good set of principles to follow
1 2 3 4 5

22. s
Agile Modelling - Primer
1 2 3 4 5

23. s
What Do You Want to Convey?
What Diagrams?
• Context Diagram - explains concepts and the bigger picture
• Deployment Diagram - explains main components, how they fit together
• Component Diagram - useful to describe the innards of your application
Use them to form a strawman architecture for people to critique
Quick survey: What other types of diagram do you find really useful?
e.g. State Diagram
1 2 3 4 5

24. s
Example 1 - Context Diagram
1 2 3 4 5

25. s
Example 2 - Deployment Diagram
1 2 3 4 5

26. s
Example 3 - Component Diagram
1 2 3 4 5

27. s
Models are good, but we need more context
Grounded in some sort of design
Linked to our user stories
Providing the how to the what
1 2 3 4 5

28. s
What goes in a design doc/software guidebook?
Lots of Confusion Here
What problem are your solving?
Terminology - define acronyms
Risks
Deployment and Ops Concerns
Components
Use Cases
Interfaces/API’s - Internal and External
Item Overview
Design Diagram
Collaborators
System Qualities
Test Harnesses (if required)
1 2 3 4 5

29. s
How do you represent your design?
Few options:
• Github Wiki - link to tickets and user stories
• Confluence - keep design and requirements together
• Google Docs?
Any other solutions that people want to share?
1 2 3 4 5

30. s
Technical Architecture

31. s
Technical Architecture
Some items that come up in technical architecture include:
• Architectural Styles - what they are, some reading points…
• Architecture Anti-Patterns - knowing what to avoid…
• Technology Selection - how to do it or what happens when somebody
has an idea?
1 2 3 4 5

32. s
Architectural Styles
Know some basic architectural styles, three important ones:
Transaction Script (Fowler) - services that build DTO’s call DAO’s
Domain Driven (Evans) - operations and data together
Pipes and Filters (Fowler) - set of processing steps
Patterns of enterprise application architecture is decent
1 2 3 4 5

33. s
Some Examples
• Big Ball of Mud
• Speculative Generality and Useless Abstractions
• Efferent and Afferent Coupling
• Single Responsibility Principle and SOLID principles
Great Resource
Source Making
Architecture Anti Patterns
1 2 3 4 5

34. s
Technology Selection
What are your dev team familiar with language wise?
How widely is the library/framework being proposed used?
Is it under active development - Github stars, number of commits
How much training/learning/time is involved to upskill the team?
Don’t just agree, spike/build prototype and get to know what you’re about
to adopt
Ohloh/Openhub.net is decent for research
1 2 3 4 5

35. s
Technology Selection
1 2 3 4 5

36. s
Non Functional Requirements
1 2 3 4 5

37. s
Non Functional Requirements
Why are they important?
Define the qualities you want your system to have,
• Performance, usability, robustness, security
• How do people know if you don’t specify them?
It was meant to support 1000 users concurrently with one action?
Lots of projects #fail due to mis-understanding of these or non
1 2 3 4 5

38. s
Non Functional Requirements
Various models
FURPS+
• Came from HP
ISO 25010
• Defines a product quality model based on eight characteristics
1 2 3 4 5

39. s
Testing NFR’s
If you don’t specify - you don’t get
Non functional requirements are good to specify
Test engineers/QA’s have hooks to test the system for
Can ask developers how it meets those requirements
• Chaos Monkey - simulate failure
• Performance Tests - measure RPS using JMeter/Locust/BlazeMeter
• Can work with devops engineers on this or ideally do it themselves
1 2 3 4 5

40. s
Resources

41. s
Market
Questions?