Using Event Sourcing in a Legacy Environment

Have you ever been met with deaf ears when you tell your team there are benefits to thinking about architecture differently? What about when you bring up buzzwords like “Event Sourcing” or “Domain-Driven…”?
I have, which is why I write about it…

Let’s talk about a concrete example, and one way to show your team the benefits of Event Sourcing while staying within your political boundaries.

When I worked in manufacturing, we had a small team that worked completely in the Microsoft stack. It still had mission-critical applications written in VB6. This meant that licensing and support costs were well-known and the yearly budget reflected them. IT Managers didn’t have to give the Executive Team any proof-of-concepts, gain any buy-in, or spend much time arguing that Microsoft was worth the money.

Understandably, IT Management wasn’t very open to new solutions that had seemingly viable Microsoft alternatives. As a dev who liked to try new things, I had plenty of these new solutions :)

Taking the business down

One particular issue being dealt with a lot had to do with one of the most important activities performed in this particular manufacturing domain: the Sales Team booking Quotes.

Over time, the system had been built for Sales people to use Microsoft Dynamics CRM for handling all Sales functions. Booking a Quote meant that a Customer had committed to buying a product, and set in motion many other business activities that converted this Quote into a Sales Order, Work Order, Invoice, etc.

Sales Orders, Work Orders, and Invoices were not managed in the CRM. The ERP system had been in place before their investment in Microsoft technologies, and it was immovable. It was a bohemoth and it worked. What didn’t always work was the integration between these systems when a Quote was booked.

The integration was an .aspx web service that handled a request/response across the network from the CRM to the ERP. Book Quote -> Gather Related Info -> Post Data to Web Service -> Recieve Confirmation -> Tell Salesperson Success.

Here’s a rough sketch.

Due to the request/response nature of this integration, any point of failure made the activity of Booking a Quote to fail. It brought the business to a halt…

Forgetting about the tech, the .aspx page, the old SQL databases, and the worn out infrastructure… this architecture needed some changes. When the integration failed, data was lost. Quotes got jumbled up, half committed in the CRM, half committed in the ERP, activites triggered with empty data, etc.

New-fangled tech

I had ideas to improve:

Introduce a message queue between the CRM and ERP that was tolerant of network failures and allowed for better monitoring of other failures.
Stop sending such large, essential information across the wire. Send a QuoteBooked event with a quoteId payload.
Instead of guaranteeing a response to the salesperson booking the Quote, email them after the event was processed by the ERP that “Everything went well!”

I suggested using NService Bus with a message queue like RabbitMQ for a message queue. Because I was generally not good at selling a point, management only heard me saying “We should try this new tech, it’s open source but whatever…”

Using events for failing better

Looking back, I would have taken a different angle to my suggested improvements to this brittle, yet mission-critical workflow. One of the things that attracts me most to Event Sourcing is the fact that it’s a potential replacement for a Service Bus.

Realizing the power of events, a much less intrusive and powerful solution would have been to store QuoteBooked events in an Event Store. After the web service processes the event, we send an email to the Salesperson about whether the event was processed successfully or not.

What would we gain from this?

Since we’re storing every QuoteBooked event, when a network failure occurs, we can check the Event Store to see where we left off and start sending the rest of the events when the network is recovered.
We don’t have to introduce a Service Bus into the infrastructure, therefore not putting that burden on System Administrators.
The Salespeople can continue with other work instead of waiting for the .aspx web service to respond to the CRM with a success/failure.

By simply adding an Event Store, we’re not so much disrupting the existing stack. Greg Young refers to this type of psuedo-event sourcing architecture as the “Poison Pill” architecture. Once we can demonstrate the benefits of using Events as our primary way to share information around the system, we might be able to ease management into understanding that we’re not just talking about a “new fangled tech”, we’re trying to keep the business running.

Keep in mind there are solutions that make SQL Server able to act as an Event Store, and I’ll be talking much more about that soon.

Summary

It can be difficult to convince a long-existing IT team to buy into new technology that’s not already available under the license agreements the business already pays for. But focusing more on rethinking the architecture, like taking a more event-centric approach to an integration can help.

In our case, we didn’t want to slam IT with a new piece of infrastructure to manage - a Service Bus. By focusing more on events across boundaries, we can try to use Event Sourcing to improve the resiliency of the system without charting unfamiliar territory. Using an Event Store to persist events is not much more than saving to a database. Once we start doing this, we can move towards a more automated way to recover from failures and utilize the Event Store to its full potential.

As always, be sure to sign up for my mailing list by clicking the big red button below for more posts about the specifics behind solving business problems with better architecture.