Technical Architecture
Edit on GitHubDefines how granular software components are engineered and organized together to achieve the optimal delivery of the features in demand. The architecture is mainly governed by the product requirements. It’s moderated by industry best practices associated with the selected technologies, services and relevant regulations.
Why
Technical architecture defines and justifies the decisions and constructs of the underlying platform of the software product. It includes functional and non-functional considerations and constraints, tech-stack selection, platform selection, architecture diagrams, deployment model and DevOps process.
How
Requirements as your starting point
Always begin from the requirements, not from a pre-conceived architecture blueprint. For this you need to identify the 'architecturally significant' functional and non-functional requirements of the product. Requirements where the 'cost of change is high' are considered architecturally significant and those should be determined at an early stage of the process to minimize rework.
- Understand the business requirements
- Understand the constraints
- Understand the stakeholder concerns and preferences
Quantify using Quality Attributes
Now, you must translate the requirements into a measurable set of quality attributes. You can find a comprehensive list of quality attributes to pick from here.
Employ architectural-styles and design-tactics
Decide the architecture styles and design tactics to be used to fulfil the quantified quality attributes. Be aware of the possible tradeoffs and conflicts that can arise from using different tactics. For example, tactics used for high security may impede usability and performance.
Defer decisions as appropriate
If you don’t have enough knowledge to make a decision, consider the possibility of deferring. Not all decisions can be delayed (deferred), especially the ones with a high cost of change. An example of this is the choice of 'programming language' and 'cloud native platform'. But there are some decisions you can delay until more knowledge is available. For example, the database system. You can use a dummy in memory DAL layer until you really require persistence.
Create architecture views
Develop different views of the developed architecture to better communicate concepts. For example, the runtime behavior of a system cannot be explained through a view depicting how the solution code is organized. There are different documentation standards to consider including the popular 4+1 model.
Living architecture
Technical architecture is not something you do just at the beginning of a project. Architecture is a living document and should be handled in an agile manner. Check out Architecture Runway to understand how this should be practically executed within a project.
Validating the architecture
Consider the derived architecture as a set of assumptions that are not verified until tested for the purpose. Use early and frequent MVPs and POCs to validate the architecture regularly. Refer to the topic Architecture Blueprint for further details.