[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tgf] RE: Issue 13 (General)- Technology Management Framework - need to include Core Standards Set? - open
On the first point about a common set of core technology standards, the conclusion we came to in the CS Transform paper was that most/all governments were spending a lot of time and effort creating and maintaining their technical standards lists, which by and large was a waste of time because as there is so much commonality a more global approach would save time and money all round. Finding a body to take on that function though would be the sticking point as we said. If this TC or the eGov MS can do something to help with this issue then great, but as both Peter and Andy have pointed out, and as was evident from our CST research, maintenance of a list is essential otherwise it soon becomes useless shelf-ware. For now can we park this discussion because it is not an issue for the Primer. We can come back to it after we’ve got that stake in the ground. On the revised wording and diagram for Collaboration between Programmes, both seem clear enough to me and make the point succinctly. In terms of placement within the Primer I would leave it where we currently have it. Although it might be of more general interest it is, unless I’m mistaken, not proven in practice, ie there are no current examples of inter-programme collaboration, so high-lighting it too much might be unadvisable at this stage. But I’d welcome Chris’ view on this. Clearly we need early closure on this issue so that we can get to agreement on the Primer next week so can I ask for any views to Peter asap please. John From: Peter F Brown [mailto:peter@peterfbrown.com] Andy, Thanks for this. I think your ideas are spot on the money. I’d definitely be in favour of an approach that favours identifying broad categories and items of ‘functionality’ (in the broadest sense) and ‘what you should look (out) for in a standard’ to address those functionalities, rather than a hard-wired, tight-coupling. At a more detailed level – keeping track of which standards are best adapted to which problem; who is using which ones; what are the latest versions, etc – I have drafted (but not yet submitted) a possible work item to the ‘OASIS eGov Member Section’ that could take this further. I’ll talk with John (with his Member Section Chair hat on) and we can report back to the TC about whether we think the idea has legs and whteher it should be pursued as a Member Section work item or be dealt with in the TGF… In the meantime, below is some draft wording that I have proposed at the end of the collaborative stakeholder governance section that Nig, Chris and I worked on after last Thursday’s call – you will see in the final paragraph the relevance and link to your arguments - but, as I’ve mentioned to Nig and Chris, this might be placed elsewhere as it is of more general interest, not just restricted to the stakeholder model. Comments on both the wording and the placement are welcome. Cheers, Peter == draft – not for citation == Collaboration between TGF Programs The [collaborative stakeholder] model clearly focuses attention within any specific TGF program. However (and increasingly) collaboration is required also between governments and, by implication, between TGF programs. In the figure below, we see that collaboration between TGF programs is favoured at the political, legal and organisational levels and only later, if and when necessary, at the more ‘tightly-coupled’ semantic and technical levels. This approach is also consistent with the SOA paradigm for service development – not only are requirements defined and services offered independently of any underlying technology or infrastructure but also one TGF program can be seen (and may need to be seen) as a ‘service provider’ to another TGF program’s ‘service request’. For example, a business wishing to establish itself in a second country may need to provide credentials and government-authenticated information that is managed by a government agency in the first country. A further advantage of this approach is that it becomes easier to identify and manage high level government requirements for services: whether in the choice of ICT standards that may need to be used to address a particular technology issue or determining the criteria for awarding public procurement contracts, this approach allows a ‘loose-coupling’ at the level of clearly defined high-level policy needs rather than the more tightly-coupled and often brittle approach of specifying particular technologies, software or systems. == end == From: Andy Hopkirk [mailto:andy.hopkirk@gmail.com] hi - sorry been out of the loop recently and not able to contribute... re: lists of standards... On Tue, Mar 1, 2011 at 9:54 PM, Colin Wallis <Colin.Wallis@dia.govt.nz> wrote: Yep, I think giving examples of profiles of standard X or Y would offer more value, but they are just examples, since there are country or industry specific contexts for them in most cases so they may not suit all situations. Cheers Colin From: Greenaway Nigel [mailto:Nig.Greenaway@uk.fujitsu.com] I'm happy that we address this aspect later. Nig: I’m taking your different points as separate issues. John has already commented: “It has always been my intention to address this point once we have got the Primer out of the way. I would like to set up a sub-committee to produce the core set of standards and then we can issue them as a CN or possible look for some other body to take them on and maintain them. And in the same vein I want to do some work on common data standards but again that’s for later. So can I propose we defer anything further on these aspects for now?” My own view (as TC member, not as an editor): I agree that we should defer for now. I’m not convinced (any more, although I’m probably an apostate on this) of the value of lists of core standards – our emphasis ought to be shifted towards lists of core functional issues that standards ought to address. Standards may, do, evolve in light of technological change, but core functional requirements (defined in the broadest sense) tend to persist more and are less prone to updating and currency problems. Other comments? Peter From: Greenaway Nigel [mailto:Nig.Greenaway@uk.fujitsu.com] There are some items that do not have a home indicated for them in the document. They probably belong in Part III(d). and will probably be separate committee Notes but probably need to be discussed by the group (perhaps initially on the call later this week?).as The areas that come to my mind (there may be more) are: 1. Core Standards Set. One of the CSTransform papers identifies a long tail of standards when various Ifs are surveyed. It would seem sensible for us to at least have a stab at defining the core set. Possibly, this could be done alongside and take cognisance of the UK Standards survey that is currently being undertaken. ==== |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]