Friday, December 3, 2010

Grid-Interop Day 3 Notes

Once again, the day's missives from Grid-Interop.  Once again, my commentary is in italics.

Today is pretty technical, so the discussion here will be very high level and limited, with the exception of the plenary sessions, which I'll discuss in as much detail as I can reasonably capture.  The lunch and dinner speakers may well be the most interesting of the day.
  • I spent the first session hopping between two sessions, one on Semantics and Semantic modelling (fascinating for a communications and linguistic geek like me) and a discussion of Case Studies.
    • Semantics discussion on "Demystifying the Common Information Model"
      • CIM is defined in a high level modelling language called UML (Unified Modelling Language)
      • IEC maintains it in Enterprise Architect, unfortunately, a proprietary system, but really just about the best tool for the job, and one of the few that explicitly supports non-Windows systems.
      • Under UML, any system is categorized by a series of high level classes and objects, with inheritance.  (Geek-speak for grouping things based on common characteristics.)
      • Profiles take a subset of CIM Classes and apply them in a given business context.
      • Theoretically and ideally, using UML and Profiles, different developers can use the same CIM classes, develop compatible application code definitions (even if the applications are written using different languages and schemas), and automatically test for compatibility with other systems.
      • It isn't perfect, but it is useful.
  • Priority Action Plan 10 (Delivering Usage information to the customer domain) Finalization.
    • Discussion regarding Leonard Tillman's comment on the Twiki.  (Scroll to the bottom to see the comments.)  Under the SGIP process, this comment has to be dealt with, however the proposed solution in the comment (altering the requirements) would require a change to the SGIP requirements review process.  A bit of a Catch 22. We have to address all comments under teh review process, but the comment requests we change the review process, which we can't do.  Resolved by clarifying what the requirements are intended to do.

      Regardless of how one feels about a proposal to alter these requirements (which I feel is a bad idea), altering requirements after a standard is written to them is a terrible idea.  Doing so will set a precedent that could gut the SGIP process.  How does one develop a standard to meet a set of requirements, and get people to invest the (volunteer) effort in the development, if the requirements can be changed on the fly after the standard is developed?  If you can alter the requirements after the fact, you can alter the requirements after the fact to arbitrarily reject the standard. 
    •  The PAP 10 seed standard is formally approved by the PAP 10 WG, and has been OKed by the CSWG review team.  next step is getting the Governing Board official OK.  After that, SDOs can use the seed standard to develop compliant standards that will be interoperable on a data expression level.  I admit, I'm personally pretty doggoned stoked over this.

  • Lunch Speaker: Lynne Kiesling - www.theknowledgeproblem.com 
    • Economic foundations of regulatory policy. 
      Why is (traditional) regulatory policy the way it is?
      • Regulation is historically based on cost recovery rather than value creation. 
        It assumes a decreasing long run average cost, and a given demand. 
        The goal is to provide a statically defined product at a known cost.  
      • This paradigm worked because it accomplished the public goals of ubiquitous service.  However, it doesn't support a more dynamic context. 
        Lynne compares the current cell phone market vs pre-Carterphone PSTN.
      • Barriers to entry limit innovation and efficiency gains from technological innovation.
        Choice is ubiquitous in our society.  I could argue that the willingness to intelligently make choices is in decline, but that's another topic. 
      • Regulation was good at the policy challenge of ubiquitous service, but not at promoting innovation.
        Changes need to come at a level that doesn't appear in anybody's architecture stack.  Changes need to happen at a cultural level. 
      • Lynne allows for some level of hierarchical control because of the need for real-time balancing, but her real vision is one of distributed intelligence.  Multiple devices in the field each responding to localized conditions.  This will probably resonate with this evening's speaker.
      • The secret, and the real trick for regulators / public policy makers will be to achieve a balance between allowing economic dynamism and maintaining the still legitimate public policy goal of ubiquitous service.  A fully dynamic market has market entrances and exits on a continuous basis.  There may be a limit to the amount of dynamism in the market for a critical resource.

No comments:

Post a Comment