{"id":13558,"date":"2021-08-27T08:00:00","date_gmt":"2021-08-27T06:00:00","guid":{"rendered":"https:\/\/conferences.isaqb.org\/software-architecture-gathering\/?p=13558"},"modified":"2025-04-25T15:09:06","modified_gmt":"2025-04-25T13:09:06","slug":"blog-matt-mclarty","status":"publish","type":"post","link":"https:\/\/conferences.isaqb.org\/software-architecture-gathering\/blog-matt-mclarty\/","title":{"rendered":"A Visual Language for Systems Integration: An Interview with Matt McLarty"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t

Blog<\/h2>\n\t\t\t\t\t\t\t\t\t\t\t\t

iSAQB Software Architecture Gathering<\/p>\n\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/section>\n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\"Matt\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Matt McLarty<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Global Leader of API Strategy at MuleSoft, a Salesforce Company<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Published On<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
August 27, 2021<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

A Visual Language for Systems Integration: \nAn Interview with Matt McLarty <\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tYour talk<\/a><\/span>\u00a0is titled “A visual language for systems integration.” What does “visual language” mean in this context?<\/strong>

\n\nI’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 \u2014 as a creative field \u2014 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<\/span><\/a>‘s work, and\u00a0Simon Brown<\/span><\/a>\u00a0has done a tremendous job articulating and providing tooling for his\u00a0C4 model<\/a><\/span>. So I think visualization is essential for our field.

\n\nIn 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.

\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tWhy is a visual language needed for integration?<\/strong>

\n\nI’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.

\n\nI 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\u00a0Gregor Hohpe and Bobby Woolf<\/span> \u2014 <\/a>and composition patterns–aggregation, orchestration and choreography. The visual language is defined in this blog series<\/span><\/a>.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In the C4 model for visualising software architecture, different levels of zoom allow you to tell different stories to different audiences. (courtesy c4model.com)<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tWhat problems could\u00a0this visual language help solve?<\/strong>

\n\nFirst 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.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tYour\u00a0title is “Global Leader of API Strategy”… Do you consider yourself a software architect?<\/strong>

\n\nI’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<\/a>.” 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 \u2014 and their organizational models \u2014 which are homomorphic with the underlying systems as per the aforementioned Conway’s Law.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Are there other talks you’re looking forward to at the event?<\/strong><\/p>

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\u00a0workshop on online retrospectives<\/a><\/span>. She is a superb speaker and always has an interesting perspective. I mentioned Simon Brown earlier, and he’s giving a talk on\u00a0software design<\/a><\/span>. James Lewis is one of my favourite conference speakers, and I recently re-read\u00a0Team Topologies<\/a><\/em><\/span>, so I can’t wait to hear his take on\u00a0software architecture, team topologies, and complexity science<\/span><\/a>. Anyone interested in software architecture should definitely attend the event! Thanks again for the opportunity to be part of it.

<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Session by Matt McLarty:<\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

A Visual Language for Systems Integration<\/a><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\tReturn to Blog Home Page<\/span>\n\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/a>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Stay up-to-date with the SAG newsletter<\/h5>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n
\n
\n \n \n \n
<\/div>\n \n <\/div>\n<\/form>\n<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Stay up-to-date with the SAG newsletter<\/h5>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\n
\n \n