This is the first of two blog posts addressing some concerns faced by the GIS business unit when required to integrate with an existing corporate Enterprise Service Bus (ESB).

ESB is a very powerful infrastructure that allows a company to transfer information among its different departments via a common framework.

ESB provides one or many communication channels, and implements Department-specific ESB adapters.

With a variety of communication patterns available, adapters broadcast and/or listen to data messages transmitted throughout the bus; enabling flow of data among the corporate departments.

In this way, corporate and departmental decisions can be enriched and complemented by the combination of information coming from a multitude of sources.

Say, as an example, that electric utility NRGy (a made up utility) needs to report to some governmental agency the yearly number and frequency of blackouts across the service area.

Data about the outages may combine information regarding the affected customers (their accounts, whether they called to report lack of service, etc.), the affected equipment, the length of the outage, the geographic distribution of the incidents, and perhaps the weather conditions at the time of the blackouts.

These details are captured by different systems managed by separate departments within the utility: CIS, IVR, OMS, AMS, AMI, GIS, weather monitoring…

A corporate ESB provides NRGy the infrastructure to automatically and reliably collect the data from the different systems, and combine it to produce the required report.

Within the last decade utilities have been gradually adopting ESB technology.

A number of ESB software vendors have been involved in the implementation of the infrastructure. Typically, though, ESB has not been deployed at once within all participating departments.

Rather, business units such as CIS, IVR, warehousing, and accounting rank among the early adopters of the technology.

Other departments, usually the “engineering and operations” type, such as GIS, OMS, SCADA, DMS, and AMI, just to mention a few, play catch up as the Board Room shows an increasing interest in having data from these systems contribute to corporate workflows, and strategic planning.

This (typical) late adoption introduces some ESB integration challenges.

Usually, the design phase of a GIS to ESB integration project (not any different when integrating any of the other engineering systems) is led by the ESB software vendor.

The software itself, in most cases, is supported by a suite of proprietary applications that hide the complexity of integration behind user friendly, yet sophisticated, Integration Development Environments.

From this perspective, ESB experts customarily look at integration as an exercise of their tools.

After agreeing on what data needs to be conveyed, an expert team can use the ESB IDE to create integration services, establish points of integration, and generate data structures almost “automagically” with a few clicks of the mouse.

However, GIS personnel does not commonly have ESB software development experience. The GIS software itself does not provide much in integration-specific tools.

Often, then, the GIS business unit must delegate the design, development, and deployment efforts of the integration to the ESB vendor, or third party ESB software experts.

The application ends up implemented as custom code on the GIS side conforming to the proprietary interfaces exposed by the ESB SDK.

And the project is costly, since only highly trained personnel has the knowledge required to develop such application-specific solutions.

Now then… Is there a (simpler) alternative? Yes: Decoupled Integration.

Decoupled Integration is the method by which GIS and ESB experts only need to agree on what data needs to be communicated, in which format, at what end-points, and within what workflow.

Then, the implementation of the GIS-side of the integration can be developed using any choice of technology.

The sole contract between the two parties is reduced to agreeing on:

1. The communication channel; for instance TCP/IP.
2. The end-points; such as IP addresses, and proxies of the integration services.
3. Communication security credentials; for example HTTPS, with SSL certificates.
4. The structure of a “single” integration message; header plus payload.
5. Exposing a “GET” and a “POST” methods; like those in HTTP technology.
6. And, the structures of the suite of payloads conveying the communication; CIM-based verb/noun XML messages, for example.

Using Decoupled Integration there is no need to implement proprietary interfaces.

Furthermore, the GIS team has freedom to use whatever technology they choose; thus, empowering them to cooperate in, and take ownership of, the integration effort in an equal footing.

This way, GIS and ESB experts participate in preliminary design session that establish the contract described in the agreement above. Thereafter, the decoupling approach of the technology allows the GIS business unit to have full control of the planning, budgeting, implementation, and deployment of the GIS ESB Adapter.

Clearly, the integration is completed after a thorough testing phase which brings the two teams to cooperate together again.

Integration of “engineering and operations” systems within the corporate ESB infrastructure is becoming a norm within utility companies.

The data provided by systems such as GIS, OMS, DMS, SCADA, AMI, and others is increasingly sought out by the corporation to comply with regulations, and drive strategic planning. Implementation of the ESB adapters can be developed by the ESB software experts.

But, if this approach seems challenging, costly, and/or inadequate, then Decoupled Integration rises as a viable option. An option that empowers the responsible department to lead the implementation effort in an efficient and effective manner.

In a follow up article we will analyze some design, implementation, and deployment details of an ESB Decoupled Integration solution.