Computer Architecture is still a less well understood discipline within the IT industry. Some still wonder the importance of it and what the benefit of it is. The key to the definition of an architecture are the principles. Here we explore What Is Architecture, What Architectural Styles exist and the 12 Principles of Architecture.

1. Architecture
Fundamentals

2. #event-arch-fund

3. Learning Objectives
How architecture benefits me
How architecture benefits my project
What is architecture
How an architect fits in

4. Agenda
Boring stuff about me
What is Architecture?
Architectural Styles
Principles of Architecture
Case Study

5. Me!
Reda Hmeid
Head of Solutions

6. A bit more about me
Middlesex County Schools u15 Rugby Champion
Middlesex County Schools u15 Rugby Player
British Junior Kickboxing Champion 1992
Leading goalscorer of all time for HH in British Airways 7 a-side
league
Managed 10 press-ups in a row a month ago

7. 1.
What is Architecture?
Just drawing some boxes

8. Your views

9. Some thoughts
Boxes with lines between them in some
sensible manner.
Tex Soh
A clear map of the physical nature of the
system/s with which you are working.
Andrew Bateson

10. “Computer architecture, like other
architecture, is the art of determining the
needs of the user of a structure and then
designing to meet those needs as
effectively as possible within economic
and technological constraints.
Planning a Computer System: Project Stretch, ed. W. Buchholz, 1962

11. “Computer architecture, like other
architecture, is the art of determining the
needs of the user of a structure and then
designing to meet those needs as
effectively as possible within economic
and technological constraints.
Planning a Computer System: Project Stretch, ed. W. Buchholz, 1962

12. “Computer architecture, like other
architecture, is the art of determining the
needs of the user of a structure and then
designing to meet those needs as
effectively as possible within economic
and technological constraints.
Planning a Computer System: Project Stretch, ed. W. Buchholz, 1962

13. “Computer architecture, like other
architecture, is the art of determining the
needs of the user of a structure and then
designing to meet those needs as
effectively as possible within economic
and technological constraints.
Planning a Computer System: Project Stretch, ed. W. Buchholz, 1962

14. “Computer architecture, like other
architecture, is the art of determining the
needs of the user of a structure and then
designing to meet those needs as
effectively as possible within economic
and technological constraints.
Planning a Computer System: Project Stretch, ed. W. Buchholz, 1962

15. “Software architecture defines the
components of a system; what they
do, what they are, and how they
interact (i.e. their interfaces).
David Slauson 2016 (Facebook)

16. “Software architecture defines the
components of a system; what they
do, what they are, and how they
interact (i.e. their interfaces).
David Slauson 2016 (Facebook)

17. “Software architecture defines the
components of a system; what they
do, what they are, and how they
interact (i.e. their interfaces).
David Slauson 2016 (Facebook)

18. “Software architecture defines the
components of a system; what they
do, what they are, and how they
interact (i.e. their interfaces).
David Slauson 2016 (Facebook)

19. Difference between Architecture and Design
Architecture Design
Customer
Microservice
Customer Microservice
Customer
Controller Customer
Connector
Customer Utils
Self Assessment
Microservice
Customer
Database

20. 2.
Architectural Styles

21. “Architecture patterns (ed: or
Styles) help define the basic
characteristics and behavior of
an application.
Software Architecture Patterns, Mark Richards

22. Layered/Tiered
Front End Layer
Business Layer
Data Layer
UtilityLayer
DomainLayer

23. Layered/Tiered
Front End Layer
Business Layer
Data Layer
UtilityLayer
DomainLayer
Process Layer

24. SOAMicroservices
Process Services
ESB
Business Services
Data Services
Service Based Architectures

25. Comparison
Microservices
1. Choreography
2. Own DB
3. Domain driven
4. Full Stack Teams
5. Self contained
6. Polyglot
7. Usually REST (or REST-like)
8. Less Coupled
SOA
1. Orchestration
2. Shared DB
3. BPM Driven
4. Factories
5. Separately deployable
6. Technology limited
7. Usually SOAP (over HTTP or JMS)
8. More Coupled

26. REST
Described by Roy Fielding in his 2000 thesis.
“REST is defined by four interface constraints: identification of
resources; manipulation of resources through representations; self-
descriptive messages; and, hypermedia as the engine of application
state”

27. Other Architectural Styles
Event-Driven Architectures
Microkernel Architectures
Space Based Architectures

28. 3.
Principles of Architecture

29. 12 Principles of Architecture
1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel

30. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
An architecture that is not based on
achieving business goals is not a good
architecture. Not matter how “pure” it is.
12 Principles of Architecture

31. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Technical, people, infrastructure, financial,
requirements
12 Principles of Architecture

32. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Deliver an architecture to fulfill the
requirements - no more. If a response
time of 2 seconds is ok, deliver an
architecture for a 2 seconds response
time.
12 Principles of Architecture

33. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Fail to prepare, prepare to fail.
12 Principles of Architecture

34. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Complexity is a measurement of the
number of components within a system,
the number of interactions between those
components and what those interactions
look like.
Greater the complexity, the greater the
development effort, the testing effort, the
maintenance effort and support effort. It
increases the potential number of points
failure and the number of bugs.
Some architectural styles are inherently
more complex.
12 Principles of Architecture

35. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Architectural decisions that increase
complexity must be based on evidence:
Metrics
User Research
Expert Opinion
Technology Characteristics
Product Owner opinion
12 Principles of Architecture

36. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
“Each software module should have one
and only one reason to change”
12 Principles of Architecture

37. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
The reusability of a component is not
measured by whether or not it has been
reused, but by whether it could be reused.
Reusability is the ability of multiple clients
to reuse the same functionality.
12 Principles of Architecture

38. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Resume Driven Architecture - the
inappropriate use of a technology to
boost one’s resume.
12 Principles of Architecture

39. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Coupling components makes change
more difficult and less likely.
Some types of coupling:
External Data Structure
Data Format
Control
Common or module coupling
12 Principles of Architecture

40. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Abstraction is the hiding of
implementation details from client
systems or components.
This is usually through well defined
interfaces and components
BEWARE: Do not overdo the abstraction
12 Principles of Architecture

41. 1. Achieve business goals
2. Constraints are King
3. Just enough is always plenty
4. Architect for Change
5. Minimise Complexity
6. Evidence Based
7. Single Responsibility Principle
8. Reusable components
9. Avoid RDA
10. Loose Coupling
11. Abstraction
12. Don’t reinvent the wheel
Use established technologies, whether
internal or 3rd party where reasonably
possible.
Use the 80/20 rule
12 Principles of Architecture

42. Case Study

43. Business Goals
Increase Customer Satisfaction through greater understanding
Increase Revenue

44. Business Requirements
Use real-time analytics to understand our customer better to make an
informed suggestion on Next Best Action.

45. Constraints
Java developers
Most development by 3rd party suppliers
2 seconds end-to-end response times
6 month initial delivery

46. Existing Architecture
Offline analysis through modelling produces customer and business
related values
These are fed in from the data warehouse using ETL daily and
stored in an Oracle Database
A customer component used to retrieve any and all customer
related data
A provided equation (I want to say regression equation) is used in
real time, taking in the request and customer and business related
values to produce an answer
The web uses the “decisions” to display the appropriate content

47. Next Phase
A real time decisioning engine has been procured, that will make use of
existing data to suggest next best actions. This has been procured on a
1 year trial basis.

48. Go

49. Upcoming talks

50. Rest Architectural Style
Microservices Architecture
Communicating Architecture
Web Security Fundamentals & Advanced
Strategic Domain Driven Design
Machine Learning
Intro to Git

51. Homework

52. Single Responsibility Principle - https://blog.8thlight.com/uncle-
bob/2014/05/08/SingleReponsibilityPrinciple.html
Software Architecture Patterns - http://www.oreilly.
com/programming/free/files/software-architecture-patterns.pdf
Who needs an architect? - http://martinfowler.
com/ieeeSoftware/whoNeedsArchitect.pdf
Building Microservices - Sam Newman
Architectural Styles and the design of network based software
architecture (Roy Fielding) - https://www.ics.uci.
edu/~fielding/pubs/dissertation/top.htm

53. https://confluence.tools.tax.service.gov.
uk/display/AR/Courses

54. thanks!
Any questions?