Architecture principles
Architecture Principles are key to relieve the gatekeeping burden from the Architect, and be able delegate specific decisions to the teams, offering more autonomy. BUT there’s a second layer below the principles, which is the SPECIFIC/CONCRETE process that ALSO needs to be put in place to garantie that governance artefacts are produced, e.g., System scoped documentation with both context and components maps/diagrams.
Principles I find useful
Create principles as a living artefact (inspired by Thoughtworks P1)
The principles should be a go-to document for dev teams, so ideally in mark-down and shared in a repo with version control and all.
Enlist gatekeepers as collaborators (from Thoughtworks P3)
“Instead of structuring an architecture team as a group of gatekeepers who issue opaque mandates, a better approach is to use that group as consultants, coaches and advisors for teams that get engaged early on in the process. They can be articulating the organisational principles and constraints, but should also be helping teams figure out how to meet them. This leads to better two-way learning, and also can be a good connection point for spotting good ideas or tools to reuse elsewhere. The architecture group can help with evangelising these harvested items.”
Code documentation principles/best practices
- Minimum Viable Documentation. https://google.github.io/styleguide/docguide/best_practices.html
Good reads on Architecture principles
https://www.thoughtworks.com/insights/articles/lightweight-technology-governance