Folks
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
We *are* getting there tho’.. well done Nig.
Cheers
Colin
From: tgf@lists.oasis-open.org [mailto:tgf@lists.oasis-open.org]
On Behalf Of John Borras
Sent: Tuesday, 5 August 2014 9:33 p.m.
To: TGF TC List
Subject: Re: [tgf] RE: TGF Patterns for the IoT Committee Note
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.
John
………………………………
Nig,
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”.
Just a thought.
Cheers,
Peter
……………………………..
Hi Nig,
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?)
-
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?
Regards,
Mark
…………………………………………………………………………………………..
On 4 Aug 2014, at 11:59, hans@eprforum.no wrote:
Hi,
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.
Nig, I have earlier sent some slides of eDevice templating descriptions. Will it be useful trying to explain these OASIS CAM eDevice templates dictionaries in a more easier way for non technical people ?
Best regards
Hans
………………………………………………………………………………………………………………………………….
Thanks for your comments.
No I don’t think that there are gaps in the TGF – indeed I think it has stood up to the test very well. What I produced are working
notes without too much consideration of the wording (apologies for that). The aspects that I have mentioned under ‘IoT Delta’ are those where I feel this CN needs to say something – primarily by building on what the TGF already says but applying it a little
more closely and overtly to the IoT aspects. In a sense this could be seen as being as profile of the TGF.
Lovelace Road, Bracknell, Berkshire, RG12 8SN
Tel: +44 (0) 843 354 5637 Internal: 7444 5637
Mob : +44 (0) 7867 833147 Internal: 7383 3147
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?
Citizen Service Transformation
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 21st
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.
In either case, I would appreciate comments as requested above ASAP and, wherever possible, I will incorporate them into a further issue
of this note.
Lovelace Road, Bracknell, Berkshire, RG12 8SN
Tel: +44 (0) 843 354 5637 Internal: 7444 5637
Mob : +44 (0) 7867 833147 Internal: 7383 3147
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU.
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU.
|