Smart Grid: Cloud-Oriented Architecture in Action

Even though the global electric power grid is now well into its second century, it might surprise you to learn that this paradigm of civilization is still extraordinarily dumb. In spite of all the hullabaloo about Smart Grid, the way that most power utility companies find out they have an outage is by the jump in incoming calls from irate customers. It’s no wonder, then, that bringing intelligence into this venerable relic of nineteenth-century technology is a worldwide priority.

The utility companies, however, are still struggling with what it means to build a Smart Grid—a situation that hit home recently when we experienced ferocious storms in the Washington DC area. Clearly, our local utility shouldn’t have been caught by surprise, as we watched on TV the line of storms as they moved rapidly from Chicago toward the Capital. Predictably, there was a widespread power outage as a result of downed trees and branches.

In fact, this occasion is not the first time that the DC area has taken a major power hit and, as a result of previous significant outages, customers have loudly criticized the electric company. In response, they worked very hard to trim trees and to improve their systems, including the publication of a mobile app for tracking the status of the local power grid and reporting issues back to the utility.

As the storm approached, I knew that this would be a great opportunity to test the app, but to my surprise the app’s performance was truly abysmal. The app turned out to be worse than useless, as it merely served to give the electric company’s customers a false sense of empowerment. The problem, however, was not the mobile app itself, but rather the architecture that supported it. Why the utility made such a fundamental error—and how they should have architected their system in the first place—go at the heart of the importance of Cloud-Oriented Architecture (COA).

Smart App vs. Smart Grid

As the storm approached, I began to work with my electric power app on my mobile phone. I could see the outage map, but when I clicked on the “My Outage” link, I received a message more than 30 seconds later stating that the system was unable to respond due to large traffic volume. Now, when a storm like this one takes place affecting so many people, there should be the expectation that there will be a surge in traffic. When there is a significant storm causing widespread outages, the power company should assume that there will be high volume of people wanting to connect using the app, both to report outages and see the status of their outage.

Furthermore, I wasn’t able to access the app until the morning after the storm, and even then the app was only available because many people had run out of power overnight and therefore couldn’t use their smart phones any more as they ran out of juice. As a result, I wasn’t able to report my outage status until twelve hours after the outage began. This lengthy delay clearly defeats the entire purpose of the app. What went wrong?

Cloud to the Rescue?

The most obvious problem with the power utility app, of course, was that it was insufficiently elastic. A spike in demand prevented it from working properly, at the precise time when the app would have been the most useful. If this app had been running in a Cloud, then presumably it would have scaled out automatically to deal with the additional demand. After all, one of the main benefits of the Cloud is its ability to support traffic surges, so any public services company dealing with widespread issues that affect their customers are prime candidates for Cloud-based apps. After all, companies that the public counts on in times of disaster should be reliable in time of need.

Fair enough, but there is more to this story, as this electric company had already built their mobile outage tracking app in the Cloud. They thought they were doing everything they could to build a modern, customer-friendly app. And yet, it still failed when we needed it most. What happened? It wasn’t the Cloud bit that failed at all. It was the legacy systems behind the newfangled Cloud-based mobile app that couldn’t handle the load. Their grid may have looked smart, but it was really just as dumb as it had been for the last hundred years.

Beyond Legacy Modernization

Clearly, the power utility should have modernized their IT infrastructure, replacing it with technology that could handle significant surges. However, such modernization is difficult, expensive, and risky—and for one reason or another, this company was unable or unwilling to retire the problem systems. This situation is very common, of course. Instead of replacing older systems, large public companies like this one typically opt to keep them around, both to provide functionality internally as well as to expose some capability to the outside world, increasingly via elastic Cloud capabilities that should grow or shrink based on demand. But exposing legacy capabilities via the Cloud is only the starting point, as our utility learned the hard way when their mobile app crashed and burned at precisely the wrong time.

The essential architectural principle this company failed to grasp was that the mobile apps are more than simply user interfaces—they are part of the Cloud itself. In fact, when ZapThink uses the term COA, we include the “Internet of Things” in the Cloud. If this utility had architected their mobile app based upon the principle that their customers’ mobile devices were part of the core app itself, rather than simply its presentation tier, then they would have a better chance of dealing with the spikes in demand that outages create.

Instead of thinking of the outage reporting app as centering on existing systems, the utility should have thought of it as a peer-to-peer, social app consisting of all the mobile devices in their ecosystem, essentially forming a crowdsourced outage reporting system. After all, most of the time the public is the first to report outages anyway.  But even when the power utility is aware of outages based upon intelligence from their own infrastructure, such intelligence can feed the crowdsourced app as well.

When it is time to dispatch a crew, the system should use an algorithm that optimizes for efficiency, taking into account the crowdsourced outage intelligence. When the crew arrives at the scene, they should use a simple app to report back to the system on the extent of the damage and the expected duration of the job. This information can feed both the legacy emergency response app as well as the modern Cloud-based customer app. Thereafter, customers at home in the dark using the consumer mobile app will be able to get specific, real time data about the location, duration, and other information about the outage, regardless of how well the utility’s legacy systems are performing. Furthermore, since all systems exchange the same data, employees see the same information as the public.

The ZapThink Take

This story is at its core a legacy modernization tale, but with a twist. Conventional wisdom often states that the cost and complexity of modernizing a legacy set of systems are difficult or impossible for an organization to cost justify. However, a sensible approach to modernization is holistic and should take into account the full power of modern architectural approaches.

COA, of course, is a prime example of a modern approach. Instead of thinking of the Cloud as consisting of little more than new and improved data centers, think of it as a new way of building applications. In this example, COA allows for building a mobile app ecosystem that both supports customers’ need for information as well as the utility’s need for actionable intelligence. After all, that phone in your pocket is more powerful than the fastest supercomputer from a mere generation ago. Why not build apps that raise customers from mere consumers of information to full participants via interactions with each other, as well as the organizations that serve them?

About Dov Levy

Mr. Levy is the President and CTO for Dovel Technologies, Inc., the company he co-founded. He has responsible for creating innovative solutions for the federal government by Dovel.

As an entrepreneur and a technologist with over 25 years of hands-on experience, Mr. Levy has a deep understanding of what it takes to deliver a state-of-the art solution with technologies such as Service Oriented Architecture, Cloud and Mobile computing. He has solid experience with delivering solutions using open source components.