3 ms·
Some examples: - Because 5 out of 6 outages the last month were related to simple regressions, we have decided to improve automated test coverage. Every servic
by WJW 7y ago
Some examples:
- Because 5 out of 6 outages the last month were related to simple regressions, we have decided to improve automated test coverage. Every service must have at least 90% unit test coverage and at least 1 integration test for every happy path before the end of the year.
- We will turn off supporting system XYZ at date ABC because of reason DEF (say, it violates GDPR and we don't want that liability). The recommended replacement is system GHI. All teams that use system XYZ must migrate off it before ABC - 1 month and provide a clear plan before ABC - 4 months.
- Market research indicates that potential customers recognize that we have a lot of features, but they perceive us to be slower and this is causing them to prefer competitor X. We want to win this customer group and therefore: 1. Every new feature from any team must be benchmarked to ensure it does not impact speed-related metrics A and B (time to first paint, for example) 2. Teams X, Y and Z should spend about 50% of time this quarter identifying and fixing performance issues.
- Example from the navy: We know based on intelligence reports that the enemy has no submarines and has recently acquired a big batch of air-to-surface missiles. Therefore, when choosing priorities for repair, anti-air system have priority over anti-submarine systems.
Important for autonomous decision making is not just communicating the priorities, but also WHY those priorities were set. In the navy example above for example, knowing why anti-air is more important can further guide personnel into choosing properly, since there might be systems officially classified "anti-air" that are not useful against air-to-surface missiles but only against helicopter or whatnot. The military calls this extra communication "commanders intent". Of course, letting people make decisions autonomously requires trust on both sides. It is worthwhile to invest in this.
- rswail 7y agoHow are these goals the responsibility of an architect. These are operational requirements that might need changes in a system's architecture, or adaption of interfaces. All of these are requirements, not architecture. Architecture is about satisfying those requirements along with all the others in a cohesive and structured way. My guiding quote is "Design is about constraints" from Charles Eames. Find and explore those constraints and you will be able to determine the architecture.
- WJW 7y agoThey're intended as "Clear goals that we widely communicated allow normal people to make design decisions autonomously" as per the parent post. In any case, architecture can be just as much about setting the constraints as it is about discovering them.