Guidelines projects begin with an installation phase, one of the activities during the installation, where the integration team comes to discuss and agree on the integration architecture, which is used to guide the products of our client’s current system landscape To communicate with. Many guideline implementations are part of a much larger enterprise transformation project, designed to replace existing outdated technologies with parts of their day to day life, typically over a period of years. In addition many want to take on new marketing channels and use disruptive technologies to sell insurance and manage the customer experience in new and exciting ways. All Good Stuff.
During such a start in a new implementation of Guidewire InsuranceSite,
today we discussed the inevitable issue of ESB implementation. The architects we were meeting were doing rigorous research on integration technologies and discussing their needs with various vendors. Part of the change is obviously system change and typically includes hub-based integration capabilities such as ESB (Enterprise Service Bus) or database-based integration capabilities.
Therefore, the discussion turned to the usual suspects of the proposed ESB development and canonical data model, conforming to data structures and crossing all integration traffic through ESB, services orchestration reared their head. This is a common theme in most common assumptions and while ESB Architect’s toolbox is a very powerful weapon, most schemes are unnecessarily complex, limited to applications that need to communicate with each other, and implemented. Too expensive to do. It often only needs you, which goes against the agile principal of making it, keep it simple and avoid big upfront design.
To elaborate further on this, the following are summarized above. Organizations typically use ESBs to do the following:
Communicate between systems that use different protocols (Web Services for Message Queuing, Web Services for CICS or IMS, Web Services for Flat File)Communicate between systems using different data formats (XML to CSV, XML Schema 1 to XML Schema 2, XML to SQL Database, etc.)
To provide standard based communication between systems like ACCORD, SOA etc.To provide loose coupling between applications so that applications are easily swapped if the insurance company wishes to change the supplier.
To use a canonical data model that models all data in its various systems, allowing for conversion from within and outside to facilitate communication between different systems.
Usually we start with a diagram like this:
This is a simple representation that we come across many times and is a fairly fair assessment of the IT landscape of an insurance company. If anything, the actual images are much more complex than this. At a typical start for a medium-sized customer we see integration requirements for 40 or perhaps systems requiring 120+ actual service calls (an interesting point is that the average number of interfaces we typically implement is around 25 Which we will return.) But these types of things also appear in most project setups and a fair amount of vendor content.
This is the complexity we want to solve with ESB. Communication between systems is a combination of flat files, databases and proprietary protocols, with expensive drivers being preferred such as MQSeries, CICS, IMS, AS400 RPG etc. as well as standards-based web services. Managing such a large heritage environment requires a large amount of skill and ingenuity, and encodes a body of knowledge that in many cases exists only in the head of the architect.
So the target architecture looks something like this:
Well that’s fantastic isn’t it? The data can only be sent to the ESB and it will pass it to the systems that need it and the complexity has gone away. In addition ESB offers a coherent interface for the entire plant allowing me to swap systems and replace them with new ones without affecting other systems.
Well it is true that it is better than before and it is true that ESB does a very good job of allowing legacy systems that talk to each and every web service enabled system using a proprietary protocol, although you should get the following points Has to be kept in mind.
Many of the new systems you purchase will be web service enabled. OOTB will facilitate communication with mainframe systems using multiple MQSeries and JMS, especially if they are designed for the insurance market.