It's evening, mid week. No one at your house feels like cooking. "Let's order pizza", you decide. Next step, you grab your phone, open your favourite food app, select the available toppings, payment method and place an order. Your next worry is to watch the notifications on the screen when the order is being prepared and the delivery driver is nearby. Food is delivered, sometimes contact-free due COVID-19 measures, and you can enjoy your meal.
Now think about the same situation, but this time, you make a call to the pizza joint. "One moment, please" says the person on the other side of the line while he or she finishes taking notes for another customer'. After a couple of minutes waiting, you finally tell what you want, not before acknowledge that they are out of pepperoni tonight, so you will have to make a last time change. 30 minutes later, the doorbell rings. While reaching for the door, looking for your credit card, you think how lucky you are for getting it on time and not have to call the place again to know your pizza's whereabouts. Best-case scenario, you use a contactless card and just have to wait for the confirmation without typing your 6 digits pin-code. Another day in paradise.
Obviously there is a huge difference in the customer experience. However, I would like to focus on the time wasted in every interaction of the second scenario:
Idle time isn't just wasted. It is counter-productive. That's one of the reasons people rather text, instead of calling. And while we can't pinpoint the reason why study after study shows a boost in workers' productivity when working from home, asynchronous communication is certainly an influencer.
Idle time is also costly, specially on cloud environments where most things are consumption based. It is like letting the room's light turned on, just in case someone comes in.
Despite the fact we are living in an increasing asynchronous world, direct communication stills overstated. "Real time" and "human touch" are marketing curated terms that work very well in a sales pitch but should not always make a compelling argument when discussing system integrations.
Synchrony generates dependency. If System A needs to send data to System B, and the last isn't available, there will be waiting and eventually a timeout error.
Although we can not predict how the future will look like, certainly there will be outages. Last week, Steam, Spotify and a whole AWS region went down. Hoping that this won't happen to your system is pure naivety.
Instead, if System A sends data to an intermediary message queue, System B can periodically monitor it for new messages and act upon them. How often this check will occur varies, 10 minutes, 1 minute, 30 seconds. I am sure you were never bothered by the time it takes from the click on "Buy Now" button on Amazon till the email you receive with your order number. Your experience is real time, even though the integration between the e-commerce and the orders' system is not.
An event is something that represents a state change. It can be an order that was created, a pizza that is ready for delivery or an invoice just validated by a fiscal authority.
Systems where those events are generated are called Producers/Publishers. And if they need to notify other systems about said events, they create messages in a queue. And that's all. Here finishes the role of "System A".
Now Systems B/C/D/N have two options:
Whatever model is adopted. There is no dependency between System A and other Systems. Therefore, this architecture can scale infinitely. If there are 100 subscribers, System A behaves exactly the same as there were 1.
Once removed the interdependency among systems, the communication can be standardized enabling a plethora of easily pluggable integrations to take place. In other words, other applications can act upon SAP systems signals without worrying about its specifics.
For the techy ones, we wrote a series of blogs explaining the approach for SAP Business ByDesign. However, event-driven architectures are not exclusivity of one or another product, meaning the concepts can be adopted on a broader spectrum.
For example, we can have ERP systems signalling things, like this:
https://www.youtube.com/watch?v=EIai3w_Cnq4
Or interacting in social media like our ByDEventBot
And even working in localization scenarios, like tax engines.
Hope this blog post have introduced the idea of how event-driven architectures can facilitate the development of your solution. The next time you are considering developing an extension or full side-by-side system. Give it a go. We have reference architectures as a starting point. For the SMB partners, reach out to your Solution Architects for further advice.
Thank you for reading and you can also find me on Twitter. @Ralphive.
Now think about the same situation, but this time, you make a call to the pizza joint. "One moment, please" says the person on the other side of the line while he or she finishes taking notes for another customer'. After a couple of minutes waiting, you finally tell what you want, not before acknowledge that they are out of pepperoni tonight, so you will have to make a last time change. 30 minutes later, the doorbell rings. While reaching for the door, looking for your credit card, you think how lucky you are for getting it on time and not have to call the place again to know your pizza's whereabouts. Best-case scenario, you use a contactless card and just have to wait for the confirmation without typing your 6 digits pin-code. Another day in paradise.
Obviously there is a huge difference in the customer experience. However, I would like to focus on the time wasted in every interaction of the second scenario:
- You (and a dozen other customers) waste time waiting for the agent to pick the phone, and to get to your turn to place the order.
- The agent waits to hear your order and to tell you that something isn't available
- The kitchen is waiting for the order to be placed
- The delivery driver is waiting for you to open the door
- You both wait for the credit card payment to be completed.
Excuse me, can you work like this app ?
Idle time isn't just wasted. It is counter-productive. That's one of the reasons people rather text, instead of calling. And while we can't pinpoint the reason why study after study shows a boost in workers' productivity when working from home, asynchronous communication is certainly an influencer.
Idle time is also costly, specially on cloud environments where most things are consumption based. It is like letting the room's light turned on, just in case someone comes in.
Almost real time is real time
Despite the fact we are living in an increasing asynchronous world, direct communication stills overstated. "Real time" and "human touch" are marketing curated terms that work very well in a sales pitch but should not always make a compelling argument when discussing system integrations.
Real time response is real time waiting
Synchrony generates dependency. If System A needs to send data to System B, and the last isn't available, there will be waiting and eventually a timeout error.
Although we can not predict how the future will look like, certainly there will be outages. Last week, Steam, Spotify and a whole AWS region went down. Hoping that this won't happen to your system is pure naivety.
Instead, if System A sends data to an intermediary message queue, System B can periodically monitor it for new messages and act upon them. How often this check will occur varies, 10 minutes, 1 minute, 30 seconds. I am sure you were never bothered by the time it takes from the click on "Buy Now" button on Amazon till the email you receive with your order number. Your experience is real time, even though the integration between the e-commerce and the orders' system is not.
Events & Messages
An event is something that represents a state change. It can be an order that was created, a pizza that is ready for delivery or an invoice just validated by a fiscal authority.
Systems where those events are generated are called Producers/Publishers. And if they need to notify other systems about said events, they create messages in a queue. And that's all. Here finishes the role of "System A".
Producer/Consumer Model
Now Systems B/C/D/N have two options:
- Query the queue on timely fashion searching for new messages, acting as a Consumer
- Be notified by the queue of new messages as soon as they arrive, like a Subscriber
Whatever model is adopted. There is no dependency between System A and other Systems. Therefore, this architecture can scale infinitely. If there are 100 subscribers, System A behaves exactly the same as there were 1.
Publisher/Subscriber Model
The Things, People and Businesses Factors
Once removed the interdependency among systems, the communication can be standardized enabling a plethora of easily pluggable integrations to take place. In other words, other applications can act upon SAP systems signals without worrying about its specifics.
For the techy ones, we wrote a series of blogs explaining the approach for SAP Business ByDesign. However, event-driven architectures are not exclusivity of one or another product, meaning the concepts can be adopted on a broader spectrum.
For example, we can have ERP systems signalling things, like this:
https://www.youtube.com/watch?v=EIai3w_Cnq4
Or interacting in social media like our ByDEventBot
And even working in localization scenarios, like tax engines.
Hope this blog post have introduced the idea of how event-driven architectures can facilitate the development of your solution. The next time you are considering developing an extension or full side-by-side system. Give it a go. We have reference architectures as a starting point. For the SMB partners, reach out to your Solution Architects for further advice.
Thank you for reading and you can also find me on Twitter. @Ralphive.
- SAP Managed Tags:
7 Comments
