[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER
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 ==== ==== |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]