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 Woolf — and composition patterns–aggregation, orchestration and choreography. The visual language is defined in this blog series.