The need for Service Levels on Systems Integration
After several decades of little change, utilities, as a result of restructuring, are becoming more interesting and gaining visibiltiy among leaders in technology and business. The market restructuring is attempting to move the utility domain from a traditional, regulated, non-competetive physical infrastructure to a set of compliant/competetive, economically reformed entities with high levels of service and fiscal accountability. In general terms – this translates into a series of mergers, acquisitions and divestitures that introduce additional needs for business units to integrate diverse organizations, while other organizations such as city owned utilities that continue to remain vertically integrated encounter similar problems in a different way.
In either case, new business units are developed and they have new relationships to the parent company as well as to external parties. For example – when a process becomes outdated, so does the supporting systems. When changes and improvements are made, business unit managers and executive management want the ability to measure the effectiveness and results of the integration strategies that are put in place. They want to be able to analyze results on an individual business services basis as well as on the basis of the total enterprise and assign service levels to the Systems Integration deliverables.
In recent years a concept known as “Enterprise Application Integration (EAI)” was introduced as the solution to this problem. Its introduction resulted in a flood of EAI vendors into the utility industry, successfully selling their integration tools to IT departments where they dealt with interfacing complexity via a wrapping middleware layer. But these tools do not allow a utility to assign service levels, effectively measure its operation environment and identify the reliability and performance bottlenecks. This problem is applicable for all integration paradigms - Application-To-Application (A2A), Business-To-Business (B2B) and Business-To-Consumer(B2C). As a result, many EAI initiatives became an isolated or a stillborn IT project with minimal budget leading to a mutant integration that failed to provide a measurable IT solution.

The need for a coherent Integration and Operations Backbone
A typical systems integrator (in-house or outsourced) should deliver a business driven integration and operations platform focused on a next generation utility enterprise that can be measured for its Service Levels in terms of cost, reliability and performance. Systems Integration solutions should provide two distinct layers to address all these issues and requirements:

1. Integration Backbone


2. Operations Backbone

The Integration Backbone should be a service-oriented architecture that provides a pre-built repository of utility industry domain specific transaction sets in which the business applications are treated as the provider or requestor of certain services. It should also provide a reliable and auditable infrastructure to implement these transactions in a message-oriented or a session-oriented integration environment.

The Operations Backbone should be an event-oriented architecture that provides a repository of business and system events that measures the service level compliance of all automated and human controlled business processes. The Operations Backbone will utilize these repositories to provide a dashboard view of the business operations and enables the insertion of business intelligence back in to the operations environment.

Deriving an Integration Blueprint
A typical business process in a Utility domain comprises of either or both:

• Automated Segments - One or more automated flow of events and procedures known as a Business Flow


• Manual Segments - One or more instances of tasks that are initiated/controlled by human interface

The Integration Backbone encapsulates all the automated segments. A Business Flow is a non linear or a linear automated segment of a business process. Each Business Flow can have one or more atomic integration service (or a procedure) known as a Business Service, which are transactional and reusable. These Business Services when requested or provided one more transactions takes place involving push or pull of information payload known as a message. Each Business Service shall comprise of one more applications defined and represented as Business Components to enable the provision of these services.

A Business Component is a logical representation of entry into applications such as CIS, WMS, OMS, GIS, etc. In summary we are now looking at an integration blueprint that is process centric, which treats the applications as a provider of reusable services to these business processes. This approach enables business units to assign Service Levels against these applications in terms of performance, cost, efficiency, throughput, exception handling etc. It further enables rapid automation of some of the manual processes that existed until now due to lack of coherent integration architecture.
Once the integration blueprint is deployed, the Operations Backbone takes over to effectively operate the integrated environment by ensuring and validating the Service Levels assigned by the business units who are accountable for the business operation. The Operations Backbone monitors both manual and automated segment of the business process to derive the measurable determinants such as cost/customer, time/process, cost/process etc.
For the given scenario the Integration Backbone provides several pre-built pieces that will significantly reduce the initial analysis and design time and cost. A typical logical integration model is illustrated in the diagram shown above.
The Business Components are the connectors C1, C2, C3, C4, C5 that are responsible for the interface into the respective applications for any given Business Service and also provides agents for effective monitoring. The Business Components are pre-built for selective applications like CRM, WMS, DIS, etc.

The Messages associated with the transaction sets – M1, M2, M3, etc., are also predefined in the integration catalog along with several conversion definitions for XML etc. The Operations Backbone separately measures the Manual Processes MP1, MP2, MP3, and MP4 in terms of front-end usage drilled down to an atomic dialog-box, application usage, cross-user, cross-group comparative analysis, individual performance of the user, usability efficiency of the front-end interface, etc.
In summary, this overall integration approach empowers utilities to expose their IT application functions as a Business Service in which Service Levels can be assigned to their systems integration deliverables to measure the performance, cost, exception, throughput and other business and systems attributes.

Sample Business Scenario – New Utility Connection

Customer moves in - needs electrical/gas connection on existing service location
Ä Manual Process (MP) é Business Flow – Automated (F) ` Business Service (S)
This business process shall comprise several automated and manual segments:

• Call Center Personnel receiving the request – Manual (MP1)


• Call Center Personnel submitting a request to CIS – Manual (MP2)


• CIS processing the order request – Automated (F1)


• CIS Validates Request (S11)


• CIS Sends an Update to the CRM application with a order number (S12)


• CIS Initiates a Work Order for a customer with an existing location by sending a transaction set to WMS (Work Management System) (S13)


• WMS processing the Work Request – Automated (F2)


• Validates the Work Request (S21)


• Sends a Work Request Number to CIS (S22)


• Generates Schedule and Dispatches Work (S23)


• Sends Update to CIS (24)


• Field Crew at work and updating the completions status – Manual (MP3)


• WMS Receives and Publishes the Update – Automated (F3)


• Receive and validate the update from Field (S31)


• Send the Update to CIS (S32)


• Send the Update to Financial Systems (S33)


• Send the Update to Time reporting System (S34)


• Customer Rep makes a courtesy call to the customer for satisfaction survey (MP4)

About the Author
Venk Gopal is solutions director for Logica's energy and utilities division in North America. He is the architect of IMFPlus, the new generation of Logica's proven product for systems integration. Logica provides global IT solutions, including systems integration, consulting, products and services. More information can be found at www.logica.com and www.us.logica.com. Venk can be reached at gopalv@logica.com.