VERY EARLY BIRD UNTIL SEPTEMBER 5: ✓ Save up to €200 ✓ 10% Team Discount ✓ 15% CPSA Discount


iSAQB Software Architecture Gathering — Digital 2021

A Visual Language for Systems Integration: An Interview with Matt McLarty

Your talk is titled “A visual language for systems integration.” What does “visual language” mean in this context?

I’ve been working in the software architecture field for a couple of decades now, and one of the consistent issues I’ve seen through that whole period of time is a lack of agreement on how architectures should be visualized. This is interesting to me, since — as a creative field — one would think that architecture’s natural expression would be through visual models. The good news is there is lots of published thinking in this area, and the idea of having consistent visualizations as part of our discipline is now getting some attention. I have long been an admirer of Ruth Malan‘s work, and Simon Brown has done a tremendous job articulating and providing tooling for his C4 model. So I think visualization is essential for our field.

In terms of a “visual language,” I see this as a collection of related concepts that can be expressed consistently in a visual way. UML is certainly a visual language. Context mapping in Domain Driven Design is a visual language. I think that the human mind is more efficient in creating visually in many cases than verbally or through text. It’s why architects love whiteboards so much.

Why is a visual language needed for integration?

I’ve been working in application and systems integration for even longer than I’ve been an architect, and this is definitely a domain that screams for visualization. The good news is that people do generally represent their integration architecture through diagrams. The problem is, they often express those architectures at wildly uneven levels of focus and granularity–often within a single diagram! Because there are so many layers to integration, you might see a diagram that mixes high level user personas with abstract remote channels with network protocols with opaquely-named applications with database instances and physical server addresses. It can get quite messy, and obscure the information that could actually be helpful in designing the integration approach.

I wanted to create a simple language that would hide much of the unnecessary complexity, and allow architects to focus on the essential complexity of the problems they’re trying to solve and the business domains involved. The core of the language focuses on interaction types between components, namely “commands, queries and events.” I also include message exchange patterns–influenced heavily by the work of Gregor Hohpe and Bobby Woolfand composition patterns–aggregation, orchestration and choreography. The visual language is defined in this blog series.

In the C4 model for visualising software architecture, different levels of zoom allow you to tell different stories to different audiences. (courtesy

What problems could this visual language help solve?

First off, I think this approach is a good way of understanding your current integration landscape. What patterns exist? Why is integration done that way today? Are they the right patterns? It’s also useful in mapping out new solutions. I find it to be a particularly helpful way of fleshing out more detail in DDD context maps, especially when projecting user experiences on to that picture. If you can get the patterns right, it helps guide the implementation decisions. It works much better if you can be intentional about the design choices, rather than backing into an approach based on some pre-ordained technology choice. Even if you have to make a compromise, at least taking the step of modeling the ideal approach lets you know it’s a compromise that could be rectified in the future.
Your title is “Global Leader of API Strategy”… Do you consider yourself a software architect?

I’ve been a software architect most of my career, in the sense that I am architecting solutions and systems involving software. I started out as a developer connecting payment systems together, and have always been fascinated by the bigger picture beyond my current scope, something Mel Conway calls “the containing system.” So I moved from developing integrated systems to designing them. And from designing domain systems to enterprise approaches. As the importance of software has increased in all areas of business, I now work with business leaders and corporate leaders to architect their digital business models–which are intrinsically tied to the enabling software — and their organizational models — which are homomorphic with the underlying systems as per the aforementioned Conway’s Law.

Are there other talks you’re looking forward to at the event?

This Software Architecture Gathering has an incredible lineup! You truly have assembled the who’s who of the software architecture field. Some highlights for me will be Aino Vonge Corry’s workshop on online retrospectives. She is a superb speaker and always has an interesting perspective. I mentioned Simon Brown earlier, and he’s giving a talk on software design. James Lewis is one of my favourite conference speakers, and I recently re-read Team Topologies, so I can’t wait to hear his take on software architecture, team topologies, and complexity science. Anyone interested in software architecture should definitely attend the event! Thanks again for the opportunity to be part of it.

Stay up-to-date with the SAG newsletter
Stay up-to-date with the SAG newsletter