Specifying and Using MultiSpeak
Specifying MultiSpeak
Utilities should consider specifying application integration features that meet the requirements defined by the MultiSpeak specification. You may wish to consider the inclusion of language similar to the following in software RFPs:
“UTILITY shall give preference in evaluation of vendor proposals to software interfaces that have been tested to be compatible with the MultiSpeak Version 3.0 specification (or higher) unless the vendor can show that the interfaces proposed provide substantially improved functionality over those included in the MultiSpeak specification. Information about the MultiSpeak specification is available here.
Using MultiSpeak
Depending on the needs of the utility, MultiSpeak can be simply and quickly deployed for point-to-point application integration or can serve as the basis of an enterprise service bus.
- Many small utilities, or those looking for a quick solution, can use vendor-provided web services and just turn on the point-to-point interfaces. This tactical approach results in fully functional integration between two applications often in only a few hours and at low cost. This is by far the most commonly used approach to date.
- In some cases, utilities have one MultiSpeak-enabled application but the others with which it should be integrated do not yet have MultiSpeak interfaces. In this case, the utility or a system integrator can develop an adapter for the non-enabled application. This situation will require some development time and care to ensure that the adapter appropriately implements the MultiSpeak data model, but still full integration can be obtained for little investment.
- A similar situation exists where no applications have existing MultiSpeak web service interfaces. In this case both applications to be interfaced require adapter development. It should be noted however, that even in this more involved situation, the semantic foundation and service development work has been provided in MultiSpeak so the cost of interface development in such a case is a small fraction of what a traditional custom interface would cost for the same applications.
A number of utilities are also beginning to look at the MultiSpeak data model and service definitions as the basis for a more strategic implementation. MultiSpeak is also well suited to serve as the basis for a service-oriented architecture.
Extensions to MultiSpeak
MultiSpeak may not currently support all of the applications that are needed by some utilities. For instance, since MultiSpeak was originally designed with the needs of distribution utilities in mind, power marketing and transmission network modeling are not currently supported. In addition, development is not complete for some utility applications, such as asset management and work management.
However, MultiSpeak was designed from the ground up to be extensible. It is possible to add an unlimited number of additional data objects to the data model and to extend any existing data object by the addition of an unlimited number of XML attributes and/or XML elements, all without affecting interoperation with other applications that may be unfamiliar with the thus-defined extensions. Furthermore, it is possible to easily add additional web services (to support additional types of applications, such as work management) and to add new methods to existing web services. All of these extensibility mechanisms make it possible for a specific utility to build on the established, well-proven foundation of the MultiSpeak data model and service definitions to create those extensions necessary to meet their specific needs.