[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER
|
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 ==== ==== ==== CAUTION: This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you. ==== |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]