Matt Waldron

Since joining the team at Xero, there have been many discussions on what our future architecture should look like. Once we had a good design with a good understanding of the decisions it was time to communicate the ideas to the team and, in particular, engineering.

The designs involved domain modelling workshops, eventually consist experiences, messaging and eventing. We needed to convey the benefits and challenges of these patterns. But there are some knowledge gaps with some of these concepts.

Engineers bring a different perspective to architecture, but an important one.

How best to convey our intentions and ensure the engineering team had an solid grounding with the concepts enabling them to measure value and contribute changes to the design?

We started analysing the high-level topics and preparing for a journey we could go on as a team. With architecture presenting high-level concepts to the broader team. Each high-level topic would have a series of detailed presentations done by the engineering team within their community of practice.

While this was in flight, we were also finalising our architecture for a consistent first cut using C4. We also began preparation for regular catch ups with engineering, with the intent of adding AMAs (Ask me Architecture sessions) and printing out copies, sticking them up clearly visible to the team to facilitate conversations.

Once you know where you want to go, determining the best way there can be even more time consuming.

So everything was in place to get from current state to desired state except the route to take. Low hanging fruit and dependent changes needed describing so we could begin defining our milestones in this journey.

After aggregating reasonably similar changes into milestones, which could form projects for engineering, I wanted to clarify the process the team would undergo to begin those projects.

This led to clarifying a change process. Given a particular type of change to the system - architectural projects - engineers would know the appropriate stakeholders to include and ensure the system evolved toward the future vision.

The summary here is that, even though there may be a clear vision of the future, enacting that vision can require as much effort if not more.

In the future, I’ll discuss methods to promote autonomy and alleviate some of this pressure from architecture.