Architecture fundamentals
3 likes977 views
The document outlines the fundamentals of architecture, highlighting its importance in meeting user needs and detailing various architectural styles, such as microservices and event-driven architectures. It also presents 12 principles of architecture aimed at achieving business goals while minimizing complexity and promoting reusability. Additionally, it includes a case study demonstrating the application of architectural principles to enhance customer satisfaction and revenue through real-time analytics.
Architecture fundamentals
- 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
- 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
- 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