├── .editorconfig ├── .gitignore ├── README.md ├── images ├── architect_skills_blockbuster.png ├── architecture_quote_1.png ├── books │ ├── accelerate.jpg │ ├── c4_model.png │ ├── fundamentals_of_software_architecture.jpeg │ ├── just_enough_architecture.jpg │ ├── the_pragmatic_programmer.jpg │ └── the_software_architect_elevator.jpeg ├── enterprise-vs-technical.png ├── senior-vs-lead.png ├── structurizr.jpg ├── structurizr_workspace.jpg ├── unicorn-project.png ├── visualising_architecture.jpg └── why_do_we_need_architecture.png ├── learning_paths ├── README.md ├── continuous_behaviours.md ├── expectations_of_an_architect.md ├── getting_started.md ├── introducing_the_principles.md ├── introduction_to_software_architecture.md ├── skills_of_an_architect.md ├── software │ ├── README.md │ ├── code_design_principles.md │ ├── monoliths_vs_microservices.md │ ├── responsive_architecture_approaches.md │ └── software_architecture_principles.md ├── the_digital_architect.md ├── the_role_of_an_architect.md ├── visualising_architecture.md ├── visualising_architecture │ ├── 1_why_visualise.md │ ├── 2_c4_model.md │ └── 3_structurizr.md └── why_do_we_need_architecture.md ├── playbooks └── architecture-part-1.md ├── principles.md ├── principles ├── communicate_into_the_future.md ├── continually_visualise_the_technical_architecture.md ├── keep_documentation_close_to_code.md └── tools.md └── resources.md /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | charset = utf-8 5 | end_of_line = lf 6 | trim_trailing_whitespace = true 7 | insert_final_newline = true 8 | 9 | [{.,}*.{js{,*},y{a,}ml}] 10 | indent_style = space 11 | indent_size = 2 12 | 13 | [*.{md,txt}] 14 | indent_style = space 15 | indent_size = 2 16 | trim_trailing_whitespace = false 17 | 18 | [Makefile] 19 | indent_style = tab 20 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .vscode 2 | *.DS_Store 3 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Architecture Handbook 2 | ## 🏫 Learning Paths 3 | - [Introduction to Software Architecture](learning_paths/introduction_to_software_architecture.md) 4 | - [Visualising Architecture for Developers](learning_paths/visualising_architecture/1_why_visualise.md) 5 | 6 | ## 🗣️ Architecture COP talks (Made Tech internal only videos and decks) 7 | - [Architecture Discovery Playback Deck](https://docs.google.com/presentation/d/18MlrVItk6v-j92kSlDHtoE-NOpe7qwq7Ow_TIm6auDI/edit?usp=sharing) 8 | - [05/07/2022 - Architecture Function Discovery Show and Tell](https://drive.google.com/file/d/1Qk7DCHTXl_kxSt75-cjXpx6T0aYeuwSo/view?usp=sharing) 9 | - [22/11/2022 - Visualising Architecture with the C4 model](https://docs.google.com/presentation/d/1wXXkyTgoNJIgyD9MDuIlvi85uGHWjIgQhvOPKTNsrHo/edit?usp=sharing) 10 | - [28/03/2023 - Intro to Architecture Learning Paths Show and tell](https://drive.google.com/file/d/1vLe46uk2GHBQvl8khTwDhmXAZ7nw51wb/view?usp=drive_link) 11 | - [01/08/2023 - Structurizr: Software architecture models as code](https://drive.google.com/file/d/1K0jJHByLXzPSaO8f0ZCwHc4n7Ffy3Hrq/view) 12 | - [08/08/2023 - Hexagonal, Onion to Clean architecture and back](https://drive.google.com/file/d/1z2cpyb_sYOHj8Kq4ZAnaLts0aVwr9TvM/view) 13 | 14 | ## Made Tech Community 15 | 16 | - **#cop-architecture** - A place to get advice, find learning material, tools and track architecture news 17 | - **#guild-systems-design** - A regular discussion group around solving real world problems 18 | 19 | ## 📚 Playbooks 20 | For Technical Leaders and Architects in Role 21 | 22 | - [Playbook Part 1 - Holistic Thinking](https://docs.google.com/presentation/d/1RwBxzT37oZNXWZzJBgZ9e-IzXfYOlf7FnGIPdjEZV-Q/edit?usp=sharing) 23 | - [Trello Template](https://trello.com/b/YIcVgWde/architecture-playbook-template) for the playbook 24 | 25 | ## 🌐 Our Blogs 26 | - [Is your technical architecture driving the right outcomes](https://www.madetech.com/blog/is-your-technical-architecture-driving-the-right-outcomes/?utm_content=305104948&utm_medium=social&utm_source=linkedin&hss_channel=lcp-276725) 27 | - [AWS Well Architected](https://www.madetech.com/blog/aws-well-architected/) 28 | - [Why software projects get messy](https://www.madetech.com/blog/messy-software-projects/) 29 | 30 | ## 🌐 Learning Resources 31 | - [A catalogue](resources.md) of our recommended learning material 32 | - [📚 Books](resources.md#books) 33 | - [📺 Videos](resources.md#videos) 34 | - [🌐 Web](resources.md#web) 35 | - [💁 People](resources.md#people) 36 | 37 | ## ⚒️ Principles, Processes, Standards and Tools 38 | - [Principles](principles.md) that we have observed teams using to be successful 39 | - [Tools](principles/tools.md) that we find useful 40 | - [Interactive Skills Radar](https://madetech.github.io/skills-radar/) which you can use to gauge your architecture skills 41 | - [Internal Tech Radar](https://miro.com/app/board/uXjVI3qqUr8=/?share_link_id=724709993521) 42 | -------------------------------------------------------------------------------- /images/architect_skills_blockbuster.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/architect_skills_blockbuster.png -------------------------------------------------------------------------------- /images/architecture_quote_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/architecture_quote_1.png -------------------------------------------------------------------------------- /images/books/accelerate.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/books/accelerate.jpg -------------------------------------------------------------------------------- /images/books/c4_model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/books/c4_model.png -------------------------------------------------------------------------------- /images/books/fundamentals_of_software_architecture.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/books/fundamentals_of_software_architecture.jpeg -------------------------------------------------------------------------------- /images/books/just_enough_architecture.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/books/just_enough_architecture.jpg -------------------------------------------------------------------------------- /images/books/the_pragmatic_programmer.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/books/the_pragmatic_programmer.jpg -------------------------------------------------------------------------------- /images/books/the_software_architect_elevator.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/books/the_software_architect_elevator.jpeg -------------------------------------------------------------------------------- /images/enterprise-vs-technical.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/enterprise-vs-technical.png -------------------------------------------------------------------------------- /images/senior-vs-lead.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/senior-vs-lead.png -------------------------------------------------------------------------------- /images/structurizr.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/structurizr.jpg -------------------------------------------------------------------------------- /images/structurizr_workspace.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/structurizr_workspace.jpg -------------------------------------------------------------------------------- /images/unicorn-project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/unicorn-project.png -------------------------------------------------------------------------------- /images/visualising_architecture.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/visualising_architecture.jpg -------------------------------------------------------------------------------- /images/why_do_we_need_architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/madetech/architecture-handbook/f5f842a2da587d5cccd22c42f4cc20afdbd2ac39/images/why_do_we_need_architecture.png -------------------------------------------------------------------------------- /learning_paths/README.md: -------------------------------------------------------------------------------- 1 | # Learning Materials 2 | 3 | 1. [Introduction to software architecture](introduction_to_software_architecture.md) 4 | 2. [Why do we need architecture?](why_do_we_need_architecture.md) 5 | 3. [The role of an architect](the_role_of_an_architect.md) 6 | 4. [The digital architect](the_digital_architect.md) 7 | 5. [Expectations of an architect](expectations_of_an_architect.md) 8 | 6. [Skills of an architect](skills_of_an_architect.md) 9 | 7. [Getting started](getting_started.md) 10 | 8. [Introducing the principles](introducing_the_principles.md) 11 | -------------------------------------------------------------------------------- /learning_paths/continuous_behaviours.md: -------------------------------------------------------------------------------- 1 | [< Back](./introducing_the_principles.md) 2 | 3 | # Day to day Behaviours 4 | 5 | ## Continually visualise the technical architecture 6 | 7 | [Read more here](../principles/continually_visualise_the_technical_architecture.md) 8 | 9 | ## Keeping documentation close to code 10 | 11 | [Read more here](../principles/keep_documentation_close_to_code.md) 12 | 13 | ## Identifying 'non' requirements 14 | 15 | Quality Attributes or Non Functional Requirements need to be considered and balanced as they are normally a trade off, examples could be: 16 | 17 | - Performance 18 | - Interoperability 19 | - Deployability 20 | - Reliability 21 | - Availability 22 | - Security 23 | - Maintainability 24 | - Observability 25 | - Testability 26 | - Scaleability 27 | - Modifiability 28 | - Reusability 29 | - Audibility 30 | 31 | ## Managing risk 32 | 33 | [Risk Storming](https://riskstorming.com/) 34 | 35 | - A visual and collaborative risk identification technique 36 | - Can be applied to architectures, business processes, workflows, etc 37 | - Can be applied multiple times during the lifetime of the thing being risk stormed 38 | - More information [here](https://sites.google.com/madetech.com/signpost/home/software-engineering/technical-architecture/processes/risk-storming) 39 | 40 | ## Communicating into the future 41 | 42 | [Read more here](../principles/communicate_into_the_future.md) 43 | 44 | [< Back](./introducing_the_principles.md) 45 | -------------------------------------------------------------------------------- /learning_paths/expectations_of_an_architect.md: -------------------------------------------------------------------------------- 1 | 2 | # The Expectations of an Architect 3 | 4 | From the research conducted as part of Made Tech's internal [Architecture Discovery](https://docs.google.com/presentation/d/1DaVGkDwuj028btg_S3CMT_xu6iVHwn3HO8nfiSXSJ3k/edit?usp=sharing) project we identified the following core expectations of an Architect: 5 | - Guide technology decisions within the team or organisation by defining the architecture decisions and design principles 6 | - Recommend improvements to solutions through continually analyzing the architecture and technical environment 7 | - Keep current with latest technology and industry trends 8 | - Ensure compliance with decisions and principles 9 | - Previous exposure and experience to multiple technologies, frameworks, platforms and environments 10 | - Have business domain knowledge and expertise to effectively communicate with business stakeholders 11 | - Possess interpersonal skills including teamwork, facilitation and leadership 12 | - Understand the political climate of the enterprise and be able to navigate the politics 13 | - Work closely with Product and the Business to give them **options** 14 | 15 | ## Common Questions ? 16 | 17 | - Do they Code? 18 | 19 | Yes and No. 20 | 21 | Most Architects have coded in the past and have a good understanding of code, some continue to code today but others do not. This is often their choice. 22 | 23 | Gregor Hohpe addresses this nicely in his blog [Debugging Architects](https://architectelevator.com/transformation/debugging-architect/) 24 | 25 | > Architects must visit the engine room. Not to deliver code but to re-emerge with new insights. 26 | 27 | The gist here is they must work with developers and be able to understand and gain insight into how they work. 28 | 29 | They might do this by coding with the team or by simply discussing the code and development process with the team. However this requires understanding and enough technical knowledge to talk on the same level as developers and it also needs to be somewhat in depth. Only attending stand-ups isn't going to cut it. 30 | 31 | - Do they design everything ? no 32 | - Do they need to know everything ? no 33 | 34 | **Next** - [The skills and behaviours of an Architect](./skills_of_an_architect.md) 35 | -------------------------------------------------------------------------------- /learning_paths/getting_started.md: -------------------------------------------------------------------------------- 1 | # Getting Started 2 | 3 | ### Video Links 4 | 5 | We recommend watching this video on the modern architecture approach which tackles, the role of IT, change and thinking like an architect. 6 | 7 | [The Software Architect Elevator](https://www.youtube.com/watch?v=Zq2VcRZmz78) - 52 minutes 8 | 9 | [Thinking like an Architect](https://www.youtube.com/watch?v=xtxfrxf0mfE) - 62 minutes 10 | 11 | ### Unicorn Project 12 | 13 | We also recommend reading this novel about a large IT project in an organisation in need of digital transformation. 14 | 15 | The book follows the story of a technical lead (acting like a modern architect) being thrown into a failing project and trying to unpick and correct the technical and business failures. 16 | 17 | It's an easy and fun read but gives a practical insight into the role. 18 | 19 | ![Unicorn Project](../images/unicorn-project.png) 20 | 21 | [Find it on Amazon](https://www.amazon.co.uk/dp/1942788762) 22 | 23 | **Next** - [Introducing the Principles](./introducing_the_principles.md) 24 | -------------------------------------------------------------------------------- /learning_paths/introducing_the_principles.md: -------------------------------------------------------------------------------- 1 | 2 | # Introducing the Principles 3 | 4 | ## Understanding Context 5 | 6 | Before we embark on designing software we need to understand the context in which it will be both developed and used. 7 | 8 | This understanding will inform our decision making later on. We could introduce significant risk if we committed to a language, frameworks or infrastructure without an understanding of expectations and constraints 9 | 10 | ### The Made Tech Architecture Playbook 11 | 12 | Our current playbook focuses on these activities and making yourself familiar with the approach will help you get started on any project. 13 | 14 | [Playbook Part 1 - 'Holistic Thinking'](https://docs.google.com/presentation/d/1RwBxzT37oZNXWZzJBgZ9e-IzXfYOlf7FnGIPdjEZV-Q/edit?usp=sharing) 15 | 16 | ## Software Architecture 17 | 18 | Once the context is understood and the architect knows (more or less) how to make decisions around trade offs and where value lies (e.g scaleability and performance is important but only up to a point and but not as important as correctness or use-ability) then they are better equipped to design the system. 19 | 20 | Whether you are designing Microservices or monoliths (or something else entirely) the basic principles remain. 21 | 22 | - The codebase needs to be easy to test in small chunks or as a whole 23 | - The codebase needs to be easy to change and adapt to new requirements 24 | - The codebase (and therefore design) *is* always changing and adapting 25 | - When a change is made the impact needs to be minimal (it should not trigger many subsequent changes through other components or services causing developers pain) 26 | 27 | So the goal is a responsive software design whether thats the design of classes and functions or services and systems. The goal is always the same (it's just the scale you are looking at it from might change). 28 | 29 | With that in mind it's worth looking at a number of well known approaches to attempt to solve this problem that we believe work well. 30 | 31 | There is no *'one true way'* to design systems but good software developers have a knowledge of many techniques and apply as needed. 32 | 33 | You don't need to know all these (or the many other approaches not mentioned) inside out but have an awareness so when you see the problem space you might relate it back to a known pattern. 34 | 35 | ### [Code design principles](./software/code_design_principles.md) 36 | 37 | ### [Responsive architecture approaches](./software/responsive_architecture_approaches.md) 38 | 39 | ### [Software architecture principles we believe are important](./software/software_architecture_principles.md) 40 | 41 | ## Microservices vs Monoliths 42 | 43 | The debate around how to layer a service - should you or should you not follow a microservice, service oriented or monolithic architecture is so common it's worth addressing now so... [A word on Microservices vs Monoliths](./software/monoliths_vs_microservices.md) 44 | 45 | ## Day to day Behaviours 46 | 47 | This is also true for day to day behaviours, as an architect (or a software developer) what could you be doing on a regular basis that are likely to improve architectural outcomes ? 48 | 49 | [Day to day Behaviours](./continuous_behaviours.md) 50 | 51 | ## Reading Material 52 | 53 | [Fundamentals of Software Architecture](https://www.amazon.co.uk/dp/1492043451) 54 | 55 | [Just Enough Software Architecture](https://www.amazon.co.uk/gp/product/0984618104) 56 | -------------------------------------------------------------------------------- /learning_paths/introduction_to_software_architecture.md: -------------------------------------------------------------------------------- 1 | # Introduction to Architecture 2 | 3 | ![Quote](../images/architecture_quote_1.png) 4 | 5 | You are probably confused as to what an architect does and thats not surprising ! The role of the architect has evolved in many different directions and organisations deliver architecture in many different ways. 6 | 7 | However, fundamentally they are all working to achieve the same goals. 8 | 9 | - Ensure technical designs meet the user and business needs, delivering clear outcomes 10 | - Ensure technical delivery is of high quality and value for money 11 | 12 | This is often achieved by: 13 | 14 | - Working closely with the business or service area to understand goals 15 | - Working closely with developers, advising, mentoring and developing skills 16 | - Setting technical design standards and guidelines for ways of working 17 | - Sharing knowledge through communities of practice 18 | - Communicating clearly at different levels and audiences 19 | - Looking left and right across the technical landscape minimising divergence and increasing convergence 20 | - Governance 21 | 22 | # Why do we need Architecture 23 | 24 | Architecture is part of a value chain, issues early in the chain manifest later as other issues. 25 | 26 | > **Architecture issue -> Coding issue -> Application issue -> Business issue** 27 | 28 | - [Architecture tells a story](./why_do_we_need_architecture.md) and architects are story tellers. 29 | 30 | # The Role of the Architect 31 | 32 | - [Architects and their many titles](./the_role_of_an_architect.md) 33 | - [The Modern Architect](./the_digital_architect.md) 34 | 35 | # Expectations of an Architect 36 | 37 | - [The expectations placed on Architects](./expectations_of_an_architect.md) 38 | 39 | # Skillset of an Architect 40 | 41 | - [The skills and behaviours of an Architect](./skills_of_an_architect.md) 42 | 43 | # Learning Material 44 | 45 | - [Getting Started](./getting_started.md) 46 | - [Introducing the Principles](./introducing_the_principles.md) 47 | 48 | --- 49 | **Next** - [Why do we need architecture?](why_do_we_need_architecture.md) 50 | -------------------------------------------------------------------------------- /learning_paths/skills_of_an_architect.md: -------------------------------------------------------------------------------- 1 | 2 | # Skills and Behaviours 3 | 4 | **Architecture is a skill and set of behaviours: not just a role** 5 | 6 | ![skills and behaviours](../images/architect_skills_blockbuster.png) 7 | 8 | As an Architect you need both sides to be effective. you might have fantastic technical knowledge and experience but if you can't communicate and influence others that knowledge will be wasted. Likewise without a solid technical understanding you might not communicate or influence the right ideas or fall short on credibility. Worse still you could lead an organisation in the wrong technical direction ! 9 | 10 | Looking now at the top of the graphic we see leadership skills, both technical and non technical. People will look at you for direction and you should be able to communicate direction with authority. Without some kind of leadership people will not trust the vision you put forward. 11 | 12 | Now looking near the bottom we see a growth mindset. Architects are always seeking to learn more and be better but also look to help others do the same through mentoring or teaching. 13 | 14 | We also see facilitation in the bottom right, this is another key skill and brings together all the above elements as an agent of change. Architects use evidence based approaches with a lean and agile mindset often running workshops and collaborative activities (again working closely with delivery managers and product owners) to influence positive, focused behaviours. 15 | 16 | This again makes us think of a 'Digital Guru' and can seem impossible to achieve ? How can an architect be an expert in all these areas ? 17 | 18 | The truth is no architect is an expert in every area but effective architects have a good understanding of all areas with no glaring weakness. Many will have specialities or stronger attributes but all recognise their strengths and utilise others to complement them while improving and learning through their growth mindset. 19 | 20 | Examples of different balances of an architect might be: 21 | 22 | - Strong technical background but less experience presenting and communicating ideas to non technical groups 23 | - Excellent communicator and influencer, great at listening and understanding but has a shallower understanding of technology or might be missing a few areas such as cloud or security. 24 | 25 | ![Enterprise Architect vs Technical Architect](../images/enterprise-vs-technical.png) 26 | 27 | Another example is a Senior vs a Lead architect where the senior performs more strongly in some areas but is missing a key skill or is overall weaker across other areas compared to the lead. 28 | 29 | ![Senior Architect vs Lead Architect](../images/senior-vs-lead.png) 30 | 31 | You might want to **[map your strengths and skills](https://madetech.github.io/skills-radar/)** over the graphic above ? if you were to rate yourself in each area what would your radar look like ? 32 | 33 | Once you understand this you know your strengths and weaknesses and you can communicate that to your team, if someone on your team excels in an area you are weak then work together and learn from them! 34 | 35 | **Next** - [Getting Started](./getting_started.md) 36 | -------------------------------------------------------------------------------- /learning_paths/software/README.md: -------------------------------------------------------------------------------- 1 | # Software Principles 2 | 3 | 1. [Code design principles](./code_design_principles.md) 4 | 2. [Responsive architecture approaches](./responsive_architecture_approaches.md) 5 | 3. [Software architecture principles we believe are important](./software_architecture_principles.md) 6 | 4. [A word on Microservices vs Monoliths](./monoliths_vs_microservices.md) 7 | -------------------------------------------------------------------------------- /learning_paths/software/code_design_principles.md: -------------------------------------------------------------------------------- 1 | [< Back](../introducing_the_principles.md) 2 | 3 | # Code design principles 4 | 5 | A good foundation (or place to start) is the design of code and an understanding of best practice. 6 | 7 | ## TDD 8 | 9 | It's worth revisiting why we do TDD (Test Driven Development) as it's not just to ensure our code is tested but to promote good code design. 10 | 11 | It is possible to recognise code written using TDD practices at is is intrinsically different from code which was written without TDD. You also find adding tests retrospectively is hard and frustrating and you end up leaning on BDD (behavioural tests). 12 | 13 | *Why is this ?* 14 | 15 | Code written using TDD has to be small, have a single purpose and therefore a single test. We compose these testable units together into more complex behaviours. 16 | 17 | > TDD will force you to write testable code, i.e., *loosely coupled* and *highly cohesive,* which means your code has a higher quality. If the testing becomes difficult, it is a tell-tale sign your design could use improvement. Thus, TDD is an effective way to get feedback on your code’s *internal quality*. 18 | > 19 | > https://www.codecraftr.nl/why-use-tdd/ 20 | 21 | ## SOLID 22 | 23 | The SOLID principles for Object Oriented Programming are important to understand as their use cases can be scaled beyond classes and functions within a single codebase. 24 | 25 | - **S** - Single-responsibility Principle 26 | - **O** - Open-closed Principle 27 | - **L** - Liskov Substitution Principle 28 | - **I** - Interface Segregation Principle 29 | - **D** - Dependency Inversion Principle 30 | 31 | [SOLID Principles for Programming and Software Design](https://www.freecodecamp.org/news/solid-principles-for-programming-and-software-design/) 32 | 33 | ## Code Decomposition 34 | 35 | Techniques to help break down code design into modular blocks (hint: so that agility as a quality attribute is met). 36 | 37 | - [CRC Cards to decompose code into classes](https://agilemodeling.com/artifacts/crcModel.htm) 38 | 39 | [< Back](../introducing_the_principles.md) 40 | -------------------------------------------------------------------------------- /learning_paths/software/monoliths_vs_microservices.md: -------------------------------------------------------------------------------- 1 | [< Back](../introducing_the_principles.md) 2 | 3 | # A word on Microservices vs Monoliths 4 | 5 | Microservices are popular as (in theory) they force a number of the above principals onto teams by splitting up services into small domain concerns with clear interfaces. They provide other advantages such as (but not limited to): 6 | 7 | - Scalability improvements 8 | - Improved fault isolation 9 | - Program language and technology agnostic 10 | - Reusability across different areas of business 11 | 12 | However they also have a management overhead and if designed poorly can be unintentionally tightly coupled (e.g a distributed monolith) which can become a nightmare to maintain. 13 | 14 | We believe a team should understand how to create a loosely coupled Monolith before embarking on Microservices so recommend the video below. 15 | 16 | [Creating a Loosely Coupled Monolith](https://www.youtube.com/watch?v=48C-RsEu0BQ) 17 | 18 | [Modular Monoliths • Simon Brown (Warning! Challenging! Pay close attention to minute 38 onwards)](https://youtu.be/5OjqD-ow8GE?t=2283) 19 | 20 | [< Back](../introducing_the_principles.md) 21 | -------------------------------------------------------------------------------- /learning_paths/software/responsive_architecture_approaches.md: -------------------------------------------------------------------------------- 1 | [< Back](../introducing_the_principles.md) 2 | 3 | # Responsive architecture approaches 4 | 5 | Taking a step further back from the code and thinking more abstractly about designing software and services we encounter design patterns which attempt to make larger scale designs more responsive to change. 6 | 7 | You don't need to know these in depth but being aware of their existence and what they are trying to achieve will help you in your design process. 8 | 9 | The patterns below are some good starting points but you will find many more if you dig deeper. 10 | 11 | ## Onion Architecture 12 | 13 | The Onion Architecture is not well known but often implemented. It is a foundational part of the more popular clean architecture (discussed later). 14 | 15 | This Architecture relies heavily on the _Dependency Inversion Principle_ and focuses on decoupling the business logic from other layers which is a recurring theme for building responsive architectures. 16 | 17 | [Onion Architecture](https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/) 18 | 19 | ## Domain Driven Design 20 | 21 | Domain Driven Design is a concept that models software based on a business domain and it's context, working closely with business experts. 22 | 23 | [Domain Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design) 24 | 25 | You might see how the DDD approach fits well with the Made Tech Playbook where we spend effort understanding the business context, working closely with subject matter experts. 26 | 27 | [DDD Made Simple](https://www.youtube.com/watch?v=H5--9pMmuK4) - 8 minutes 28 | 29 | However it's implementation can be complicated or overkill for smaller projects. 30 | 31 | [Stop Dogmatic DDD](https://www.youtube.com/watch?v=8XmXhXH_q90) - 7 minutes 32 | 33 | ## Hexagonal Architecture (Ports and Adapters) 34 | 35 | [Hexagonal Architecture](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)) is yet another approach that shares many themes from above. 36 | 37 | The _Ports and Adapters_ approach here is incredibly powerful for creating easily testable units of code. Using this approach you end up injecting dependancies into your units of code (e.g a class) decoupling anything outside the core application (such as a database or API). 38 | 39 | [How To Make Your App Maintainable (hint: Adopt Hexagonal Architecture)](https://www.youtube.com/watch?v=92ZJcxJgmmE) - 18 mins 40 | 41 | ## DCI (Data, context, and interaction) Architecture 42 | 43 | A slightly different twist on the above approaches where users and their behaviour are moved to the fore. 44 | 45 | > Objects are principally about people and their mental models—not polymorphism, coupling and cohesion 46 | > ... but in spite of capturing structure, OO fails to capture behavior 47 | 48 | - To improve the readability of [object-oriented](https://en.wikipedia.org/wiki/Object-oriented_programming "Object-oriented programming") code by giving system behavior first-class status; 49 | - To cleanly separate code for rapidly changing system behavior (what a system _does_) versus slowly changing [domain knowledge](https://en.wikipedia.org/wiki/Domain_knowledge "Domain knowledge") (what a system _is_), instead of combining both in one class interface; 50 | - To help software developers reason about system-level state and behavior instead of only object state and behavior; 51 | - To support an object style of thinking that is close to programmers' mental models, rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages. 52 | 53 | [DCI Architecture](https://www.artima.com/articles/the-dci-architecture-a-new-vision-of-object-oriented-programming) 54 | 55 | ## Clean Architecture 56 | 57 | Clean architecture is an amalgamation of a number of architecture strategies. It is an attempt to create a separation of concerns. This separation is achieved by dividing the software into layers such as decoupling UI from the Business logic or external dependancies to increase testability and changeability of components increasing your softwares responsiveness to change. 58 | 59 | The overriding rule that makes this architecture work is _The Dependency Rule_. This rule says that _source code dependencies_ can only point _inwards_. 60 | 61 | A simple [explanation](https://www.youtube.com/watch?v=Ys_W6MyWOCw) that nicely explains when and when not to follow dogma based on trade offs - 15 minutes 62 | 63 | ## Event Driven Architecture 64 | 65 | An application and system architecture that has been well designed (and implemented) enables you to reap the benefits of other patterns such as [Event Driven Architecture](https://en.wikipedia.org/wiki/Event-driven_architecture). 66 | 67 | Events (as messages) can be easily transmitted among loosely coupled software components and services, an example of this might be using the [Observer Pattern](https://refactoring.guru/design-patterns/observer/ruby/example) to notify a Search Engine that state has changed to allow instant re-indexing. 68 | 69 | ## Further Material 70 | 71 | [Hexagonal, Onion & Clean Architecture](https://www.youtube.com/watch?v=JubdZIdLQ4M) 72 | 73 | [< Back](../introducing_the_principles.md) 74 | -------------------------------------------------------------------------------- /learning_paths/software/software_architecture_principles.md: -------------------------------------------------------------------------------- 1 | [< Back](../introducing_the_principles.md) 2 | 3 | # Software architecture principles we believe are important 4 | 5 | - **Designing Components** so they are *stable* (balancing cohesion and coupling) 6 | - **Setting Boundaries** between software elements. Boundaries separate things that matter from things that don’t, i.e. high-level components from low-level components 7 | - **Separating layers** and organising them using the *dependency rule*: outer layers should depend on inner layers (at the source-level), and not vice versa. 8 | 9 | [< Back](../introducing_the_principles.md) 10 | -------------------------------------------------------------------------------- /learning_paths/the_digital_architect.md: -------------------------------------------------------------------------------- 1 | 2 | # The Modern Architect 3 | 4 | Within the Public Sector 'Transformation' is everywhere. 5 | 6 | Everyone is on some transformation journey, whether just starting out or maturing and improving. 7 | 8 | As an architect your role is often to deliver and accelerate this transformation. 9 | 10 | > Many large enterprises are feeling pressure from digital disruptors 11 | > who serve users’ increased expectations with innovative business 12 | > models and little legacy. Competing in such an environment remains a 13 | > massive challenge for enterprises that rely on traditional technology 14 | > and organizational structures to be successful. 15 | > 16 | > Architects and CTOs play a critical role in transforming such 17 | > organizations. They combine the technical, communication, and 18 | > organizational skills to derive business value from a tech stack 19 | > refresh. They see more dimensions and bust common disbelieves, 20 | > for example showing that moving faster can actually increase quality. 21 | > 22 | > Gregor Hohpe, https://architectelevator.com 23 | 24 | The role has been described as 'some kind of digital guru' which can feel a bit overwhelming but it comes down to architects being **'agents of change'**. 25 | 26 | The modern architect does not operate in a silo but has a broader role, bringing the organisation together around lean and agile methodologies to enable the most effective technical delivery for a service. They work closely with Delivery Managers and Product Owners managing trade offs and leading technical decision making from a position of informed knowledge. 27 | 28 | **Next** - [The expectations placed on Architects](./expectations_of_an_architect.md) 29 | -------------------------------------------------------------------------------- /learning_paths/the_role_of_an_architect.md: -------------------------------------------------------------------------------- 1 | # The Role of the Architect 2 | 3 | Traditionally the architect role has evolved into certain activities at different levels within an organisation. 4 | 5 | You will see some architects working closely with the exec team and never with developers, others work close to the coal face and organisations like to keep this distinction by differing titles. 6 | 7 | ## Typical Public Sector Roles 8 | 9 | The Public Sector is made up of hundreds (if not thousands) of organisations all moving at a differing pace and many levels of size and digital maturity. 10 | 11 | GDS have a definition of architecture roles [here](https://www.gov.uk/government/collections/digital-data-and-technology-profession-capability-framework#technical-job-family), of which [this role definition](https://ddat-capability-framework.service.gov.uk/role/technical-architect#lead-technical-architect) is the most relevent and overlaps more clearly with Made Tech skills and behaviours. 12 | 13 | However, alignment with DDaT professions is not a given and on the ground when working with Central, Local or Arms Lengths Bodies wthin the Public Sector and you are likely to see other roles in the wild. 14 | 15 | ### Enterprise Architect 16 | 17 | ### Technical Architect 18 | 19 | Can also be described as: **Application Architect** or **Software Architect** or **Product Architect** 20 | 21 | ### Cloud Architect 22 | 23 | Can also be described as: **Infrastructure Architect** 24 | 25 | ### Other roles you might see 26 | 27 | Integration architect, Solution Architect, Security Architect, Data Architect, Transformation Architect 28 | 29 | ## The Modern Architect 30 | 31 | We are seeing the emergence of a modern architect within leaner, more agile 'Digital Enterprises' where role and activities are less siloed. 32 | 33 | > Modern architects align organization and technology, reduce friction, and chart transformation journeys. In addition to working with UML and architecture styles, such architects ride the Architect Elevator from the penthouse, where the business strategy is set, to the engine room, where the enabling technologies are implemented. They shun popular buzzwords in favor of a clear strategy defined by conscious decision making. 34 | > 35 | > Gregor Hohpe, https://architectelevator.com/ 36 | 37 | We also consider how **all** Developers as play a part in the architecture role and how the modern architect facilitates this. 38 | 39 | **Next** - [The Modern Architect](./the_digital_architect.md) 40 | -------------------------------------------------------------------------------- /learning_paths/visualising_architecture.md: -------------------------------------------------------------------------------- 1 | # Visualising Architecture 2 | Helping to create a common understanding and foster collaboration. 3 | 4 | ## Recommended reading 5 | Many of views expressed here align the views of Simon Brown in his book which is part of our [recommended reading list](../resources.md). 6 | 7 | ## Watch 8 | Watch our recent visualising architecture CoP session [here](https://drive.google.com/file/d/14R3OpBbcN0xbU_XeQQfG7ocehkw_U0w3/view?usp=share_link) 9 | 10 | ## Introduction 11 | Visualising architecture is about effectively and efficiently communicating the software architecture of the software that you’re building, with a view to: 12 | - Help everybody understand the “big picture” of what is being built, and how this fits into the “bigger picture” of the organisation/environment in which it exists. 13 | - Create a shared vision for the development team. 14 | - Provide a “map” that can be used by software developers to navigate the source code. 15 | - Provide a point of focus for technical conversations about new features, technical debt, risk reviews, etc. 16 | - Fast-track the on-boarding of new software developers into the team. 17 | - Provide a way to explain what’s being built to people outside of the development team, whether they are technical or non-technical. 18 | 19 | ## The problem to solve 20 | Ask somebody in the building industry to visually communicate the architecture of a building and you’ll likely be presented with site plans, floor plans, elevation views, cross-section views, and detailed drawings. In contrast, ask somebody in the software industry to communicate the software architecture of a software system using diagrams, and you’ll likely get a confused mess of boxes and lines. 21 | 22 | ## Doesn't the code speak for itself? 23 | We feel it is difficult to describe a code base perfectly without a lot of prior knowledge. We feel that different questions require different levels of granularity to answer them, which may not easily be possible from just looking at the code. The code doesn’t answer where components are deployed at runtime or how they communicate and it does not provide an overview of a system that can be used for group decision making. 24 | 25 | ## C4 Model 26 | The [C4 Model](https://c4model.com/) focusses on the visual communication and documentation of software architecture. It doesn’t present a formalised, standardised method to communicate software architecture, it does provide a collection of lightweight ideas and techniques that we've observed to be useful. 27 | 28 | We've observed the use of the C4 Model with our active deliveries and found that it: 29 | - Provides a lean approach to diagramming a software architecture at multiple levels 30 | - It helps focus on providing clear and concise meaning 31 | - Is useful as starting point for other techniques such as risk storming 32 | - Has a wide range of diagram types that are easy to learn, create and understand 33 | - Isn't mandatory to create versions of all of the diagrams, only use ones that appropriate. System Context and Container diagrams are the most widely used. 34 | - is a simple but not simplistic approach to visualising architecture 35 | 36 | ## Tools 37 | 38 | See a list of potential [tools](../principles/tools.md) that are tried and tested. 39 | 40 | However, we recommend the [C4 Model](https://c4model.com/) and the [Structurizr DSL](https://github.com/structurizr/dsl). See [here for a demo](https://github.com/madetech/structurizr-template) that you can try and explains why. 41 | -------------------------------------------------------------------------------- /learning_paths/visualising_architecture/1_why_visualise.md: -------------------------------------------------------------------------------- 1 | # Visualising Architecture 2 | Helping to create a common understanding and foster collaboration. 3 | 4 | ## Introduction 5 | Visualising architecture is about effectively and efficiently communicating the software architecture of the software that you’re building, with a view to: 6 | - Help everybody understand the “big picture” of what is being built, and how this fits into the “bigger picture” of the organisation/environment in which it exists. 7 | - Create a shared vision for the development team. 8 | - Provide a “map” that can be used by software developers to navigate the source code. 9 | - Provide a point of focus for technical conversations about new features, technical debt, risk reviews, etc. 10 | - Fast-track the on-boarding of new software developers into the team. 11 | - Provide a way to explain what’s being built to people outside of the development team, whether they are technical or non-technical. 12 | 13 | ## The problem to solve 14 | Ask somebody in the building industry to visually communicate the architecture of a building and you’ll likely be presented with site plans, floor plans, elevation views, cross-section views, and detailed drawings. In contrast, ask somebody in the software industry to communicate the software architecture of a software system using diagrams, and you’ll likely get a confused mess of boxes and lines. 15 | 16 | ## Doesn't the code speak for itself? 17 | We feel it is difficult to describe a code base perfectly without a lot of prior knowledge. We feel that different questions require different levels of granularity to answer them, which may not easily be possible from just looking at the code. The code doesn’t answer where components are deployed at runtime or how they communicate and it does not provide an overview of a system that can be used for group decision making. 18 | 19 | **Next** - [The C4 model](./2_c4_model.md) -------------------------------------------------------------------------------- /learning_paths/visualising_architecture/2_c4_model.md: -------------------------------------------------------------------------------- 1 | # C4 Model 2 | The [C4 Model](https://c4model.com/) focuses on the visual communication and documentation of software architecture. It doesn’t present a formalised, standardised method to communicate software architecture, it does however provide a collection of lightweight ideas and techniques that we've observed to be useful. 3 | 4 | We've observed the use of the C4 Model with our active deliveries and found that it: 5 | - Provides a lean approach to diagramming a software architecture at multiple levels 6 | - Helps focus on providing clear and concise meaning 7 | - Is useful as starting point for other techniques such as risk storming 8 | - Has a wide range of diagram types that are easy to learn, create and understand 9 | - Isn't mandatory to create versions of all of the diagrams, only use ones that appropriate. System Context and Container diagrams are the most widely used. 10 | - Is a simple but not simplistic approach to visualising architecture 11 | 12 | The creator of C4 Simon Brown has published a book called `Visualising Software Architecture`, which is part of our [recommended reading list](/resources.md) 13 | 14 | ## Watch 15 | ### Visualising Architecture CoP session (22nd November 2022) 16 | [![Visualising Architecture](https://madetech.github.io/architecture-handbook/images/visualising_architecture.jpg)](https://drive.google.com/file/d/14R3OpBbcN0xbU_XeQQfG7ocehkw_U0w3/view) 17 | 18 | **Made Tech internal only video** 19 | 20 | Stuart McKee demonstrates how to create a common understanding and foster collaboration 21 | 22 | - [Recording](https://drive.google.com/file/d/14R3OpBbcN0xbU_XeQQfG7ocehkw_U0w3/view) 23 | - [Slides](https://docs.google.com/presentation/d/1wXXkyTgoNJIgyD9MDuIlvi85uGHWjIgQhvOPKTNsrHo/edit) 24 | 25 | **Next** - [Structurizr](./3_structurizr.md) 26 | -------------------------------------------------------------------------------- /learning_paths/visualising_architecture/3_structurizr.md: -------------------------------------------------------------------------------- 1 | # Structurizr 2 | We recommend using the [C4 Model](https://c4model.com/) in conjunction with the [Structurizr DSL](https://github.com/structurizr/dsl) as a way to automatically generate the C4 diagrams from code. This allows for the Structurizr code to be kept in the same repository as the code of the system, making it easier to keep the two up to date together. 3 | 4 | A [Structurizr Lite quick start template](https://github.com/madetech/structurizr-template) has been created that you can use as a starting point in your own projects. 5 | 6 | ## Quick overview 7 | All the code to define the model, relationships and views are held in a single `workspace.dsl` file that Structurizr uses to build the visual diagams. 8 | 9 | ![Structurizr workspace](https://madetech.github.io/architecture-handbook/images/structurizr_workspace.jpg) 10 | 11 | The following code will generate a very simple diagram showing a basic relationship between a user and a software system 12 | ``` 13 | workspace { 14 | model { 15 | u = person "User" 16 | s = softwareSystem "Software System" 17 | 18 | u -> s "uses" 19 | } 20 | views { 21 | container s { 22 | include * 23 | autoLayout 24 | } 25 | } 26 | ``` 27 | 28 | ## Watch 29 | ### Structurizr: Software architecture models as code CoP session (1st August 2023) 30 | [![Software architecture models as code](https://madetech.github.io/architecture-handbook/images/structurizr.jpg)](https://drive.google.com/file/d/1mJ2TpHPmiwDel0GhoIQdVv87cXfTwLCf/view) 31 | **Made Tech internal only video** 32 | 33 | Peter Bridger explains how to get up and running with Structurizr to create your own interactive diagrams, along with using the documentation and ADR abilities of Structurizr Lite using the quick start template mentioned previously. 34 | 35 | - [Recording](https://drive.google.com/file/d/1mJ2TpHPmiwDel0GhoIQdVv87cXfTwLCf/view) 36 | - [Slides](https://docs.google.com/presentation/d/1WDT0kEZoicyoUUp96QXznWwGv8lmvfAno0s_irAkXX0/edit) 37 | 38 | ### Futher reading 39 | - [Structurizr](https://structurizr.com/) project website 40 | - [Structurizr Lite](https://structurizr.com/help/lite) free version 41 | - [Structurizr DSL language reference](https://github.com/structurizr/dsl/blob/master/docs/language-reference.md) 42 | -------------------------------------------------------------------------------- /learning_paths/why_do_we_need_architecture.md: -------------------------------------------------------------------------------- 1 | # Why do we need architecture ? 2 | 3 | ![Why do we need architecture](../images/why_do_we_need_architecture.png) 4 | 5 | Source: [Coevolution of Architecture & Code - Closing The Gap](https://www.youtube.com/watch?v=slGZMTFPElo) 6 | 7 | **Next** - [The Role of the Architect](./the_role_of_an_architect.md) 8 | -------------------------------------------------------------------------------- /playbooks/architecture-part-1.md: -------------------------------------------------------------------------------- 1 | [Playbook Part 1 - 'Holistic Thinking'](https://docs.google.com/presentation/d/1RwBxzT37oZNXWZzJBgZ9e-IzXfYOlf7FnGIPdjEZV-Q/edit?usp=sharing) 2 | -------------------------------------------------------------------------------- /principles.md: -------------------------------------------------------------------------------- 1 | # The Big List of Principles 2 | 3 | ## Software Design 4 | 5 | ### Designing Components so they are *stable* 6 | 7 | Balancing cohesion and coupling 8 | 9 | ### Set Boundaries between software elements 10 | 11 | Boundaries separate things that matter from things that don’t, i.e. high-level components from low-level components 12 | 13 | ### Separate layers and organise them using the *dependency rule* 14 | 15 | Outer layers should depend on inner layers (at the source-level), and not vice versa. 16 | 17 | ### Don't add complexity where it is not needed 18 | 19 | For example: 20 | * Most services we build are simple forms 21 | * We should avoid Business Logic in the User Interface. If the project requires it, we **should** include an [Architecture Decision Record](./principles/communicate_into_the_future.md) explaining why 22 | * Avoid using JavaScript in the User Interface in the project. The project **should** include an [Architecture Decision Record](./principles/communicate_into_the_future.md) explaining why. Even if the project uses standard GOV.uk/local authorities' approved components 23 | 24 | ## Behaviours 25 | - [Continually visualise the technical architecture](principles/continually_visualise_the_technical_architecture.md) 26 | - [Keep documentation close to code](principles/keep_documentation_close_to_code.md) 27 | - [Communicate into the future](principles/keep_documentation_close_to_code.md) 28 | -------------------------------------------------------------------------------- /principles/communicate_into_the_future.md: -------------------------------------------------------------------------------- 1 | # Communicate into the future 2 | 3 | - Communication is a key architecture skill 4 | - Consider the context of who you are communicating too and how it would be best received or understood 5 | - Simple not simplistic 6 | - You must consider future teams and architects, years from now decisions will be questioned and problems revisited. Shortcut that future pain by making sure the past can be understood. 7 | 8 | [Architecture Decision Records (ADRs)](https://adr.github.io/) 9 | 10 | - A framework for recording choices that are architecturally significant 11 | - Helps with knowledge transfer over the lifetime of a product 12 | - The process of filling in ADRs helps solidify thinking on a decision 13 | -------------------------------------------------------------------------------- /principles/continually_visualise_the_technical_architecture.md: -------------------------------------------------------------------------------- 1 | # Continually visualise the technical architecture 2 | 3 | - Fosters common understanding of architecture to technical and non-technical stakeholders 4 | - Aligns to evolving architecture through techniques such as minimum viable architecture (MVA) 5 | - Provides value for enabling techniques such as risk storming 6 | - Can help with speeding up comprehension of architecture for new team members 7 | 8 | See the [visualising architecture](../learning_paths/visualising_architecture.md) learning path for more information. 9 | -------------------------------------------------------------------------------- /principles/keep_documentation_close_to_code.md: -------------------------------------------------------------------------------- 1 | # Keep documentation close to code 2 | 3 | We have observed that proximity of documentation to code leads to increased freshness of documentation 4 | 5 | - Simplifies checking updates have been done as part of Definition of Done 6 | - Documentation / diagrams as code Change from static 7 | - diagrams done at the start/end of a delivery to living parts of the 8 | delivery that add value in terms of domain context 9 | -------------------------------------------------------------------------------- /principles/tools.md: -------------------------------------------------------------------------------- 1 | # Tools 2 | 3 | ## [PlantUML](https://www.planttext.com/) 4 | 5 | - Has a [C4 Plugin](https://github.com/plantuml-stdlib/C4-PlantUML) so you can make C4 Diagrams. 6 | - Has a [VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml) 7 | - Need to set it to local Render if project is not open source or is connecting to sensitive sources. 8 | 9 | ## [Web Sequence Diagrams](https://www.websequencediagrams.com/) 10 | 11 | - Quick and easy 12 | - No offline support 13 | - If you download the image not text, you can't "pick up where you left off" 14 | - Not really code (supports `.txt`) 15 | - Web only/image is hosted, possibly a no go if security is a concern - links directly to the images 16 | 17 | ## [ArchiMate](https://en.wikipedia.org/wiki/ArchiMate) 18 | 19 | - An enterprise modelling language that is free and open 20 | - Open source modelling toolkit available: [Archi](https://www.archimatetool.com/) 21 | 22 | ## [Draw.io](https://draw.io) 23 | 24 | - As lots of default shapes, AWS etc 25 | 26 | ## [Structurizr](https://structurizr.com/) 27 | 28 | - Diagrams as code 29 | - Also offers publishing of [ADRs](./communicate_into_the_future.md) to enrich the generated diagrams 30 | - Developed by Simon Brown, and so has strong C4 model support 31 | - See [MoJ's HMPPS](https://github.com/ministryofjustice/hmpps-architecture-as-code) example 32 | 33 | ## [CodeClimate Quality](https://codeclimate.com/quality) 34 | 35 | - Help get a better understanding of technical debt in a code base and how to resolve it 36 | - Applicable across a large range of languages 37 | -------------------------------------------------------------------------------- /resources.md: -------------------------------------------------------------------------------- 1 | # Useful Resources 2 | ## 📚 Books 3 | 4 | ### Fundamentals of Software Architecture 5 | [![Fundamentals of Software Architecture](/images/books/fundamentals_of_software_architecture.jpeg)](https://www.amazon.co.uk/dp/1492043451) 6 | 7 | - Real world advice for technologists to drive architectural excellence 8 | - Viewed as a guide to navigate personal journeys towards software architecture mastery 9 | - Comprehensive overview of software architecture's many aspects, including: 10 | - First Law of Software Architecture: _Everything in software architecture is a trade-off_ ⚖️ 11 | - Second Law of Software Architecture: _Why is more important than how_ 12 | - All architectures become iterative because of unknown unknowns, Agile just recognizes this and does it sooner 13 | - £35 on [Amazon](https://www.amazon.co.uk/dp/1492043451) 14 | 15 | ### The Software Architect Elevator 16 | [![The Software Architect Elevator](/images/books/the_software_architect_elevator.jpeg)](https://www.amazon.co.uk/dp/1492077542) 17 | - Provides invaluable insight into what architecture is all about 18 | - Teaches how to avoid the traditional, somewhat dysfunctional 'business vs IT' mindset 19 | - Covers an essential mix of technical and non-technical topics 20 | - About £30 on [Amazon](https://www.amazon.co.uk/dp/1492077542) 21 | 22 | ### Accelerate 23 | [![Accelerate](/images/books/accelerate.jpg)](https://www.amazon.co.uk/dp/1942788339) 24 | - Clear and practical advice on measuring and investing in team performance 25 | - Provides context around the role of architecture, and its significant impact on team performance 26 | - Solid guidance on what works, what doesn't work, and what doesn't matter 27 | - About £12 on [Amazon](https://www.amazon.co.uk/dp/1942788339) 28 | 29 | ### Visualising Software Architecture 30 | [![Visualising Software Architecture](/images//books/c4_model.png)](https://leanpub.com/visualising-software-architecture) 31 | - An indepth look at leveraging the C4 Model https://c4model.com/ for visualising software architecture 32 | - Contains advice and guidance on the primary and supplimentary diagrams and how to handle large systems 33 | - Provides guidance on adding additional information to the diagrams to help facilitate a particular narrative 34 | - About £9 on [leanpub](https://leanpub.com/visualising-software-architecture) 35 | 36 | ### The Pragmatic Programmer 37 | [![The Pragmatic Programmer](/images//books/the_pragmatic_programmer.jpg)](https://www.amazon.co.uk/dp/0135957052) 38 | - Reminder of: 39 | - Don't add complexity where it isn't need yet 40 | - Trade offs (pros/cons) 41 | - About £30 on [Amazon](https://www.amazon.co.uk/dp/0135957052) 42 | 43 | ### Just enough software architecture: A risk-driven approach 44 | [![Just enough software architecture](/images/books/just_enough_architecture.jpg)](https://www.amazon.co.uk/gp/product/0984618104) 45 | - This is a practical guide for software developers 46 | - It teaches risk-driven architecting 47 | - It emphasizes the engineering 48 | - It provides practical advice 49 | - About £40 on [Amazon](https://www.amazon.co.uk/gp/product/0984618104) but the ebook is available for £7.99 [on George Fairbanks' own website](https://www.georgefairbanks.com/e-book/) 50 | 51 | ## 📺 Videos 52 | - [The Software Architect Elevator](https://www.youtube.com/watch?v=Zq2VcRZmz78) 53 | - [Hexagonal, Onion & Clean Architecture](https://www.youtube.com/watch?v=JubdZIdLQ4M) 54 | - [How To Make Your App Maintainable (hint: Adopt Hexagonal Architecture)](https://www.youtube.com/watch?v=92ZJcxJgmmE) 55 | 56 | ## 🌐 Web 57 | - [Debugging Architects](https://architectelevator.com/transformation/debugging-architect/) 58 | - [Improve how you architect web apps](https://www.patterns.dev/) 59 | - [38 Actions and Insights to Become a Better Software Architect](https://medium.com/hackernoon/38-actions-and-insights-to-become-a-better-software-architect-f135e2de9a1b) 60 | - [Roadmap.sh - Software Architect](https://roadmap.sh/software-architect) 61 | - [Event Storming](https://www.eventstorming.com/) 62 | 63 | ## 💁 People 64 | - [Gregor Hohpe](https://architectelevator.com/about/) 65 | - [Simon Brown](https://simonbrown.je/) 66 | - [Addy Osmani](https://addyosmani.com/) 67 | --------------------------------------------------------------------------------