4 ms·

> Clear goals that we widely communicated allow normal people to make design decisions autonomously. It can really remove the need for constant daily updates an

> Clear goals that we widely communicated allow normal people to make design decisions autonomously. It can really remove the need for constant daily updates and information overload (for you) If you don't mind, could you provide some examples of this ?

WJW 6y 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 6y ago
  How 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 6y ago
    They'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.
KaiserPro 6y ago
These goals should really be unique the company. But as the head architect, its your job to figure out where the company is going and design goals to get them there. A standard problem is monitoring, or more than one way to host/deploy something so good long term goals might be: All services must be on platform p All services must use <<CI system of choice >> All systems must emit metrics according to spec 1.0 system z will be turned off by march 2021, migrate to new system y These goals are clear, measurable and only have one instruction. They are not prescriptive. These goals can be given to the team leads to figure out how to do. You then have to watch them and try and gently steer them away from making new legacy/snowflakes.

WJW 6y 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 6y ago
How 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 6y ago
  They'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.

KaiserPro 6y ago

These goals should really be unique the company. But as the head architect, its your job to figure out where the company is going and design goals to get them there. A standard problem is monitoring, or more than one way to host/deploy something so good long term goals might be: All services must be on platform p All services must use <<CI system of choice >> All systems must emit metrics according to spec 1.0 system z will be turned off by march 2021, migrate to new system y These goals are clear, measurable and only have one instruction. They are not prescriptive. These goals can be given to the team leads to figure out how to do. You then have to watch them and try and gently steer them away from making new legacy/snowflakes.