AutomatedBuildings.com Article - The Challenges of Implementing an Interoperable Grid

Interoperability is the current mantra for the North American Power Grid. We conceptually understand the driving need of things working together. We hope for the benefits of that “Interoperable Grid Dream World” of cost savings, more efficient processes, choice in products and hardware that already work together, as well as security that consistently works, to name a few benefits. The challenge is always in the doing. How do we get this “Dream World” to become “Our Real World” to support the next generation of the grid? I contend that the process for building that interoperable grid is not at all what it seems.

Logically, one would dive into the technical details of how systems are put together, building test scenarios, reviewing technical standards and how they fit together in the system. Building test tools and testing processes become tantamount to everything to ensure that from a technical perspective all will work! What if I told you that this is only about 30 percent of the work? Based on my companies’ proven experiences in other industries, ( For more information, view www.drummondgroup.com) I would suggest that the majority of the work is about “driving adoption” of the standard and/or certification software in the target industry or industries. While the 30 percent is a technical science with some art involved, the last 70 percent is art with some science involved. From our experience, if the focus becomes only about the technical pieces of interoperability, this will get us nowhere.

To understand this, I have to invert the normal thinking on the subject. Interoperability makes little economic sense if products from the interoperable set of tested products are not used by anyone. It is a worthless endeavor! So I contend that the question is not how do I get the set of products interoperable? The more important question is: how does one try to get targeted end users to use the test products in their supply chain? How do you drive adoption of the overall interoperability program? This is so critical because I have seen this fail in industries so often where much work is done on the technical and little is done to drive adoption.

The answer to this question often is specific to a value or supply chain’s purpose and has three distinct areas: 1) the fragmentation of the user community which will purchase the final interoperable products, 2) the technical interoperability program itself, and 3) marketing an understanding of the economic value for using these products. These three items must ALL be addressed to make interoperability successful. Let’s just look at the first one in more detail.

In some value or supply chains, a few pivotal players drive the adoption for everyone. In others, the communities as a whole drive the adoption through their purchasing behaviors. There are many variations, but let’s just look at these two ends of the spectrum for brevity.

Few Pivotal Players
These pivotal players are usually the ones buying the products or services that the supply or value chain information system supports. Because of this, they implicitly or explicitly dictate what software products the players may use in the supply chain by their information strategies. In these types of supply chains, these pivotal players often force one of two strategies:

The first strategy is easier and faster to implement, but it reduces current and future technical options because it limits choice to one or two vendors. They are tied heavily to these couple of vendors and other vendors products may or may not work in the supply or value chain.

In the second option, choosing from a set of interoperable products, allows them not to be closely tied to any single vendor. They have choices—competitive product choices which drive down price, enhance functionality and enable small, medium and large organizations to select product based on need, not mandates. This is the optimum solution in any industry that is driven by different competitors and has a large supply chain and various factors, such as business buyouts and spin-offs.

[an error occurred while processing this directive] Community of Players
A community of players provides examples of supply or value chains where there are no “800-pound gorilla” organizations that can dictate direction. In this environment, they are heavily fragmented with no super-players to drive a direction. These environments are highly susceptible to first option listed above where players select strategies that do not help the adoption of interoperable products based on standards. In this case, a uniform market for the interoperable software products will not develop unless it has a well-orchestrated interoperability program. It tends to be focused more on the marketing aspects than on the technical aspect which begins the process. Interoperability in this leaderless and “lack of common vision” market never takes off because software companies that produce the to-be interoperable products never have a large enough market to make it worthwhile in sales.

A very important consideration in both supply chain instances above is who will be negatively affected by the method chosen for interoperability: A few software/hardware companies of interoperable products or the choice of many interoperable products. It is typical that products must be able to serve organizations of all sizes—each with different functional needs and costs. Generally, limiting the choice of products requires additional implementation knowledge, i.e. costs, or high product prices for the small- to mid-size organizations. Sometimes liability issues arise when organizations try mandating one or two specific products for a supply chain. Creating a choice of products enables products that would serve a wide range of sized organizations. It also encourages competition in the marketplace which generally reduces price, keeps a stable trusted test group of interoperable products and allows flexibility in functionality of products.

Summary
An interoperability test and its “big sister” certification program means facilitating the exchange of meaningful information between organizations and people in the end to conduct business. It is about driving adoption, making it economically feasible for the software vendors and the supply chain end users to conduct business with as few inhibitors as possible.

I believe our “dream world” can be our real interoperable grid world. My company has built one and knows it can be done. The question is: Are you ready to focus on the full 100 percent? Or, just focus on that all seemingly important technical 30 percent? Your answer will drive the future of an interoperable grid.

As the chief executive officer and chief scientist for Drummond Group Inc. (DGI), Rik Drummond has led the company's technical and research strategies while steering DGI to constant growth and innovation. He is a widely respected authority in the eBusiness industry and has been a driving force in the technical standards bodies and vertical industry groups supporting B2B commerce. In addition, Drummond currently serves as chairman of 13 on the GridWise Architecture Council. GridWise is a U.S. Department of Energy (DOE) task group focused on defining the next generation of information systems for the national electrical generation and distribution power grids. DGI, a global leader in B2B software testing and certification, works with software vendors, industry associations, supply chains and the standards community by conducting interoperability and conformance testing, publishing related strategic research and developing vertical industry strategies. Founded in 1999, DGI has tested hundreds of international software products used in vertical industries such as automotive, consumer product goods, financial services, government, petroleum, pharmaceutical and retail.

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources