[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [smartgrid-discuss] Senate Hearings on Smart Grid - Cyber Security
Good observations and a couple good
points.
Developing consensus standards of high
quality takes time. 9 to 12 months to get to a workable draft is very
aggressive, with 2 years to get to final draft still pretty
optimistic. We can think generally of the process in stages:
1. Establish need and scope (concept
validation)
2. Develop technical approaches and consensus
leading to a draft standard
3. Validation of the draft standard within the SDO
4. Final Approval (which usually involves
approval by people not involved in development of the draft
standard)
Very often vendors take the risk of implementing
draft standards during the third phase (while the standard is still being vetted
inside the SDO) once it looks as though it is fairly stable. This can have mixed
results, and in several examples in my experience, the overall process of both
standard completion and market adoption is actually lengthened considerably when
this is done (if different vendors interpret drafts differently when there are
still missing bits, and thus produce non-interoperable solutions, the market
sours on the technology and it can take a while to get over it). Other
times it works fine. Deciding when the risk is reasonable takes a lot of
experience, in depth knowledge of the standard, the process by which it was
drafted, good timing and a bit of luck (though as a famous golfer once said, the
more I practice, the luckier I seem to get ;-).
Sometimes if the standard is drafted too quickly
the overall time to adoption is actually longer, like many things. IMO the
primary purpose (only purpose?) of standards is to achieve interoperability, and
strong emphasize of this over all other goals during the drafting process seems
to help; it may take a bit more time up front but like so many things if spent
well that time pays back quickly with an overall shorter time to reaching the
goals.
Another trade-off is that the wider the
participation, the better the standard, but the more participants
the longer it takes to reach a true consensus. The term 'consensus can
mean different things to different people, even when operating in the same
SDO with the same rules. It may mean we combine ideas and find a workable
merged approach, or it might mean I can get more votes than you so I
win (and many shades between). I'll agree with Joe that funding
can help broaden participation (I sure wouldn't mind it ;0), but other outside
pressures can actually stifle the process. When consensus is forced both
quality and schedule can suffer.
One way to accelerate the process is when the SDO
task group has a very well defined and focused scope. This tends to narrow down
the options and lead to some obvious 'good enough' points rapidly.
The better we understand the problem to be solved, the easier that is. The flip
side of that is that in many cases what we think we know becomes obsolete
knowledge rapidly, and the problem we think we're solving changes by the time
we're done; too narrow a view leads to irrelevance.
A recurring theme in SG discussions seems to be a
fixation on how things have always been done. I think we need to think beyond
traditional models, because communications technology is an enabler of new ways
to do things. I believe technology will alter the barriers and balances to
new architectures, for example, distributed generation and local storage will
become viable in places it hasn't been so far, and will completely change the
game. The work on SG, mostly based
on what we know to be the rules of the game are today, will be a catalyst that
will change the rules completely. So how hard can it be to characterize that
problem?
Just some things to think about as we try to
maintain useful perspective.
-Ben
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]