The strong and weak forces of architecture

Technology governance and what is considered ‘good architecture’ is mostly considered with a ‘one size fits all’ approach. Many organisations try to apply the same strict governance at all levels – limiting tech choices, and disempowering teams. How do you work out where it’s ok to move faster and ease those requirements?

Teams at MYOB

MyOB has arranged its teams according to well-proven principles for modern digital product organizations

• Teams are aligned to our product capabilities and business capabilities, and are responsible for all aspects of planning, delivery, maintenance, and support for their software and infrastructure
• They are grouped into Domains which bring together related capabilities, with some leadership and enabling roles working at the domain level
• Domains are further grouped into much larger organizational units called Verticals

Integration Patterns

Systems that are owned within a single domain are relatively easy to change in a closely co-ordinated way.

• Even “forbidden” approaches such as database-level integration will have less impact within the systems in one domain if they are integrated within the same domain.

Within a domain = strong forces

For teams within a domain, there is a very strong force of alignment

• Between teams in the same domain, alignment forces are still very strong
• Sharing of knowledge is easy and fluid
• Coupling between systems at a domain level is not always necessary, in fact coupling at this scope can be a useful thing

Shared code and infrastructure

Within a single domain, even across 3-5 teams, there should be high bandwidth communication and a short distance to empowered leadership

• This means that when a change needs to be made to shared code or infrastructure, they can be quickly informed and prepared for the changes

Within a vertical = weakened forces

The social distance between the people in one domain and another is getting stretched. This makes negotiation and reaching alignment more strained and slower, and so necessarily this impacts our technology choices and approaches.

Code Contribution models

Can teams contribute code changes into other team’s codebases to avoid waiting for the other team to do the work?

• Within a single domain, it can be quite reasonable for teams to contribute code across team boundaries, with a type of collective code ownership extending to the whole domain.
• At the whole of org level, it is often quite difficult to effectively manage contributions that cross verticals.

Conclusion

Achieving ‘aligned autonomy’ is no easy feat, and requires constant balancing and adjustment. Being aware of these forces of alignment within our organization allows us to understand what is going to be easy and what is hard, and make better technology choices as a result.

Whole of organisation = weak forces

The force of alignment between the verticals is very weak indeed

• It is quite hard to make changes atomically across the landscape – mostly because the prioritisation of work for each vertical is deliberately independent
• Co-ordinating work at this level is necessarily much slower and limiting

Technology choices

Within a single domain there should be a small set of technology choices agreed. Often this follows Default Trial Retire for each class of technology required.

• At a vertical level there would be a slightly larger set of agreed technology choices, to cater for the differing needs of the multiple domains.

Source