A Simple Analogy to Illustrate the Power of Event-driven Architecture
Blog: The Tibco Blog
Reading Time: 4 minutes
If you have been following the blog, you have probably read about event-driven architecture at one point or another. If you’ve wondered what exactly event-driven architecture is, then you’re not alone. Let me explain with a simple analogy.
Suppose you walk into a local branch office of your bank. You have several tasks you want to accomplish on this visit: withdraw money from your savings account, refinance your mortgage, remove baseball cards from your safe deposit box, and take out a car loan (yes, this is a lot to do in one visit, but stay with me). So you first visit a bank teller, ask for money from your savings account, and wait for a bit until they give it to you. Then you’d see a safe deposit box officer, ask for your baseball cards out of your box, then wait a bit again. And so on until all of your tasks are complete. Obviously, your trip to the bank involves a lot of waiting and a lot of blocking—you can’t start a new task until your current task is complete. Let’s call this “response banking.”
Your time would be better spent if you could walk into your bank and drop request forms into boxes that said something like “withdraw $50 from savings account 12345 submitted,” “request for baseball cards out of safe box 345 submitted,” etc. Let’s call each of these pieces of paper an “event.” Now, instead of waiting and blocking on each individual task (event) before moving on to the next one, you can submit them all at once into the boxes (event bus). And while they are being serviced, you can do something productive—like sit in the lobby and read old magazines. Seriously, since all of your requests are submitted nearly simultaneously, your wait times are significantly reduced, and you can complete all your banking requests in far less time. When each of your tasks (events) is complete (serviced), you’d be notified (more events) and provided with the outputs you requested. Let’s call this “event-driven banking.”
Benefits of Event-driven Banking
The obvious benefit of event-driven banking is that the overall experience with your bank is not only more productive and efficient for you but also more engaging. You don’t have to wait and do nothing while each of your requests is serviced one after the other. Instead, you can do something else while each is serviced in the background all at once.
However, there are many other benefits, specifically for the bank. When you select a specific teller to service your task (event), for example, you become highly dependent upon that person. When you depend on something specific, you are tightly coupled to it. It then makes it hard for the bank to respond to your task with flexibility—such as selecting the teller with the right skills and bandwidth to respond to your request at that moment. This is a key tenet of software development: tight coupling creates rigid architectures. Tight coupling makes it hard for the bank to choose how to respond to your request. Event-driven architectures are more loosely coupled.
Also, when the bank is driven by events, it can look at all of the various events that transpire over a period of time, find correlations, and take specific actions. Events can be any action that takes place across the banking ecosystem, such as a change to an account balance. There obviously could be a large number of events that occur, and not all will be interesting to the bank. As a simple example, when a customer applies to refinance their mortgage and then pays off a bank credit card, these two events could create a new event through a business rule that automatically offers the customer a personal loan through their mobile device at a special rate. The banking architecture is flexible enough to add enhancements like this quickly and easily. There are all sorts of ways that a bank can understand and take action on the large volume of events that occur in its ecosystem—such as via business rules as well as by using artificial intelligence to determine appropriate actions.
A Real World Example of Banking with Event-driven Architecture
In fact, the Bank of Montreal is one example of a bank that successfully implemented an event-driven architecture to improve the customer experience. The bank realized that customers wanted more personalized interactions and that current bank offers were outdated and not meeting customers’ needs. By implementing an event-driven architecture with TIBCO event processing and messaging capabilities, the Bank of Montreal can take customers’ event data and provide them with personalized mortgage offers, personal loans, credit cards, and more. This led to an offer acceptance rate three times higher than before.
Event-driven architectures not only create more engaging and productive experiences for your clients but also are more flexible and adaptable to change and help your business understand and take action on the important digital events that surround it—ones where there is an opportunity to generate new business, or better satisfy a customer, for example. The concepts that motivate event-driven architectures have been around for decades, but the technology has evolved so that you can apply them across hybrid application environments that include on-premises, cloud, and serverless.
As your customers’ satisfaction is highly influenced by the experiences that they have with your applications, you should look to event-driven architectures as a key approach to both improve brand loyalty, increase responsiveness, and improve business results.
If you want more information on event processing, learn more about how to act in real time with contextual event processing or how to choose between Apache Kafka, Pulsar, and other technologies.
This blog was originally published by Kevin Larsen on 7/8/2019.
The post A Simple Analogy to Illustrate the Power of Event-driven Architecture first appeared on The TIBCO Blog.
Leave a Comment
You must be logged in to post a comment.
