Author: John
Company: DELLNBX

Nig’s original note:
Hi All,
        As discussed on our call on 24/7, here is a note containing bullet points for each of the patterns identified in section 3. 
As stated in the note I think the next actions are for everyone to look at the issues raised under ‘IoT Delta’ headings and 
1)      agree that they are indeed issues
2)      agree that they are in the right place
3)      Identify any further issues that we should address in the CN.
Then, we need to look at the recommendations, comment upon them and identify any further ones.
I did originally offer to attempt to draft the full patterns for review by our meeting on 21^st August. I don’t think that will be possible given the need for the TC to comment on this note and my other commitments. Thus, I suggest that we aim to have this note (including a full set of recommendations) agreed by the end of that meeting. I hope that is acceptable.

Chris’ Comments:
Thanks for doing this.  There’s lots of great stuff here, and in general I think all the issues you’ve identified are important  and, other than some detail we can address when we get to detailed drafting, I think the recommendations are on the right lines.
 What concerns me though is the sense that all of these issues and recommendations are missing from the existing TGF; that this content is about ‘filling gaps’ in some sense.  Is that what you had in mind by “IoT Delta”?  
 Because that’s not the way I see it.  While the TGF doesn’t explicitly discuss IoT in much detail, we very much had it in mind when drafting many of the patterns.  And I think we should take the general stance that the TGF as it stands is a valuable tool for organisations wishing to manage effectively in an IoT environment (while also talking the opportunity of this Committee Note to do further due diligence and highlight any issues that are not fully addressed in TGF).   
 That’s why my suggested format for this committee note started by looking at relevant patterns and explaining why they are already relevant to the IoT. In many places, the  “IoT delta” sections of your note identify issues which I think are already identified explicitly in the relevant TGF pattern, albeit in slightly different wording, and similarly many of the recommendations are already TGF recommendations.    So I found it difficult to disentangle which elements of your note were new.
 Happy to give examples of this if that would be helpful.  Or is this also how you see things, and simply planned to bring in the “how TGF already addresses” this element back in during the next phase?

Hans’ Comments:
This is a very good start Nig ;-)

I feel the win-win and service oriented approach with competing vendors from different technology platforms and different networked products are crucial for the service and citizen centric approach of the TGF work.

Being working with process control in different markets(ship & offshore, energy/utility,paper industry, home automation, healthcare etc etc) the interoperability layer has been solved through open APIs and open BUS-protocols many years ago.
The new approach is the globalization requirement of merging "open" services on a functional XML level dealing with open information exchange in real time. ( Going from Local Automation to Global Automation )  This require an understanding of a hybrid information exchange structure.

The lowest control level is the process control of interacting networked devices of one or several interoperable BUS-protocols.( BUS interoperability) This is handled by different BUS-standards(technology standards) and their trade organizations. I recommend that this technology level should not be the the topic of the TGF approach. Never the less some of the functionalety in these systems needs to be exposed(mirrored) to a service level to be part of wanted interaction of different services(both public and private).
We do call this service level:
- Scenario composing on an individual user defined level.

This is the level of service templating we are dealing with in OASIS CAM and BCM.

Mark’s Comments:
Thanks for doing this, it has helped me to feel like I'm getting a grip on this.  A few comments:
 [B1]  Vision for Transformation.  I would suggest that the point you make here is true for any collaborative situation, and therefore any TGF programme and the more heterogenous the types of organisations the more diverse the aims and agendas will be.  This leads me to two questions:
 Should we be drawing this out in the main document?  (Possible change for v3?)
1.	Is the problem different for IoT, or exacerbated to the extent that it needs specific treatment?
 [B7]  Supplier Partnership.  I think the key point here is that relationships could become more complex around IoT - the same organisation may be custodian, supplier and consumer in a single area, and may even have multiple "instances" of these roles.  However, I think this needs to be addressed in [B5], not [B7] which is about transforming procurement thinking.  (Although there may be knock-on effects here as well.)
 [S3]  Does something need to be said about what is "private"?  Interesting article on the BBC today here.
 [T1]/[T2]  Given how easy it is for organisations to lose track of traditional IT assets, what happens ~~if~~ when they lose track (or lose interest) in IoT assets?  If the asset is still live and connected, but no longer being maintained, does this become a security risk?  Does something need to be said about this?
Peter’s Comments:
I’m pleased that you answered Chris, as many of my initial questions were very similar! I too believe that the TGF was scoped and designed in a way that could (easily) take account of IoT and welcome your clarifications.
 I have one remaining issue – regarding how IoT devices are the same or differ from other IT infrastructure and assets. You state for example,
“All systems, regardless of platform, need to be configured, secured, monitored, updated, and patched. The IoT will only contribute to the complexity of IT systems management, security and asset management as Internet-connected computing devices and application delivery models proliferate”
 Many devices that are becoming part of IoT are commoditized and it is difficult to see how they can be configured, secured, etc. For example, my new television has an onboard embedded webserver, whose password I cannot control or configure; and which I can only “secure” by not allowing it to connect to the Internet. That defeats the object of it being a “smart TV” but stops it from becoming a spamming botnet, which although not part of its intended design, is nonetheless well within its capability.
 I think we need to say something about how one can govern an IT landscape in which one may have to accept components over which one has little or no control. I fear that this is going to be increasingly the case and as IoT spawns more and more such devices, and as service providers try to respond defensively to this increased complexity we may start to hear more clamour for proprietary and closed systems as a defensive strategy based on “security through obscurity”.
John’s Comments:
Thanks to all for the exchanges so far.  I've made a few observations in the attached and I think what this exercise has done for me has highlighted what is it we are trying to do with this Committee Note.  Are we trying to say how to use each of the closely related patterns in an IoT context or are we trying to highlight just the new issues that the IoT brings into play. 
 For me it's the latter and to that end I think we need some general preamble up front saying most of the patterns apply as is, with perhaps some short examples, and then just highlighting the small number, maybe 3 or 4, where there are some specific new issues brought in by the IoT, eg data usage and privacy, stakeholder engagement, technology management.
 The CN needs to be short and sharp and I'm sure if we get into writing too much about too many patterns we'll end up with something that is far too long.  So let's focus on just the IoT issues IMO.
 Getting agreement on this point will help resolve the points raised by Mark, Hans and Chris, so views please.
Colin’s Comments:
I have tried to consolidate the comments on this one thread.
 Apologies if I have missed any.
 I agree we are heading in the right direction, generally supporting all comments, generally supporting John’s comments/mark up (and I may try and add to that in the next few days if I can grab some time).
 I wanted to quickly address Nig’s 3 questions in advance of offering any text..
 As stated in the note I think the next actions are for everyone to look at the issues raised under ‘IoT Delta’ headings and 
1)         agree that they are indeed issues
<<CW: ‘Getting there’.. but feel it needs a little more substance to be useful.  If the ‘nuts and bolts’ of the IoT are sensors, telematics, M2M etc, and the means by which it’s brought together is cloud services, big data analytics etc (because IoTs don’t have a lot of memory, storage or processing power), and the output of that is software services, mobile apps and API’s etc (basically tools that end user customers, business developers, researchers, system administrators can use to extract added value, or a benefit, or a tool to manage privacy, security, system orchestration, digital assets etc), then I think the very least we should do is mention (in the Recommendations/Benefits) that the above topics will play into/make more complex/disrupt/ existing relationships with suppliers, partners and customers.  And that is the crux of the additional focus on Governance and Management that needs to be applied in respect of IoT>>.
2)         agree that they are in the right place
<<CW: More or less..others have commented and broadly support those. We will probably need another pass tho’>>
3)         Identify any further issues that we should address in the CN.
<<CW: Kind of addressed in (1) above