Photo Credit: SqueakyMarmot, cc
Nearly every smart grid application you can name relies on functionality and data from multiple systems. Take condition-based transformer maintenance, for instance. Leading utilities are predicting failures and building proactive maintenance strategies by combining data from their AMI networks along with data about transformers from enterprise asset management systems, then analyzing past failure data from maintenance applications.
Another example is enhanced outage management. Smart meter outage messages can be mapped to linear models to identify faults and then be combined with data from GIS systems for faster and more targeted work crew deployment. Dynamic pricing and residential demand response, conservation voltage reduction, renewables integration -- all are composite applications. Most of the other applications on the smart grid consideration list are composite applications, as well.
Composite applications are the sweet spot for service oriented architecture (or SOA). Briefly, SOA is a loosely coupled system design pattern enabled by a supporting set of software infrastructure tools and internal standards. A free GTM Research smart grid enterprise architecture webinar this Thursday will share highlights from our recently issued smart grid enterprise architecture report, including a briefing on SOA technologies, plus a market forecast.
For now, however, the salient point is that SOA provides a foundation for building smart grid applications.
But SOA requires investments in planning, expertise, and programming muscle-power. Why bother? Here are five reasons:
1. Agility and time-to-market. No one has a crystal ball for where smart grid is going to take us. New and creative uses for AMI and IED (intelligent electronic device) data and features are being discovered all the time. SOA provides a mix-and-match infrastructure for quickly building new applications. Once a core set of SOA building blocks (called “services” in SOA parlance) are built, they can be used to create new applications (called service “consumers”).
2. Improved developer productivity. Integrating with pre-smart grid legacy applications is a messy business. In many cases, core applications like customer information systems (CIS) were never designed with smart grid applications like dynamic pricing or home area network (HAN) integration in mind. SOA makes it possible to build well-defined messaging interfaces to these systems using technology standards like XML (eXtensible Markup Language) and industry standards like IEC Common Information Model (i.e., IEC 61968, part 9). This increases developer productivity and lowers integration costs, since services enable developers to access legacy application features without a detailed knowledge legacy idiosyncrasies.
3. Reuse. Over time, a library of reusable application services can be built and listed in a services registry where they can be discovered and reused by other developers on other projects. Reuse is a good thing, it makes future projects faster, cheaper, and hopefully, better (the tech “big three”).
4. Consistency. SOA makes it possible to create some level of centralized governance and consistency. Once services are built, they can be listed and documented in a services registry. Future applications built with common application services become more consistent, making it possible to adhere to industry standards, and importantly, to extend those standards in a known and well-documented fashion.
5. Lower total cost of ownership (TCO). TCO is an established concept for what it costs to “keep the lights on” with the existing IT environment. It seems like an inevitable law of physics that, over time, more and more IT dollars get chewed-up by routine maintenance and upgrade chores, leaving an ever-declining pool of resources for new development. A key culprit that raises TCO costs is point-to-point integration between applications. Ad-hoc integration creates complex (and often hidden) interdependencies between applications.
SOA solves this problem by using a message broker (called an enterprise service bus or ESB) to route communications between applications. The overall goal is to provide a plug-and-play, publish-and-subscribe infrastructure to replace point-to-point communications and snuff out hidden interdependencies. This streamlines upgrades and makes it possible to swap applications in and out while stable messaging interfaces are maintained. It also provides a centralized environment for change control, debugging, testing, and for building security services. These under-rated benefits become lifesavers when the task is to build robust, predictable and scalable distributed applications.
One of the criticisms of SOA is that it creates more upfront costs. These take the form of middleware and development tools, developer training, planning, and creating and staffing an enterprise architecture competency center (a best practice), and building the services themselves. These initial investments are recouped over time as additional smart grid applications are built.
A good rule of thumb is that SOA ROI increases in concert with system heterogeneity, application complexity, and system scale. The specifics of the business case will vary depending on the smart grid business architecture and overall organization strategy and the complexity of the application portfolio. That said, the best approach is to start small, get some early initial wins and experience, then build more services over time.
While it is possible to build smart grid applications without SOA, it is shortsighted to hurtle down the smart grid highway without an IT roadmap. SOA is a proven design pattern for building composite applications that has been successfully applied in a wide range of industries.
It is time for organizations implementing smart grid to move beyond slide-ware and into the business of building reusable application infrastructure components.