Event-Driven Architecture Maturity Assessment
First experiments show great results —
now it’s time to get moving
At this maturity stage, it's common for IT architects, developers and data scientists to describe their organization’s approach to Event-Driven Architectures as:
Description
Early experience with event processing begins to teach the application architects and business users of the potential advantages and special capabilities of event-driven design. Developers have been designing request-response APIs — whether newer REST-based APIs or older SOAP web services — for many years.
A large body of knowledge exists on how to design effective APIs. However, compared with request-response APIs, typically those leveraging event-driven IT are not as well understood by developers.
Partly, this is due to the lack of tooling. Full lifecycle API management products typically include the ability to design request-response APIs, but not similar development tools to create APIs using event-driven IT, using technologies such as webhooks, SSEs and HTML5 WebSockets. Another important factor is that an orientation towards EDA requires a different thinking in the ability to support traceability, failure paths, scaling and explanations about why things have gone wrong.
Recommended Action
Once you get the first quick win with a running event stream for example, between legacy systems and modern microservices), you can start to connect more sources to your streaming architecture.
You can now give access to the information to as many systems or lines of business as you want without ever worrying whether if or how you do so will affect the core systems or others accessing them. This can make a huge difference to your business as it fosters innovation by making it far easier to access this information.
Consider using a data integration tool or Kafka APIs that connect easily to all your sources and targets. Also consider data integration tools that can scale to handle complex transformations of data in flight without incurring significant latency.
Description
For your growth, you need to identify and implement best practice in your business to make it stand out from your competition and to accelerate success. There are specific factors that help organizations with the process of sharing best practice.
Sharing best practice is one of the great ways of initiating a learning environment in an organization. Consider doing this through knowledge-sharing tools and intranet networks.
Recommended Action
To underline further the value of EDA, successful projects by teams should be highlighted. Ask colleagues from these teams to share with you the processes that contributed to their success. What tools did they use? How did they collaborate to produce and manage event streams?
Best practice should be documented in detail and shared with other teams. Be aware: organizational and cultural challenges are likely to arise in this phase as well — document when and where these problems occurred as well as how they were solved.
Additionally, it’s important at this time to form some governance principles in order to build the foundation for a future central governance team.
Description
In this phase, you should have already completed successfully your first experiments or use cases with EDA architectures. It is important now to be able to differentiate between two of the most popular topologies. According to Mark Richards, author of the book Software Architecture Patterns published by O’Reilly, these are either based around a mediator or a broker.
The mediator topology is used mostly when you need to orchestrate multiple steps within an event. A broker-centered approach is usually used when you need to chain events together without using a centralized approach, as with the mediator.
Because each of the two architecture patterns come with different benefits and disadvantages, it is important that you understand each one to know which is best for your use case.
This also applies to different types of platforms. Despite the intended general use for the selected event technology, one single vendor’s platform is unlikely to fit all purposes, so different use cases may lend themselves to the selection of multiple technologies across the organization.
Recommended Action
Use Open-Source integrations such as Apache Camel, Mule ESB or, if you need more enterprise-capabilities with advanced monitoring or a low-code-approach, platforms like Xapix. More sophisticated use cases with event brokers are best served with Apache Kafka and RabbitMQ, two open-source and commercially-supported pub/sub systems.
Be aware if different teams select a separate broker for their specific use case without considering a future integration. They might face the need for integration later on which can be very complex and cumbersome.