So you wanna be a software architect?

This aims to be a collection of resources if you decide you want to train yourself to be a software architect.

In phase 1, it'll be just a bunch of links put into this readme.
In phase 2, it should have a structure, a good start for everyone (hopefully), but not a complete thing.
In phase 3, it'll be an ultimate guideline on the topic "How to be a software architect".

Let's go.

Oh, I almost forget: do contribute, I have a lot of things to learn (eg. proper written english :).

Phase 1

(don't worry, phase 2 won't look like this)

Podcasts

Software Architecture Podcasts (https://player.fm/podcasts/Software-Architecture)
Episode 396: Antifragile Architecture
Episode 390: Security in Software Design
Episode 389: Basecamp’s Software Development Process
Episode 374: Motivating Programmers
Episode 368: Managing Distributed Teams
Episode 355: Scaling Technology and Organization
Episode 346: Streaming Architecture
Episode 333: Software Design
Episode 317: Measuring Software Engineering Productivity
Episode 308: IT Architecture and IT Transformation
Episode 281: Career Strategy
Episode 265: Becoming a Tech Lead
Episode 250: Why Large IT Projects Fail
Episode 245: Marketing Yourself and Managing Your Career
Episode 236: Evolutionary Architecture
Episode 234: Lean Enterprise
Episode 228: Software Architecture Sketches
Episode 208: Hiring in the Software Industry
Episode 170: Large Agile Software Development
Episode 168: Being a Consultant
Episode 166: Living Architectures
Episode 153: Product Lines and Software Ecosystems
Episode 149: Difference between Software Engineering and Computer Science
Episode 147: Software Development Manager
Episode 142: Sustainable Architecture
Episode 132: Top 10 Architecture Mistakes
Episode 115: Architecture Analysis
Episode 114: Requirements Engineering
Episode 112: Roles in Software Engineering II
Episode 110: Roles in Software Engineering I
Episode 93: Lessons Learned From Architecture Reviews
Episode 90: Product Line Engineering Pt. 3
Episode 58: Product Line Engineering Pt. 2
Episode 53: Product Line Engineering Pt. 1
Episode 74: Enterprise Architecture II
Episode 34: Enterprise Architecture I
Episode 64: Architecture and Business
Episode 41: Architecture Pt. 4
Episode 30: Architecture Pt. 3
Episode 25: Architecture Pt. 2
Episode 23: Architecture Pt. 1
49. Building Effective Distributed Teams
47. Working with an Event-Driven Architecture
42. How to Prepare for Coding Interviews
41. Architecting Multi-Tenancy
39. Evolving Alongside your Tech Stack
28. Effective Leadership Development
24. Side Projects for Fun and (not necessarily) Profit
20. Becoming a Junior Developer
15. Pursuing a Career in Tech
10. How to Learn Something New
9. Coordinating Remote Work
125: Choosing the Right Product Idea
105: Strength Training for Nerds
91: Designing a Calmer Team Communication Platform
56: Getting Things Done and Building Your Own Tools
42: Marketing for Developers
31: #NoEstimates
26: What do you need when you launch?
25: Tips and tricks to make your code awesome
20: Code is not a business
17: Maximizing Your Conference Experience
9: Architecture, Patterns and Design
5: Jobs-to-be-Done and Product Design
Designing Data-Intensive Applications: Reliability, Scalability, Maintainability, Data models: Relational vs Document, Relationships, Query Languages
The Pragmatic Programmer - Investing in Your Knowledge Portfolio
What Should You Learn Next?
Tackling Tough Developer Questions
How to Learn Programming Skills
Programmer Strengths and Weaknesses
Software Design Anti-patterns
Why Domain Driven Design
How to be an Advanced Programmer
Delegate all the things!
What programmer do you want to be?
Technical Leadership, Cultivating Culture, and Career Growth
Role of the Software Architect in a Continuous Delivery Environment
Architecting to Avoid and Recover from Failure
Unlocking the "Secret Sauce" of Great Teams
Architecture and Rapid Growth

Ideas, technologies, seeds for a google search

everything driven development
Hammock Driven Development
caching techniques, tools and cache invalidation
chaos engineering
antifragile architecture
distributed (systems | databases | coordination)
documenting architecture
fault tolerance and error handling
legacy (code | systems)
modularization
mooc
multi-tier applications
performance and tuning
pipes & filter
rfc
semantic versioning
software architecture in sync with organization structure
software architecture patterns
technical debt
timezones
UML
C4 model (Simon Brown)

Human factor

360 degree feedback
support network of architects
plan your own time as well

Process

agile
disaster recovery plan
estimation
handling defects
incident response
incremental release
itil
product iteration (PI) planning
release management
SLA
workflow management

Quality Assurance

automatic testing

Security

authentication, SSO, OAuth, 2FA
checkmarx, osa, sast
devsecops
encryption
OWASP
security

DevOps

apache mesosphere
backup strategies
CI/CD
devops
docker
edge computing
geodns
kubernetes
load balancing
logging
networking
service discovery
SRE
static code analysis, sonarqube
storage technologies
virtualization

Cloud technologies

* aaS
aws, azure, google cloud
openstack
serverless

AI

chatbots
computer vision
machine learning
neural networks
tensorflow

Misc

blockchain

Databases

ACID
cloud databases
data science
data visualization
database replication
graph databases
graphql
hadoop
nosql
sql
transactions
data masking
bigquery

General software development

CBD https://en.wikipedia.org/wiki/Component-based_software_engineering
algorithmic complexity
antipatterns in software development
application state management
bugs and debugging
clean code and refactoring
code retreat
code review
coding guidelines (styling, linting)
Compiled vs interpreted languages
data structures: arrays, trees, heaps, tries, hashtable, dictionary, primitives
design patterns
event sourcing
extreme programming
formal languages
functional programming
git
git workflows
hackerrank
IDE
Imperative vs Declarative Programming
llvm
mobile apps
MVC, MVVM
naming things
nocode
low-code
npm
online payment solutions
oop, aop
ORM
pair programming
quantum computing
regular expressions
software disenchantment
software quality
statically vs dynamically typed languages
streams
websockets

Backend developmemnt

API design (public, private)
autoscaling backend services
backend frameworks
CRUD
embedded systems
internet of things
message queues
microservices
monoliths
REST
service mesh
soa

Frontend developmemnt

a/b testing
accessibility
bootstrap
cdn
CMS
CSS frameworks
electron, node-webkit, webview
frontend frameworks (and how to build them from scratch)
HTTP 1, 2, 3, QUIC
PWA
semantic web
SPA
UI design systems
user experience
voice UI
web components
webassembly
webgl
webrtc

Books

Chess and the Art of Enterprise Architecture
Test-Driven Development by Example, Kent Beck
Building Evolutionary Architectures, Neal Ford (local snapshot)
Techniques for Crafting Better Presentations, Neal Ford (local snapshot)
The ThoughtWorks Anthology, Volume 2, Neal Ford
97 Things Every Programmer Should Know, Neal Ford
97 Things Every Software Architect Should Know, Neal Ford
The Productive Programmer, Neal Ford (local snapshot)
Fooled by randomness

Conferences

O’Reilly Software Architecture Conference 🡕
#devdotnext2020 #LeadDevLondon

People

Patrick Kua, tech lead 🡕 Neal Ford 🡕

Blogs

LevelUp Newsletter, Patrick Kua 🡕

Links

https://apiumhub.com/tech-blog-barcelona/user-interface-testing/
https://apiumhub.com/tech-blog-barcelona/microservices-vs-monolithic-architecture/
https://apiumhub.com/tech-blog-barcelona/almost-infinite-scalability/
https://apiumhub.com/tech-blog-barcelona/importance-good-software-architecture/
https://apiumhub.com/tech-blog-barcelona/importance-of-soft-skills/
https://apiumhub.com/tech-blog-barcelona/software-architecture-books/
https://apiumhub.com/tech-blog-barcelona/benefits-of-software-architecture/
https://www.leanix.net/en/enterprise-architecture
https://www.infoworld.com/article/2988671/architecture-principles-considered-harmful.html
https://ea.rna.nl/2015/03/08/losing-a-limpet-what-happens-when-we-dont-have-enterprise-architecture/
https://ea.rna.nl/2017/01/13/agile-architecture/
https://blog.codinghorror.com/so-you-dont-want-to-be-a-programmer-after-all/
https://blog.ndepend.com/mentoring-software-developers/
https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/
https://blog.ndepend.com/code-reuse-not-good-goal/
https://blog.ndepend.com/secrets-maintainable-code-codebases/
https://blog.ndepend.com/code-quality-metrics-signal-noise/
https://www.ndepend.com/docs/code-metrics
https://blog.ndepend.com/5-tips-help-visualize-code/
https://blog.ndepend.com/with-code-metrics-trends-are-king/
https://en.wikipedia.org/wiki/List_of_software_development_philosophies
https://en.wikipedia.org/wiki/Software_development
https://medium.com/globalluxsoft/5-popular-software-development-models-with-their-pros-and-cons-12a486b569dc
https://www.mendix.com/blog/introducing-the-low-code-manifesto/
https://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-cc4b804022e9
https://getstream.io/blog/styled-components-vs-css-stylesheets/
https://blog.pragmaticengineer.com/software-architecture-is-overrated/
https://www.progression.fyi/
https://dzone.com/articles/10-years-of-important-technical-decisions-itds
https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
https://uxstudioteam.com/ux-blog/ux-team-structure/
https://pythonspeed.com/articles/dont-need-kubernetes/
http://strlen.com/treesheets/
https://futureofcoding.org/notes/paval-bazant-5-21-19.html
https://melsatar.blog/2017/04/29/architectural-design-decisions/
https://github.com/elsewhencode/project-guidelines
https://github.com/ryanmcdermott/clean-code-javascript
https://leadership-library.dev/The-Leadership-Library-for-Engineers-c3a6bf9482a74fffa5b8c0e85ea5014a
https://atomicdesign.bradfrost.com/chapter-5/
https://adr.github.io/
https://github.com/donnemartin/system-design-primer
https://github.com/kamranahmedse/developer-roadmap
https://github.com/futurice/backend-best-practices
https://8thlight.com/blog/stephen-prater/2020/09/15/values-rules-break.html
https://12factor.net/
What is extreme programming 🡕
https://doriantaylor.com/the-specificity-gradient

One-liners: The architect ...

makes decisions on things which are expensive to change later
plans everything what the client not asked specifically but necessary for the product (non-functional requirements)
is not always there but an architecture is
shouldn't be always the best developer (who is tend to keep the hard problems for themself)
should code in a daily basis

Phase 2

Architecture

Different architect roles

Software architect (Wikipedia) 🡕

A software architect is a software developer expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.

Architects make high-level design choices based on their programming experience. An architect has thought through all the aspects of a software, just like an architect that builds a house. A construction architect knows where the ducts will be, where the electric connections will be and where the wall outlets will be. A design that a common person sees is just the walls and windows but a detailed design that is abstracted from the outsider are also present with the architect. In addition, the architect may sometimes propose technical standards, including coding standards, tools, or platforms.

Software architects may also be engaged in the design of the architecture of the hardware environment, or may focus entirely on the design methodology of the code.

Architects can use various software architectural models that specialize in communicating architecture.

Architect type	Strategic thinking	System interactions	Communication	Design
enterprise architect	across projects	highly abstracted	across organization	minimal, high level
solutions architect	focused on solution	very detailed	multiple teams	detailed
application architect	component re-use, maintainability	centered on single application	single project	very detailed

Solution architecture (Wikipedia) 🡕

Solution architecture is a practice of defining and describing an architecture of a system delivered in context of a specific solution and as such it may encompass description of an entire system or only its specific parts. Definition of a solution architecture is typically led by a solution architect.

According to Forrester Research, solution architecture is one of the key methods by which enterprise architecture delivers value to the organization. Solution architecture activities take place during solution ideation, solution design, and solution implementation. During ideation, solution architecture establishes the complete business context for the solution and defines the vision and requirements for the solution. During design, solution architecture elaborates potential options, which may include RFIs, RFPs or prototype development. It selects the optimal option and develops the roadmap for the selected solution. During implementation, solution architecture communicates the architecture to the stakeholders, and guides the implementation team.

Application architect (Wikipedia) 🡕

The Application architect is a lead or technical manager in the computer programming team who is specialized in the application built and the technologies used.

An applications architecture describes the behavior of applications used in a business, focused on how they interact with each other and with users. It is focused on the data consumed and produced by applications rather than their internal structure. In application portfolio management, applications are mapped to business functions and processes as well as costs, functional quality and technical quality in order to assess the value provided.

Enterprise architecture (Wikipedia) 🡕

Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

Practitioners of enterprise architecture, enterprise architects, are responsible for performing the analysis of business structure and processes and are often called upon to draw conclusions from the information collected to address the goals of enterprise architecture: effectiveness, efficiency, agility, and continuity of complex business operations.

Everything driven development

Test-driven development (TDD)

Test-driven development (Wikipedia) 🡕 (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the code is improved so that the tests pass. This is opposed to software development that allows code to be added that is not proven to meet requirements.

encourages simple designs and inspires confidence
is related to the test-first programming concepts of extreme programming
helps improving and debugging legacy code developed with older techniques

Benefits

programmers who wrote more tests tended to be more productive
programmers rarely felt the need to invoke a debugger
programmer is concerned with the interface before the implementation
allows a programmer to focus on the task
ensures in this way that all written code is covered by at least one test
gives the programming team a greater level of confidence in the code
more code is required with TDD than without TDD
can lead to more modularized, flexible, and extensible code
they detect any unexpected changes in the code's behaviour

Limitations

extensive use of unit tests required for testing: user interfaces, software that works with databases,
management support is essential
tests may share blind spots or the developer misinterprets the requirements: tests will give a false sense of correctness
false sense of security
tests become part of the maintenance overhead of a project
maintaining an excessive number of tests costs time
tests made with TDD cannot easily be re-created at a later date

Key elements of TDD

Dummy, Stub, Spy, Mock, Simulator

Design-driven development (DDD)

Design Driven Development 🡕 uses design as part of a process to learn and better define requirements in order to build better, more informed technology solutions. It can also be looked at as a process whereby design and user experience drives the development of a product or software application. This leads to products that people enjoy using and want to tell others about.

Using design to learn means allows the business to gain insights to better inform product design and technology decisions before investing heavily in the software development. The design can be in the form a sketch, to a low or high-fidelity mockup, to a clickable prototype or even a quick and dirty coded prototype. Anything you can put in front of a customer to get feedback and better inform what you’re building before you build it.

Without design driven development, it’s easy to build many bad experiences into a product and more importantly, miss the mark with solutions completely. In the absence of design driven development, teams are focused more on building and shipping — often blindly. If product managers and teams are not thinking deeply and analysing what they intend to build and why, they’re coding without a cause.

Feature-driven development (FDD)

Feature-driven development 🡕 (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind the Agile Manifesto.

FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities. In the figure on the right, the meta-process model for these activities is displayed. During the first two sequential activities, an overall model shape is established. The final three activities are iterated for each feature.

Any project can use this method. In other words, that project splits into multiple features; each feature is divided further until it is as small as it can be worked out. Additionally, this is done to ensure that its delivery can happen in 2-10 days.

It is usually applicable to Large-scale projects.

Roles and responsibilities

Project Manager
Software Architect
Development Manager
Dev Lead
Class Owners
Domain Experts
Other Supporting Roles

Practices

Domain Object Modeling
Development by Feature
Individual class ownership
Feature Team
Code/Design reviews
Configuration Management
Regular Deploy
Visibility

Processes

Develop an overall model
Build a feature list
Plan By Feature
Design by feature
Build by feature

Model-driven development (MDD)

Model-driven engineering 🡕 (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing (i.e. algorithmic) concepts. MDD is a key element of the low-code approach.

Instead of writing code you can create models. These models are transformed into source code. You, of course, have to learn how to model, but once you have, all the manual work of writing code is automated.

In Model-Driven Development the model of a software application is specified on a higher abstraction level than traditional programming languages. This model is automatically transformed into a working software application by generating code or interpreting / executing the model. While the used model is on a higher abstraction level it is much smaller compared to the same model expressed in code.

Model-driven development (MDD) leverages graphical models and pre-built application components so that users can visually construct complex applications. Interest in model-driven development continues to increase as individuals experience the ease and speed with which technical and business users orchestrate and deploy business applications. The right model-driven development platform provides significant productivity advantages over traditional development methods and enables project delivery by smaller teams.

There are two core concepts associated with model-driven development: abstraction and automation. The software application model is defined on a higher abstraction level and then converted into a working application using automated transformation or interpretations. The right model-driven development approach leverages model execution at run time, where the model is automatically transformed into a working software application by interpreting and executing the model (removing the need to generate or write code).

MDD Tools

Mendix
Microsoft Power Apps
Appian
Pega platform
Quick Base
Kony Development Cloud
OutSystems
Nintex Platform
KiSSFLOW
Dezyne

Acceptance test driven development (ATDD)

Acceptance test driven development 🡕 (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. All these processes aid developers and testers in understanding the customer's needs prior to implementation and allow customers to be able to converse in their own domain language.

Acceptance tests are from the user's point of view - the external view of the system.

Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about…).

These acceptance tests represent the user’s point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests.

Acceptance tests are a part of an overall testing strategy. They are the customer tests that demonstrate the business intent of a system. Component tests are technical acceptance tests developed by an architect that specify the behavior of large modules.

Test format

Given (setup) - When (trigger) - Then (verification)

Given Book that has not been checked out
And User who is registered on the system
When User checks out a book
Then Book is marked as checked out

Behaviour-driven development (BDD)

Specification by Example

Behavior-driven development 🡕 (BDD) is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

The goal of BDD is a business readable and domain-specific language that allows you to describe a system’s behavior without explaining how that behavior is implemented.

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes.

BDD focuses on:

Where to start in the process
What to test and what not to test
How much to test in one go
What to call the tests
How to understand why a test fails

At its heart, BDD is about rethinking the approach to unit testing and acceptance testing in order to avoid issues that naturally arise.

Title

An explicit title.

Narrative

A short introductory section with the following structure:
As a: the person or role who will benefit from the feature;
I want: the feature;
so that: the benefit or value of the feature.

Acceptance criteria

A description of each specific scenario of the narrative with the following structure:
Given: the initial context at the beginning of the scenario, in one or more clauses;
when: the event that triggers the scenario;
then: the expected outcome, in one or more clauses.

callmemartin / software-architect Goto Github PK

software-architect's Introduction

So you wanna be a software architect?

Phase 1

Podcasts

Ideas, technologies, seeds for a google search

Human factor

Process

Quality Assurance

Security

DevOps

Cloud technologies

AI

Misc

Databases

General software development

Backend developmemnt

Frontend developmemnt

Books

Conferences

People

Blogs

Links

One-liners: The architect ...

Phase 2

Architecture

Different architect roles

Further reading

Everything driven development

Test-driven development (TDD)

Benefits

Limitations

Key elements of TDD

Further reading

Design-driven development (DDD)

Further reading

Feature-driven development (FDD)

Roles and responsibilities

Practices

Processes

Further reading

Model-driven development (MDD)

MDD Tools

Further reading

Acceptance test driven development (ATDD)

Test format

Further reading

Behaviour-driven development (BDD)

Further reading

Domain driven design (DDD)

Example driven development (EDD)

Plan-driven models

software-architect's People

Contributors

Recommend Projects

Recommend Topics

Recommend Org