Many organizations get more and different value from their Enterprise Service Bus (ESB) implementation than they ever expected. Their initial purpose was to sort out the integration spaghetti and other technical issues related to their complex set of applications and channels. This is often an IT-lead initiative, making general claims to business and executive sponsors on how great it will be after they have implemented the ESB. The business and executives are suspicious; this just sounds like make technical mumbo jumbo from the IT department, but they agree as they really do need all that sorted out. The ESB initiative is successfully implemented and they get those benefits, but along the way it is quite common for different unintended benefits to be realized, which provide a huge positive impact.
It starts with some finger pointing between the various organizations, applications areas and the ESB team. A large complex integration can have an impressive number of stakeholders. Inevitably, some issue comes up where someone is saying it’s not my problem, it must be your system that caused the issue. The owners of the ESB realize that they have to capture and log all of the information that flows through the ESB to prove that it’s not their problem. Very quickly people realize that they have a centralized place to diagnose problems for all sorts of things. Data-related issues, slow responsiveness from end system, abnormal behavior, and many other insights can be gained from investigating the ESB logging database. It gets even more interesting when folks start to use LogLogic to extend the ESB logging DB to include information from connected systems; then they can really quickly troubleshoot issues which would have not been possible to figure out before.
Then some astute executive comments that the ESB is even more business-critical than their individual business applications; after all, everything is flowing though the ESB and if it has an issue then who knows what could be the impact? This leads to a project to put very powerful monitoring and alerting around the ESB. It’s not too long until someone monitoring the ESB notices an issue with one of the systems that are connected to the ESB. So they contact the system owner, and guess what? The connected system did not even know they were having a problem and the ESB team alerted them before it became a business-impacting issue. People realize that the ESB is providing an enterprise-wide monitoring capability with a single viewpoint across disparate systems, which just cannot be provided by only looking at the applications themselves.
Sooner or later some back-office system breaks and loses some data. Or perhaps there is some data-formatting issue between the sending and receiving systems that causes the data processing to fail. The sending system cannot resend it, and the receiving system doesn’t have it. However, the forward-thinking ESB team has implemented an Exception Handling system, which has the capability to replay messages, and even to fix the data before it is resent. Now the ESB is providing enterprise fault tolerance and business continuity.
The Holy Grail occurs when someone talks to the business to find out what can be done to meet its needs. The business wants to know about, well … business-related things. Like how many orders did we process and for which type of product? Or, we just ran an advertising campaign; did it impact sales? If it did impact sales, which channel (mobile or web) contributed the most, and when did it happen? The savvy ESB analyst says, “I have this logging database with all sorts of information, and I have this analytics tool call Spotfire, let me take a look and see what I can provide.” The next day the ESB analyst comes back with some slick interactive charts generated by Spotfire, and the business just about falls out of their chair. The business says, “This is exactly the Business Activity Monitoring (BAM) that I have been looking for!”
Yes, the analyst replies, we have an ESB with a BAM.
