I’ve been talking with folks who are considering a major upgrade to a key application that impacts core aspects of their business. This project is big enough it is going to take years to complete the implementation. So the first thing I am thinking to myself is how to keep data moving to and from all the other systems from which this system integrates?
Moreover, is there going to be a need for some period of time to synchronize data between the old and new system?
I don’t know what jumps out at you when you hear a scenario such as this. For me, I start thinking Service Bus. The key feature of a service bus is the ability to publish and subscribe to events. Those events are defined by the consumers. And, the events may or may not contain a data load.
What’s especially important here is the fact that the publishers and subscribers are not aware of each other. That means you do not have any tight coupling of systems to anything other than the service bus. In addition, by subscribing to the service bus, you are no longer polling for data changes, or limited to a specific schedule, although both of those capabilities are still available. Instead, a subscriber client can attach to the service bus with an event handler, and be awakened when the bus has a message for the client to handle.
Can you imagine how much simpler this can make the passing of data between systems. Now, even with a legacy and new core application, they can communicate through the service bus, without even being aware of the existence of each other. At least not from a programmatic standpoint. Moreover, as the new system comes online, other applications may subscribe to the events as needed. It may also be possible that the new system can simply continuing publishing messages that used to come from the old system, and the clients are none the wiser regarding the source of the data.
Do you need a service bus? Maybe not. As you continue to add more systems, and they continue to communicate with each other, perhaps a Service Bus is in your future.