GISdevelopment.net ---> GITA 2003 ---> System Integration

A “Business service oriented” Approach to systems integration

Venk Gopal
Solutions Director
Logica
32 Hartwell Avenue
Lexington, MA 02421
Tel: 617-476-8239
Fax: 617-476-8017
Email: gopalv@logica.com


Abstract
Utility companies are being challenged to justify new IT investments due to the changing economic outlook. However, IT managers and business leawders are continually being pressured to improve operating efficiencies and support new regulatory and business functions. The IT units go through several iterations of integration to deal with such challenges. This presentation discusses how existing IT systems can be organized into a portfolio of “business services” to support new functions and define measurable service levels, which helps simplify the management of the overall integration effort.

The need for service levels on systems integration
After several decades of little change, utilites, as a result of restructuring, are becoming more interesting and gaining visibiltiy among leaders in technology and business. The market restructuing is attempting to move the utiltiy domain from a traditional, regulated, noncompetetive 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 sessionoriented 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.

Sample business scenario – New utility connection




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.

Conclusion
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.

© GISdevelopment.net. All rights reserved.