The strong and weak forces of architecture

Technological governance and what is considered ‘good architecture’ is mainly considered in the ‘one size fits all’ approach. Many organizations try to implement the same strict management at all levels – limiting technological possibilities, and sculpting teams. Others allowed teams full autonomy at all levels, meaning that teams were left to make their choices without any restrictions at all. None of these approaches are ideal.

Taking a specific example, we have long seen integration architects striving for a ‘true one’ integration approach at all levels of architecture. They indicate ‘recommended practice’, which requires extremely loose coupling, backward-compatible interfaces, and careful encapsulation for any systemic interaction at all levels. This universal approach has created a lot of unnecessary complexity and delay in many cases – but how do you know where it is okay to move faster and ease these requirements?

Teams at MYOB

B MYOB We have arranged our teams according to well-proven principles for modern digital product organizations. The teams are tailored to our product and business capabilities, and are responsible for all aspects of design, delivery, maintenance and support for their software and infrastructure.

The teams are grouped by Domains That bring together related capabilities, with a certain leadership and enabling roles that operate at the field level. Areas are further grouped into much larger organizational units called Vertical. The industries represent a major segment of our customer base.

There is much more to it of course, with supporting functions and internal platforms that provide scaffolding for the entire organization to deliver efficiently. However, this simple model is useful for logic regarding technological governance.

In this article I would like to explain how this structure informs about our technological choices and our design decisions, when different potential approaches are appropriate depending on the scope (or ‘explosion radius’) of the decision. The conceptual model I like is the gravitational pull between different parts of the organization.

Within a field = strong forces

Within a field we have several teams, each responsible for several basic capabilities and systems within the field. Sometimes it is perfectly aligned, with each team maintaining a carefully arranged array of systems. More often it is not perfect in reality, when the guardianship of certain systems is shared between teams – often for reasons of previous generation. For teams within a field, there is a very strong power of alignment.

The domain structure is designed to bring together cohesive systems in their functioning – they are closely related, they deal with the same concepts, they rely on shared domain expertise, and they often change at the same time to meet a customer’s need. .

Individual team members typically work in the same systems, and therefore need a clear and very happy way of working, standards, technological choices and design directions. This is the most powerful force of alignment.

Among teams in the same field, the alignment forces are still very strong. Sharing knowledge is easy and fluid. Negotiating system interactions such as schemas is relatively very easy. When it comes to providing a feature that crosses systems in the field, often the same people have implemented ‘both sides’ of each integration point.

This means that the ‘private’ interactions between systems within a domain – API calls, events, data files – can be more closely coupled without such a severe cost. By providing a tighter coupling, we can reduce the amount of effort going through versions and backward compatibility and avoid joint dependence. Coupling between systems at the domain level is not always the bad monster to be won at any cost, in fact coupling to this extent can be a useful thing.

Within vertical = weakened forces

In the middle of the road we have our vertical structure, with several areas. The social distance between people in one field and another is stretching. This makes negotiations and reaching alignment stretch and slower, so it inevitably affects our choices and technological approaches.

The whole organization = weak forces

When we zoom out to the whole organization – the alignment power between the verticals is indeed very weak. It is quite difficult to make atomic changes across the landscape – mainly because the work preference for each vertical is intentionally independent. Work coordination at this level is necessarily much slower and more restrictive. This means that our design decisions and approaches need to be adjusted accordingly.

How is this model applied?

Let us make this model more concrete by examining certain areas of technological decision-making that may vary according to their scope. The list below is not intended to be exhaustive – just a few interesting examples to consider.

Technological choices

How do we control the life cycle of technology choices?

Domain (strong power)

Within one area there should be a small set of agreed-upon technological options.

This often comes after retiring a default trial for any type of technology required.

Informal governance through technological leadership is usually highly effective.

Vertical (weakened force)

At the vertical level there will be a slightly larger set of agreed-upon technology options, to satisfy the different needs of the multiple domains.

It is beneficial for the vertical to be able to bring people closer to high priority work, so it is important to maintain a fit for technology here.

More formal sharing of options and suggested solutions maintains effective choice of choices.

The whole organization (weak power)

The weakest force to align and conduct technological choices is at the entire level of the organization.

MYOB technology radar sets direction in terms of preferred technologies.

Options and suggested solutions encourage dialogue and improve alignment.

Common code and infrastructure

Can we share reusable code bases and directories? Can we share infrastructure to reduce duplication?

Domain (strong power)

Within one area, even across 3-5 teams, we should have high bandwidth and short distance communication for enhanced leadership.

This means that when it is necessary to make a change to a common code or infrastructure, we can quickly notify and prepare for the changes.

Couplings introduced by shared code and infrastructure have less impact, and the benefits often outweigh the costs.

Vertical (weakened force)

Code sharing, artifacts, and infrastructure can usually be managed vertically – but the towbar must be carefully monitored.

The whole organization (weak power)

Common code at the whole organization level is limited to very stable, very useful things. Most of these things are limited to libraries that can be distributed and changed carefully.

Similar common infrastructure – At a pan-organizational level, a common infrastructure must have a very high value, and be well-encapsulated (“competency”, self-service). Very rarely it needs a core change in response to the need for a single team.

Code donation models

Can teams contribute code changes to other teams’ code bases, to avoid waiting for the other team to do the work?

Domain (strong power)

Within a single domain – with high degrees of compliance in terms of working methods and technology – it can make quite a lot of sense for teams to contribute code across team boundaries, with a kind of collective ownership of code that spans the entire domain.

The guardianship of each system still needs to be clearly understood, usually worth keeping in one team.

Vertical (weakened force)

Within vertical it is accepted that code contribution occurs across systems, for example pull requests in source control – when only small amounts of delay and rework are required.

The whole organization (weak power)

At the organization-wide level, it is often quite difficult (and sometimes detrimental) to effectively manage cross-vertical donations.

This is especially true when systems are complex in nature, critical or highly sensitive in terms of accuracy, performance, privacy and compatibility.

When brand new system features are established, it can work well to collaborate between verticals and even perform pairing programming together. However, as features become established and demand for changes from other industries increases, investment is required to make these systems safe to expand and configure. These changes are often architectural in nature – separating the ‘core’ from complex subsystems and introducing modularities to facilitate expansion management.

Integration patterns

How do we connect systems together?

Domain (strong power)

Systems owned by a single domain are relatively easy to modify in a tightly coordinated manner. For example this means that it takes (a little) less effort to maintain backward compatibility of interfaces.

Even ‘forbidden’ approaches like database-level integration will have less impact within single-domain systems. Although it is not advisable to build a system intentionally, if it exists then we can contain the impact within one area.

Vertical (weakened force)

Changes that must be coordinated across multiple domains within a vertical should be rare, but can be managed when absolutely necessary. Contract extension Changes to API contracts It is quite effective when the effects are included within the vertical.

The whole organization (weak power)

Interfaces and APIs (e.g. events) published in each MYOB must receive the highest attention to published schemas, version control, backward compatibility, contracts and usage strategy.

The impact of high-integration integration (e.g. ETLs, database integration) is very high, and should be completely avoided.


In any organization on a non-trivial scale many dozens of technological decisions are made every day. We strive for many years to enable and empower teams to make decisions closer to work, without strict centralized governance on every decision. Achieving ‘aligned autonomy’ is not an easy feat, and requires constant balance and adjustment. Simple models can help teams understand how to make good decisions in context. In this article I described how at MYOB we aligned our technological governance approach to our organizational structure and dynamics. Aware of these matching forces within our organization allow us to understand what is going to be easy and what is going to be difficult, and make better technological choices as a result.




Please enter your comment!
Please enter your name here