As companies grow, so do their needs for supportive technologies. At Lucus Labs, we are no different. Every day we, and other companies, are developing new technologies, many of which need to integrate with other technologies to provide additional functionality without duplicating code and efforts. As part of this integration need, many companies choose to connect one application directly to another and another and so on. As one can imagine, this type of "spaghetti-like architecture" can become quite cumbersome to maintain. Luckily for us, there is a better architecture to follow.
The solution is called an Enterprise Service Bus (ESB), also called a "messaging bus". It provides disparate technologies and applications a common interface for interconnectivity. Even with applications that are developed in different programming languages, all applications that utilize an ESB for integration can speak a common language, seamlessly share data, and scale without the need of each application having to create and maintain connectivity to all of the other applications within the business.
Let's take a quick look at an example of a "spaghetti architecture" versus an "ESB driven architecture" to get a better understanding of how the solutions work.
Imagine you have 2 applications within your company that need to integrate with each other for whatever reasons. In some cases it's possible to have both apps talk directly to the databases sitting behind the 2 apps. But, as any DBA will tell you, this is obviously a bad idea. So instead, your engineers implement interfaces within both apps that allow them to talk to each other directly. This is a much better design as it also allows each application to benefit from the other's built-in functionality (such as performing field validations) and not just rely on the data itself.
Now imagine that as time goes on your IT department develops and/or implements a third application and it too needs to talk to the other 2 apps. So, your software engineers get busy updating the API's (Application Programming Interface) in each of the apps so that they can all communicate directly with each other. A few months later you find the need for a fourth app, then a fifth, and so on. Eventually you have several applications that all need to communicate with each other, but as you can see in the example below, that can be a nightmare to maintain. Not only is it difficult for developers to follow and manage the code that makes this possible, but it also puts additional system resource constraints on each of the applications because they have to juggle multiple outbound connections to the neighboring apps while also handling inbound connections.
Let's now take a look at how these applications will interact when an ESB architecture is adopted instead. As you can see in the diagram below, all applications talk directly to the ESB only. This architecture allows all applications to communicate with each other, but they only have to maintain a single connection between themselves and the ESB. Once an application needs data from another, it simply places a question onto the ESB and waits for a reply from the application that has the answer.
Now, I'm sure right about now you are thinking, "this doesn't sound like a traditional enterprise service bus" and you're right! Ordinarily, applications using an ESB architecture will begin by subscribing to topics on the ESB. As necessary, other applications will publish messages (aka data) onto the ESB as that data changes and applications that are interested in said data will have the data pushed to them from the ESB over their open pipe/connection. Unfortunately, in a few cases we have experienced in our lab, sometimes we aren't always aware of which applications need data from which other systems. Sometimes we want to be able to simply ask a question and have neighboring systems (one or more) respond with an answer. You can think of it like walking into a room and shouting, "who drives the blue sedan?"
Although there are technologies out there today that can be interwoven to support the question/answer mechanism described here, we at Lucus Labs decided it much more necessary to develop our own technology for addressing the problem. Along with that, we have also decided to make it available to others who might also have a similar requirement within their organizations. This technology is known as "Symbient™ Spine™". As the name suggests, this is the "backbone" of our products which allows every application to interconnect with others without the overhead of developing, configuring, and maintaining traditional ESB implementations like those offered by other technology providers.
Contact us today to learn more about Symbient™ Spine™" and what it can do for your business.