Think about the busy city streets. There are shops, homes, businesses, government offices…all jumbled together, all with their specific purpose, all the destination of countless people. Then imagine a bus. It provides structured transportation, makes each stop along its route, and delivers everyone where they need to go.
With that picture in mind, it is easy to understand why the IT industry created a software architectural model to connect the disparate parts of a business and dubbed it the Enterprise Service Bus (ESB). The ESB seamlessly links together multiple business applications, data repositories, and data consumers. These connections are made via a service layer that contains the rules and a common framework to enable communication between these various entities.
Put somewhat simplistically, the bus takes you where you want to go. Or, in IT lingo, an ESB moves data from any application whenever and wherever it is needed to facilitate business functions. Applications talk to the services layer (ESB) and not directly to the underlying systems.
A Typical Bus Route In Healthcare City
Consider a straightforward example. A health insurance company has multiple applications, three of which are a Claims Management System, a Policy Underwriting System, and an Agency Management System. How do these systems access the patient’s data? You could make multiple point-to-point connections, but that would entail significant effort. Plus, each unique connection would increase the possibility of error.
The better way is to use an ESB. The ESB forms a single common layer (rather than separate point-to-point connections) that each application can use to access the patient data. These applications can be local or in the cloud – this bus travels anywhere.
Getting Your First Bus On The Road
Like any bus, an ESB has quite a few moving parts — all of which need to be in good working order for the bus to function well. Answering the following ten questions will help you create an ESB implementation strategy that is supported by industry-proven best practices:
- 1.What are the rules on how a service gets triggered?
- 2.What are the rules on what data to gather based on a request?
- 3.What are the rules that govern hold-offs or exceptions when retrieving data?
- 4.What are the rules this service must follow from start to end in order to complete a transaction?
- 5.What systems does the service need to interact with to get the right data at the right time?
- 6.What connections need to be made to these systems?
- 7.What acknowledgements does the service need to send when a transaction has been completed?
- 8.What dependent systems need to be updated after a transaction has been completed?
- 9.Are there any workflows, reports, or documents that the end-user needs to interact with as part of this service?
- 10.Are any of these services re-usable across other processes or operations?
City streets can seem chaotic and impossible to navigate, yet buses calmly proceed on their routes delivering people to their varied destinations. Businesses can appear — if anything — even more chaotic and tangled. But an ESB can connect users, applications, and data flawlessly…allowing companies to get down to the core task of doing business.