Architecture
Fundamentals
#event-arch-fund
Learning Objectives
� How architecture benefits me� How architecture benefits my project� What is architecture� How an architect fits in
Agenda
� Boring stuff about me� What is Architecture?� Architectural Styles� Principles of Architecture� Case Study
Me!
Reda HmeidHead of Solutions
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
1.
What is Architecture?
Just drawing some boxes
Your views
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
“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
“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
“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
“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
“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
“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)
“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)
“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)
“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)
Difference between Architecture and Design
Architecture Design
Customer Microservice
Customer Microservice
Customer Controller Customer
Connector
Customer UtilsSelf Assessment
Microservice
Customer Database
2.
Architectural Styles
“Architecture patterns (ed: or Styles) help define the basic
characteristics and behavior of an application.
Software Architecture Patterns, Mark Richards
Layered/Tiered
Front End Layer
Business Layer
Data Layer
Util
ity La
yer
Dom
ain
La
yer
Layered/Tiered
Front End Layer
Business Layer
Data Layer
Util
ity La
yer
Dom
ain
La
yer
Process Layer
SOAMicroservicesProcess Services
ESB
Business Services
Data Services
Service Based Architectures
Comparison
Microservices
1. Choreography2. Own DB3. Domain driven4. Full Stack Teams5. Self contained6. Polyglot7. Usually REST (or REST-like)8. Less Coupled
SOA
1. Orchestration2. Shared DB3. BPM Driven4. Factories5. Separately deployable6. Technology limited7. Usually SOAP (over HTTP or JMS)8. More Coupled
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”
Other Architectural Styles
� Event-Driven Architectures� Microkernel Architectures� Space Based Architectures
3.
Principles of Architecture
12 Principles of Architecture
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. Abstraction
12. Don’t reinvent the wheel
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. Abstraction
12. Don’t reinvent the wheel
Technical, people, infrastructure, financial, requirements
12 Principles of Architecture
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. Abstraction
12. Don’t reinvent the wheel
Fail to prepare, prepare to fail.
12 Principles of Architecture
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. Abstraction
12. Don’t reinvent the wheel
“Each software module should have one and only one reason to change”
12 Principles of Architecture
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
1. Achieve business goals2. Constraints are King3. Just enough is always plenty4. Architect for Change5. Minimise Complexity6. Evidence Based7. Single Responsibility Principle8. Reusable components9. Avoid RDA
10. Loose Coupling11. 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
Case Study
Business Goals
Increase Customer Satisfaction through greater understandingIncrease Revenue
Business Requirements
Use real-time analytics to understand our customer better to make an informed suggestion on Next Best Action.
Constraints
� Java developers� Most development by 3rd party suppliers� 2 seconds end-to-end response times� 6 month initial delivery
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
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.
Go
Upcoming talks
� Rest Architectural Style� Microservices Architecture� Communicating Architecture� Web Security Fundamentals & Advanced� Strategic Domain Driven Design� Machine Learning� Intro to Git
Homework
� 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
https://confluence.tools.tax.service.gov.
uk/display/AR/Courses
thanks!
Any questions?