This framing comes from a source that I do not recall. I am writing it down because the core idea is worth keeping. I am happy to remove this page and credit appropriately if the original source is found
Product design and development needs strong engineering and architecture. The two are complementary, but they are not equal partners on separate org charts. Architecture is a subset of the overall engineering effort.
The trap on both ends is the amount of design done up front. Doing too much design before any code is poor practice and tends to fail. Doing too little design also tends to fail. The goal is the middle ground that optimizes how the team works and delivers.
The problem
Treating architecture as a standalone function, independent of engineering, is an archaic way to build software. It runs counter to the goals most teams claim to set for themselves. It produces a predictable failure mode. The engineers go stagnant. They do little independent thinking and wait for instruction from whoever holds the architect role.
That is a waste on both sides. The architect becomes a bottleneck. The engineers never grow into the harder problems.
The objective
Fold the architect role into the engineering team. Let it transition into a technical lead role rather than a standalone architect role. The point is to optimize how the team works and delivers, not to preserve a title.
Ground rules
- Engineering owns development and delivery of all features and products.
- Architecture works inside the engineering teams. It acts as a consultant, an advisor, or a technical lead based on what the project needs.
- The architect supports engineering at the direction of the engineering lead.
What architectural design is, and what it is not
The architect makes the significant, relevant decisions. There are two kinds.
- Technology choices. Programming languages, frameworks, protocols, products.
- Structure. Decomposition strategies, modularity, functional boundaries.
The architecture should let the team understand three things: what they will build, how they will build it at a high level, and whether the design will work, both on its own and within the larger system.
Architectural design is not designing every API and attribute. It is not the length of each column in a table. It is the high-level patterns and the context. The engineering team designs the lower-level details from that context to deliver the product vision.
Who does what
The split below is the heart of the model. Architecture sets direction and reviews. Engineering owns the build.
| Function | Architecture | Engineering |
|---|---|---|
| Design | • Define and document the overall system and data architecture • Design high-level technology solutions and build prototypes and POCs • Recommend the platform technology stack • Provide input and guidance on technical requirements: security, performance, maintainability, scalability, usability, reliability • Help draft user stories for the technical implementation of a design • Review the engineering team's low-level designs and give feedback on improvements • Identify and mitigate technical and architectural risks |
• Review and interpret the high-level architectural design • Work with architecture to operationalize and enhance the POC efforts • Own technology and implementation decisions • Perform low-level design for APIs, interfaces, and all aspects of implementation • Use the architect for analysis, research, and guidance on enhancements and implementation decisions • Decide and implement the technology stack and vendor choices, based on inputs from architecture |
| Development | • Lead design workshops with the engineering team, focusing on the team's understanding of the feature, the high-level design, and the interface specifics, so the team leaves ready to focus on low-level design • Support estimation, T-shirt sizing, and level of effort • Embed with the engineering team to develop and deliver a feature • Act as a technical lead, coach, and mentor, especially for junior engineers • Act as the right hand or consultant to the engineering team lead |
• Own sizing and estimation of efforts • Define and deliver the implementation of a feature or fix • Draft user stories • Write code, unit and integration tests, and perform code reviews • Automate deployment and the CI/CD pipeline |
| QA | • Support triage of issues and defects that have architectural or design impact | • Pull QA in early during story development • Work with QA to document and resolve defects and issues |
| Deployment and launch | • Support all deployment and launch activities as on-call support, ready to help triage if issues arise | • Lead all deployment and launch activities as deployment leads and on-call support, ready to help triage if issues arise |
| Non-delivery functions | • Evaluate the best available technology for the platform • Attend planning, scrum, and demo ceremonies as an observer, unless actively developing a feature • Attend grooming as an active participant, helping clarify user stories and technical requirements |
• Lead planning and demo ceremonies • Identify and implement development process improvements |
| Artifacts owned | • High-level physical and logical architecture diagrams, at the right level of detail • High-level sequence diagrams • Network diagrams • Security architecture diagrams |
• Low-level architecture diagrams • Low-level sequence diagrams |
The takeaway
Architecture and engineering are not rivals, and they are not separate departments. Architecture is the high-level subset of the engineering effort. When the architect works as a technical lead inside the team, the engineers think for themselves and the architect stops being a bottleneck. That is the middle ground worth aiming for.