Integrating Systems with Event Driven Architecture at JAX London
Two problems I’ve seen a number of times are accidental coupling and poorly defined message semantics.
JAX London is just a few weeks away! In this interview, we speak to Eoin Woods, co-author of “Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives,” about the two sessions he will deliver as part of the Systems Integration and Agile tracks at JAX London.
JAXenter: At Jax London you will present a session on ‘Integrating Systems with Event Driven Architecture.’ What are the common problems to look out for, when adopting an event driven approach?
Eoin Woods: Two problems I’ve seen a number of times are accidental coupling and poorly defined message semantics. The idea of event driven systems is that senders and receivers don’t know of each other’s existence; they just publish and consume events. However what sometimes happens is that events get very obviously tied to systems and mutate into service calls. So the publishers start using the events to implicitly invoke operations and get accidentally coupled to the receivers. Poorly defined message semantics are pretty self explanatory – if you’re going to publish and consume events you need to really understand what they mean, so their meaning needs to be clearly defined, not just their field names and types. It’s quite rare that people take the time to do this and it often doesn’t matter initially, but results in a real mess as the system starts to evolve.
JAXenter: Who should attend ‘Agile Architecture – How Much is Enough?’
Eoin Woods: Everyone! Seriously, the idea behind the session is that “architects” – or “chief programmers” or “lead engineers” or “technical leads” or “system designers” or “systems engineers”, whatever you call them – and agile development teams want the same thing; working, valuable software, in production quickly and reliably, continually evolving. They just seem to want to go about it differently. However, I believe strongly that the differences are mainly style, emphasis and presentation rather than anything fundamental. In this session I have a set of tangible practices for architects to help them work well with and in agile teams. So anyone involved in agile development where there’s also some notion of system design and architecture should find it useful.