Strong and Weak Forces Domain Driven Architecture at MYOB

Evan Bottcher is the Head of Architecture at MYOB. This article by Evan discusses strong and weak forces in domain-driven architecture.

MYOB has been around for more than 30 years. It has made a major change from being dated and difficult to work with Windows desktop product to being fully online cloud-connected. It has moved beyond core accounting features into having a broader set of business management features that people use to run their businesses.

There are different ways how people approach APIs. Some are completely autonomous and are free to make their tech decisions. On the other hand, some have a strict prescription for what you can do.

Standardization at MYOB

At MYOB, we have three capability tiers – Product, Customer, and Business and Technology.

At the top, we have product features that our customers use every day. In the middle, we have our customer and business capabilities to sell our products and manage our business. And then we have technology capabilities underneath. We use a building block called Domain. It’s a cohesive unit of capabilities. A domain represents a grouping of things, data, user interface, processes, people, and systems. You build it; you own it; you run it but within a boundary. Within the Domain, we have agile and DevOps teams that plan, build, run, and support software. Having these domains, and having them well defined and long-lived, allows us to concentrate our expertise, bring together systems and deduplicate and manage that technology estate within a meaningful business construct. It allows us to align on technology. It allows for reuse, although reuse isn’t necessarily the upfront goal of the consolidation.

We compose those domains into what we call verticals. These generally relate to our customer segment, particularly in our product space. So small and medium enterprise customers have a segment to vertical. And there are leadership teams and structures to help people align and work towards their goals and then manage the estate.

So, now that I’ve given you a bit of a building block and constructs, I want to explain how that impacts the way we do governance and standardization.

The strongest force starts when you have a team that works together every day; they have lunch together, work under the same leadership, they are aligned on goals they’re working together. They have a very strong force of alignment that they will be able to align easily. That same strong force applies to teams within a domain.

For domains in a vertical, it is a slightly weaker force. They’ll have separate planning cadences and need to negotiate over anything they need to do together or any change that impacts those verticals. But they also have shared leadership who can arrange those things, and they have shared goals and all those things that modern organizations have to try and establish that alignment.

We have strong forces within a domain, and you have the same group of people who usually work across domains where systems connect together. You have the ability to loosen or lower your level of scrutiny over how systems are connected together. You don’t need to negotiate a contract with someone and then retain it for a long period, usually implementing a feature that covers both systems. The standards are that the discoverability of schemas etc. is reasonably private to those domains. Domains can work with those productively where we have weakened forces between our domains. If this is in the same vertical, we must increase our scrutiny of how these things work together. The domains might be operating differently in terms of technology and processes. To compensate for those differences, we must increase our standardization level. At MYOB, we are trying to have fewer technologies and higher scrutiny around standards, schemas, discoverability, and registry in our system catalog, managing the way we provide backward compatibility and versioning.

When we go to MYOB or out into our partner ecosystem, we have a lot of organizational distance between the different domains that might be participating in connecting systems and delivering useful things. If you’re one of the platform areas of our organization, if you publish something, you might as well consider it to be forever; your deprecation cycles will be very long. So, take a lot of care around how they are presented and how you manage change in those in those APIs.

We don’t always get the boundaries in the right place, especially when going through a transformation. You sometimes need to shuffle things, merge things and split things. There will be reengineering.

To summarize, one size fits all for governance and standardization is not the right thing. It can stifle our speed and innovation. As leaders in technology, we need to be aware of these forces, the organizational dynamics, and how that affects how we run our systems and govern them. Through design and change, we should focus our standardization effort where it matters most to help overcome our organization’s weak forces, and that will lead to better outcomes and faster delivery or use.