One of the hardest things to do in newly deregulated energy markets is communicate. In many regions what was once a vertically integrated power monopoly is now a network of retailers, wholesalers, distributors, transmission companies, and generators — each one free to do business with whomever it wishes, and each of whom operates under a (often different) prevailing set of business rules. Energy is bought and sold, accounts settled and billed, transmission capacity scheduled, and customers allowed to leave one supplier and sign up with another. To make it all work, there needs to be communications between the various players — which is why companies increasingly turn to products like the transaction management hubs. These products help companies package, transmit, receive and process information. They take into account the fact that different companies probably have different systems, different data formats and different business rules. They also take into account the fact that many of these rules change from one jurisdiction to another.
As deregulation takes hold, there is a growing requirement for trading partners to exchange information quickly and efficiently. Transaction hubs let them do that.
Clearly, communications between trading partners in the electric industry can be a formidable task. Not only are there these “language differences” to overcome, there is also the sheer volume of data that must be handled. Take energy usage information. Distributors and transmission companies need this so they can settle charges with each other and with generators. In many markets, energy usage is tracked in five or 15-minute intervals — a tremendous amount of data when you consider the number of accounts involved. And that’s just energy usage. Altogether a company may send and receive thousands of messages in a typical day. Failure to handle any of one them correctly can mean a payment delayed, energy not delivered, or a customer lost. Even in the short term, there may be severe consequences — both economic and political.
So Many Interfaces, So Little Time
One way to overcome these hurdles would be to design a specific interface between each pair of companies that need to interact. Depending on the market players involved, however, dozens or even hundreds of interfaces would need to be established and maintained. That would be hard to do (and take a long time) under the best of circumstances. Such an approach is virtually impossible in the world of energy deregulation where trading partners, data formats, business rules, and technology are constantly changing.
Another approach might be to rely on industry-wide standards, just as trading partners in other industries do. Some industries, for example, employ EDI (electronic data interchange) interfaces to conduct their B2B (business to business) transactions. As long as an invoice, say, follows the standard EDI format, another company in the same industry can handle the invoice. Its computers can read the information, match it against an open purchase order, and generate a payment — all without printing out an actual paper invoice, sending it through the mail, and forcing the customer to reenter the information into the accounts payable system.
In the electric industry, however, these types of universal standards don’t exist. Take customer enrollments. Most energy markets use an EDI 814 document for enrollments, drops, move-ins, etc.. However, in the Texas ERCOT model there are 27 unique 814-enrollment transactions to manage switching customers from one retail provider to another. All of these transactions in the Texas market are routed through the ERCOT (Electric Reliability Council of Texas) Transaction Clearing House. Unlike the Texas marketplace, Pennsylvania implemented only five variations of the 814, all of which are different from the Texas transactions.
But it is not just the types and numbers of transactions that constitute an “enrollment” that can vary. So too can the business processes that handle enrollments. And it’s not just enrollments that display differences in number of transactions, types of transactions, and business processes. So too can invoicing, settlements, and other market operations as well. That means every time a company wanted to talk to a different trading partner, it would have to implement and maintain a partner-specific interface to handle a different set of variations. Clearly that is not workable.
A Third Way
The third way companies can communicate is with a hub. The advantage of using a hub is very simple: no one has to learn anyone else’s interface. Everyone talks to the hub using its own data formats and transaction models. It is up to the hub to support the protocols and processing rules needed to work with any of the partners connected to the hub. Such an approach is highly efficient, provided certain design principles are satisfied:
Scalability. A hub might have to potentially handle millions of transactions a day. A single instance of a hub running on a single server could easily break under such conditions. The ideal design would be one in which workload could be distributed across multiple instances running over multiple servers. You would also want built-in facilities for load balancing and load management — for example, with a graphical user interface that allows an operations manager to quickly see if a particular service is overloaded, and also immediately start another instance to maintain optimal system throughput.
Standard Runtime Services. One of the advantages of a hub is that you don’t have to implement the same core services differently in different markets. These are the functions needed to manage the individual transactions and the relationships between them in the context of a business process, such as customer enrollment. Using a common set of core functions means these functions could be optimized for best performance. Sharing runtime services among processes also means you avoid the pitfall of having to maintain redundant versions of these services for different processes — potentially leading to software compatibility and versioning issues.
Transaction Identification. A hub would have to recognize a process as consisting of various transactions, and a transaction as belonging to a specific process. This mapping is also something that should be done centrally through a shared service like a library, ideally using a standard protocol suited for the task, such as XML. Implemented as XML schema and attributes, this transaction library could be easily referenced to determine the type and context of any in-coming transaction.
Transaction Coupling. Each transaction would also have to be associated with the other transactions belonging to a specific process. For example, in the Texas ERCOT marketplace and enrollment process consists of an 814_01 enrollment request, 814_02 enrollment response, and 867_02 historical usage request. Any transactions that cannot be either identified as the initial transaction for a business process, or cannot be coupled to an associated business process that has already been started, must be logged as an unsolicited or orphan transaction.
Expiration Notification. In many business processes, there are market rules related to response times. For example, market rules often dictate that for a customer enrollment request, an enrollment response transaction must be delivered with a certain number of business days. A hub should therefore allow the user to configure expiration timers around the business processes according to the market rules. For example, if an enrollment request transaction is sent out and the enrollment response not received in the user-specified number of business days, an exception should be logged indicating that there is a problem with that particular enrollment process. Depending on the circumstances, you might also want to be able to set the expiration notice as either hard or soft. Soft expirations would allow the business process to continue. Hard expirations would terminate the associated business process.
Exception Handling. With hundreds and sometimes hundreds of thousands of transactions being exchanged between applications and trading partners, the identification of exceptions is critical to managing operations. Operators should be able to quickly and easily identify exceptions and errors that occur. These should be available for inspection — preferably in easily searchable work queues in an easily accessible form, such as a Web browser. Useful search keys would be trading partner, date, transaction type, process type (i.e. Enrollment), as well as user-defined attributes.
Data Validation. Data interpreted as valid in one market might not be valid in another. Furthermore, validation rules change frequently within a market. The hub should therefore allow the user to easily configure validation rules and associate these rules with one or more transactions. Hard coding of rules in the hub’s software should therefore be avoided. Rules should also be available in a manner (again like a library of XML schema) that is centrally accessible by all processes that need those rules. That avoids the needs to redefine the same rules multiple times and increases runtime efficiency.
Auto Response. Hub performance should not depend on manual intervention if validation failures or other specified events occur. For example, in many markets there are application-level response transactions that are defined as part of the overall business process. Those should happen automatically, such as when a Texas ERCOT 814_02 transaction is issued in response to the 814_01 enrollment request. Such response transactions are often used to reject a request, and to indicate a reason for the rejection. The hub should therefore include an auto response mechanism — allowing the user to configure the appropriate responses to specific events without the need to manually write program code. In the case of data validation errors, this would effectively isolate back end systems from receiving invalid data.
Multi-Standard Support. Many deregulated markets have adopted EDI and XML via the Internet B2B exchanges. Other markets, such as Atlanta, Georgia, employ proprietary flat file formats for data exchanges. The hub software must be able to support each of these standards.
Middleware Standards. A hub should employ technologies such as JMS (Java Messaging Service) that allow easy interoperability with many middleware products. JMS provides compatibility with any JMS-compliant middleware, including SeeBeyond, Tibco and MQSeries. Thus, allowing the market to choose the middleware component that works best for them.
Workflow. Management of transactions in the context of a business process is one of the fundamental concepts in the hub strategy. Not only should processes be able to “see” transactions that belong to them, operations personnel should too. Graphical workflow interfaces should allow staff to view the overall process, the transactions associated with a process, and the steps required to complete a process. It is important to not only understand the transaction and its exceptions, but also transaction dependencies. Staff can then be proactive in preventing a situation such as not sending out an invoice in a timely manner. Hub configuration should also primarily be a GUI based activity that is simple and straightforward. Once transactions and business rules are understood, users should be able to implement them — and visualize their impact
A Universal Approach
The economies inherent in the hub approach are self-evident: optimized core services shared among processes and business rules implemented as shared libraries — all of which can be easily managed and configured using a graphical interface. Both user and software performance are maximized. Best of all, the problem of how to connect multiple business partners quickly and efficiently across barriers of heterogonous products, data formats and business rules is solved. This means management can respond immediately to market changes and market opportunities. It can continue to use legacy systems, partner with whomever they want to, and not worry about system compatibility issues. In a time of constant redefinition, that is truly remarkable. n
About the Author:
Chris Hamilos is the Chairman and CEO of LODESTAR Corporation, which offers the comprehensive LODESTAR® Customer Choice Suite™, enabling customer choice in the energy industry. The LODESTAR Transaction Management Hub™ (LTMH™), a compo-nent of the LODESTAR Customer Choice Suite, provides complete transaction management services with multiple trading partners, as well as managing the delivery of transactions to internal applications.
For more information about Mr. Hamilos or LODESTAR Corporation, visit www.lodestarcorp.com.
As deregulation takes hold, there is a growing requirement for trading partners to exchange information quickly and efficiently. Transaction hubs let them do that.
Clearly, communications between trading partners in the electric industry can be a formidable task. Not only are there these “language differences” to overcome, there is also the sheer volume of data that must be handled. Take energy usage information. Distributors and transmission companies need this so they can settle charges with each other and with generators. In many markets, energy usage is tracked in five or 15-minute intervals — a tremendous amount of data when you consider the number of accounts involved. And that’s just energy usage. Altogether a company may send and receive thousands of messages in a typical day. Failure to handle any of one them correctly can mean a payment delayed, energy not delivered, or a customer lost. Even in the short term, there may be severe consequences — both economic and political.
So Many Interfaces, So Little Time
One way to overcome these hurdles would be to design a specific interface between each pair of companies that need to interact. Depending on the market players involved, however, dozens or even hundreds of interfaces would need to be established and maintained. That would be hard to do (and take a long time) under the best of circumstances. Such an approach is virtually impossible in the world of energy deregulation where trading partners, data formats, business rules, and technology are constantly changing.
Another approach might be to rely on industry-wide standards, just as trading partners in other industries do. Some industries, for example, employ EDI (electronic data interchange) interfaces to conduct their B2B (business to business) transactions. As long as an invoice, say, follows the standard EDI format, another company in the same industry can handle the invoice. Its computers can read the information, match it against an open purchase order, and generate a payment — all without printing out an actual paper invoice, sending it through the mail, and forcing the customer to reenter the information into the accounts payable system.
In the electric industry, however, these types of universal standards don’t exist. Take customer enrollments. Most energy markets use an EDI 814 document for enrollments, drops, move-ins, etc.. However, in the Texas ERCOT model there are 27 unique 814-enrollment transactions to manage switching customers from one retail provider to another. All of these transactions in the Texas market are routed through the ERCOT (Electric Reliability Council of Texas) Transaction Clearing House. Unlike the Texas marketplace, Pennsylvania implemented only five variations of the 814, all of which are different from the Texas transactions.
But it is not just the types and numbers of transactions that constitute an “enrollment” that can vary. So too can the business processes that handle enrollments. And it’s not just enrollments that display differences in number of transactions, types of transactions, and business processes. So too can invoicing, settlements, and other market operations as well. That means every time a company wanted to talk to a different trading partner, it would have to implement and maintain a partner-specific interface to handle a different set of variations. Clearly that is not workable.
A Third Way
The third way companies can communicate is with a hub. The advantage of using a hub is very simple: no one has to learn anyone else’s interface. Everyone talks to the hub using its own data formats and transaction models. It is up to the hub to support the protocols and processing rules needed to work with any of the partners connected to the hub. Such an approach is highly efficient, provided certain design principles are satisfied:
Scalability. A hub might have to potentially handle millions of transactions a day. A single instance of a hub running on a single server could easily break under such conditions. The ideal design would be one in which workload could be distributed across multiple instances running over multiple servers. You would also want built-in facilities for load balancing and load management — for example, with a graphical user interface that allows an operations manager to quickly see if a particular service is overloaded, and also immediately start another instance to maintain optimal system throughput.
Standard Runtime Services. One of the advantages of a hub is that you don’t have to implement the same core services differently in different markets. These are the functions needed to manage the individual transactions and the relationships between them in the context of a business process, such as customer enrollment. Using a common set of core functions means these functions could be optimized for best performance. Sharing runtime services among processes also means you avoid the pitfall of having to maintain redundant versions of these services for different processes — potentially leading to software compatibility and versioning issues.
Transaction Identification. A hub would have to recognize a process as consisting of various transactions, and a transaction as belonging to a specific process. This mapping is also something that should be done centrally through a shared service like a library, ideally using a standard protocol suited for the task, such as XML. Implemented as XML schema and attributes, this transaction library could be easily referenced to determine the type and context of any in-coming transaction.
Transaction Coupling. Each transaction would also have to be associated with the other transactions belonging to a specific process. For example, in the Texas ERCOT marketplace and enrollment process consists of an 814_01 enrollment request, 814_02 enrollment response, and 867_02 historical usage request. Any transactions that cannot be either identified as the initial transaction for a business process, or cannot be coupled to an associated business process that has already been started, must be logged as an unsolicited or orphan transaction.
Expiration Notification. In many business processes, there are market rules related to response times. For example, market rules often dictate that for a customer enrollment request, an enrollment response transaction must be delivered with a certain number of business days. A hub should therefore allow the user to configure expiration timers around the business processes according to the market rules. For example, if an enrollment request transaction is sent out and the enrollment response not received in the user-specified number of business days, an exception should be logged indicating that there is a problem with that particular enrollment process. Depending on the circumstances, you might also want to be able to set the expiration notice as either hard or soft. Soft expirations would allow the business process to continue. Hard expirations would terminate the associated business process.
Exception Handling. With hundreds and sometimes hundreds of thousands of transactions being exchanged between applications and trading partners, the identification of exceptions is critical to managing operations. Operators should be able to quickly and easily identify exceptions and errors that occur. These should be available for inspection — preferably in easily searchable work queues in an easily accessible form, such as a Web browser. Useful search keys would be trading partner, date, transaction type, process type (i.e. Enrollment), as well as user-defined attributes.
Data Validation. Data interpreted as valid in one market might not be valid in another. Furthermore, validation rules change frequently within a market. The hub should therefore allow the user to easily configure validation rules and associate these rules with one or more transactions. Hard coding of rules in the hub’s software should therefore be avoided. Rules should also be available in a manner (again like a library of XML schema) that is centrally accessible by all processes that need those rules. That avoids the needs to redefine the same rules multiple times and increases runtime efficiency.
Auto Response. Hub performance should not depend on manual intervention if validation failures or other specified events occur. For example, in many markets there are application-level response transactions that are defined as part of the overall business process. Those should happen automatically, such as when a Texas ERCOT 814_02 transaction is issued in response to the 814_01 enrollment request. Such response transactions are often used to reject a request, and to indicate a reason for the rejection. The hub should therefore include an auto response mechanism — allowing the user to configure the appropriate responses to specific events without the need to manually write program code. In the case of data validation errors, this would effectively isolate back end systems from receiving invalid data.
Multi-Standard Support. Many deregulated markets have adopted EDI and XML via the Internet B2B exchanges. Other markets, such as Atlanta, Georgia, employ proprietary flat file formats for data exchanges. The hub software must be able to support each of these standards.
Middleware Standards. A hub should employ technologies such as JMS (Java Messaging Service) that allow easy interoperability with many middleware products. JMS provides compatibility with any JMS-compliant middleware, including SeeBeyond, Tibco and MQSeries. Thus, allowing the market to choose the middleware component that works best for them.
Workflow. Management of transactions in the context of a business process is one of the fundamental concepts in the hub strategy. Not only should processes be able to “see” transactions that belong to them, operations personnel should too. Graphical workflow interfaces should allow staff to view the overall process, the transactions associated with a process, and the steps required to complete a process. It is important to not only understand the transaction and its exceptions, but also transaction dependencies. Staff can then be proactive in preventing a situation such as not sending out an invoice in a timely manner. Hub configuration should also primarily be a GUI based activity that is simple and straightforward. Once transactions and business rules are understood, users should be able to implement them — and visualize their impact
A Universal Approach
The economies inherent in the hub approach are self-evident: optimized core services shared among processes and business rules implemented as shared libraries — all of which can be easily managed and configured using a graphical interface. Both user and software performance are maximized. Best of all, the problem of how to connect multiple business partners quickly and efficiently across barriers of heterogonous products, data formats and business rules is solved. This means management can respond immediately to market changes and market opportunities. It can continue to use legacy systems, partner with whomever they want to, and not worry about system compatibility issues. In a time of constant redefinition, that is truly remarkable. n
About the Author:
Chris Hamilos is the Chairman and CEO of LODESTAR Corporation, which offers the comprehensive LODESTAR® Customer Choice Suite™, enabling customer choice in the energy industry. The LODESTAR Transaction Management Hub™ (LTMH™), a compo-nent of the LODESTAR Customer Choice Suite, provides complete transaction management services with multiple trading partners, as well as managing the delivery of transactions to internal applications.
For more information about Mr. Hamilos or LODESTAR Corporation, visit www.lodestarcorp.com.
