[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER
Thanks for your views and Hi to Doug - welcome to the discussion. I think we are all agreed that there is clear space in what we are trying to do, ie covering ground that is not being addressed elsewhere and producing something that would be valuable to public sector managers. Therefore the TC should go ahead providing we can get sufficient support. So the hard part now then is to agree a provisional list of deliverables that can we substitute for the list in the draft Charter attached. Red pens to the ready then everyone!! Seriously though whilst I’m more than happy to be the Convenor of this Discussion I can’t be the only brain writing the Charter, I need you guys to give me the necessary ammunition. Can you post your suggestions for a specific set of deliverables please, not just commentary, and I’ll pull them together. Just a reminder, if our target is to launch this TC at the ICS event in Washington on 10-12 October we do need to wrap up this Discussion List fairly soon to allow the necessary time for the submission and announcement of the TC. So whilst we need to get this right before we proceed we should try and resolve this aspect in the next couple of weeks if possible. John From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of Doug Newdick Hi, Apologies for coming in to this discussion a bit late, and perhaps uninformed. My colleague Colin Wallis suggested that I might find the work being done here of value. From my point of view the single most important question is: Are the requirements of public sector agencies different enough from those of the private sector to warrant a separate TC, and producing the deliverables suggested? I think that the answer is "yes", but I don't believe that it is obvious. When I look at the issues that concern me about cloud adoption versus those that worry my private sector counterparts I see the following differences: 1. Public sector agencies are more concerned about security. 2. Public sector agencies are more concerned about privacy. 3. Public sector agencies (at least in NZ) are concerned about maintaining the "public record" - something that is of little concern to the private sector. This includes making these records available when requested by Official Information Act requests. 4. Public sector agencies are concerned about "sovereignty" - this is a term that wraps up worries about national and commercial jurisdictions. Many of the differences are quantitative differences, not qualitative - we are more concerned about certain matters than the private sector. You could argue that items 3 and 4 are more specifically public sector only. I believe that public sector agencies will get value from this exercise to the extent that the list of features and requirements (as described in the charter) can be used to inform RFPs, vendor and service evaluations or drive the creation of cloud services. My concern is that we will not be able to get that value without including some level of technical requirements. To that extent I favour carrying on this discussion further. Cheers, Doug Doug Newdick Enterprise Architect Government Technology Services The Department of Internal Affairs Te Tari Taiwhenua Direct Dial: +64 4 474 8110 Extn: 8110 From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of Peter F Brown +1 From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of Colin Wallis Personally I favour a bit more discussion first. Maybe look at a few other examples.... IMHO if we go the generic summary too early, we may risk the perception that there is not enough ‘meat’ in the resulting requirements to deliver something of value. Cheers Colin From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of John Borras OK let’s step back a bit. If, and I stress if, the main objective of the TC is to “develop and deliver a non-technical implementation/conformance profile for government, which provides common, readily-understood rules that inform assurance and conformance testing and acquisition criteria” as I suggested the other day, then we have to ask ourselves what elements can be included in such a profile. They need to be ones that are measurable and can be tested and that therefore would exclude the needs and goals aspects that Peter highlights below. So the main question at this stage is do we agree on the prime deliverable from the TC as stated above? If so then we would do well to recruit into the TC some procurement and accreditation experts to help define what elements could and should be included in such a profile. We can also discuss at that stage what constitutes a functional and a non-functional requirement and also what constitutes a technical and non-technical one. Do I therefore re-draft the Charter with a much more generic summary of the TC deliverables to get us going, or do we continue this discussion to agree a final detailed list of requirements before starting the TC? John From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of Peter F Brown Colin, The OGF paper certainly helps by laying out a clean set of functional and non-functional requirements (FRs and NFRs) - although I don’t understand why some FRs appear as NFRs, such as “security”; or some are stated as FRs whereas, I would argue, they are not requirements at all, but “needs” or “goals” (such as “[API] calls must return quickly”) – important considerations but not requirements. I guess my feeling is not whether we are going for “shallower” or “deeper” in terms of requirements but rather whether we want to express “requirements” in the broader sense: more “API calls must return quickly” than “a JSON-scripted call should respond within 500ms”. In the SOA Reference Architecture Framework we make a distinction between these, in terms of “needs” (broadly stated, “know it when I see it”) and “requirements” (formally and tractably stated, specific, measurable, etc.) but I don’t want to confuse the terminology of this discussion further (at least not now!) Also, you call out the three classic layers of IaaS, PaaS and SaaS and flag the need for requirements for each – but what about requirements for interoperability between different offerings at the same layer, IaaS to IaaS, for example. Peter From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of Colin Wallis Hmm.. Well we need to take a deeper look at these items from the charter...and decide what we would expect to see in the deliverable. 1 A base set of required attributes, expressed as architecture-neutral functional features, that generally should be sought in any cloud or remote computing infrastructure employed by or on behalf of governments (including computer networking, network management, data storage and shared repository, service or device management and virtualization management). 2 A base set of required attributes, expressed as architecture-neutral functional features, that generally should be sought in any cloud or remote computing platform services employed by or on behalf of governments (including common transactional, eventing, notification and messaging operations such as middleware and enterprise service buses, and interaction patterns and protocols among autonomous physical or virtual machines). 3 A base set of required attributes, expressed as architecture-neutral functional features, that generally should be sought in any cloud or remote computing data application services employed by or on behalf of governments (including application program interfaces (APIs) and end-user software applications). Some folks might expect to see something like this….as I highlight attribution to OGF and the author… J http://ogf.org/documents/GFD.162.pdf To take this as a benchmark, would folks consider this technical, or non technical? Is this the flavor of the deliverable we expect to get? Something even deeper? Something shallower? Cheers Colin From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of John Borras Colin A fundamental point here, what should be regarded as technical and what non-technical? The list and Charter was drafted by Jamie not Belgian SPFF colleagues and my interpretation is that his list is non-technical things but I can appreciate that may be open to debate. So we need to clarify and agree this. Without question this TC is focusing on non-technical requirements as there is already a plethora of other groups working on technical aspects, so the list has to be unambiguous about that. Just a reminder of the process, the purpose of the Discussion List is to agree whether we should proceed with the TC or not, and not to necessarily to agree a final Charter, although a near final version would be good. So for now let’s not get too hung up on word-smithing the list other than to be very clear about what the list should or should not contain. I know it’s perhaps a bit of chicken and egg in that people want to see the proposed outputs before agreeing to get involved or not, but I think perhaps we should at this stage just put in some overview of the outputs rather than a definitive list. Does that make sense, if so any suggestions for some overview wording of the outputs from all on the List would be appreciated. John From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of Colin Wallis +1 to Peter’s view on the title. <<The TC will develop and deliver a non-technical implementation/conformance profile for government i.e. the features that governments want to see in cloud offerings to government. The profile will include as a minimum the following:>> Hmm..I see what you are trying to get to here, but for me it’s not quite there yet. The thing is that much of that list *is* technical and I suspect Belgium wanted that. What it didn’t have is the (non technical) process (and to a lesser extent but my implication workflow) piece to balance it such that you can achieve and measure both technical interop and non technical process standardization. This latter piece is what in Kantara parlance is called the Service Assessment Criteria (SACs) So I think the better way to tackle it is to remove the ‘non technical’ reference to the sentence above, but add an additional bullet to the list that addresses the non technical process requirements for standardization Cheers Colin From: public-sector-cloud-discuss@lists.oasis-open.org [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of Peter F Brown John, From: John Borras Colin ==== ==== ==== ==== |
Attachment:
PACR-draftcharter-20120625.rtf
Description: MS-Word document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]