ATIS 0200009-2012 Cloud Services Lifecycle Checklist.pdf

1、 ATIS-0200009 ATIS Standard on - CLOUD SERVICES LIFECYCLE CHECKLIST As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priorities. Through ATIS committees and forums, nearly 200 companies a

2、ddress cloud services, device solutions, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lifecyclefrom design and innovation through solutions that include standards, specifica

3、tions, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a membe

4、r and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit .Notice of Disclaimer and B) guidelines on how to do it with the results experien

5、ced, respectively. The framework is goal-oriented and categorized; goals are listed; and, per categorization, guidance with associated detail to achieve those goals in the given category is provided. The framework acts as a “checklist factory”. It is intended to be used to produce a given checklist

6、for a given context. That context, in turn, is selected from a comprehensive set of categories (i.e., cloud models and vector subareas) combined with the rest of its respective context hierarchy (i.e., lifecycle function, primary stakeholder & focus goals). Regarding the framework input, note that t

7、he categories envisioned at the time of this writing are shown in initial caps format under the columns shaded in red. Also note that the framework input honors the previously described context hierarchy, represented by both the blue and red shaded areas. ATIS-0200009 12 Table 7 - Framework Inputs a

8、nd Categories LIFECYCLE FUNCTION PRIMARY STAKEHOLDER & FOCUS PRINCIPAL GOAL PRIMARY STAKEHOLDER & FOCUS VECTOR GOAL CLOUD MODEL VECTOR SUBAREA CHECKLIST SERVICE MODEL SERVICE TYPE DEPLOYMENT MODEL & TYPE FUNCTIONAL REQUIREMENTS CHECKLIST ITEMS NON-FUNCTIONAL REQUIREMENTS CHECKLIST ITEMS XaaS-NIST SP

9、I SaaS, PaaS, IaaS Public, Private, Community/Vertical, Hybrid Burst, Span, Storm, Source Connectivity Subareas, Compliance Subareas, Compatibility Subareas, Contractual Subareas , Conformance Subareas NIST Standard Use Cases, ODCA Standard Use Cases, ATIS CSF Use Case Enhancements to such based upo

10、n the corresponding ATIS CSF CDN-I, VDI and Inter-provider Telepresence Requirements Checklist items to satisfy the functional requirements. Availability, Accessibility, Accuracy, Alarming, Archiving, Audit-ability, Capacity, Compatibility, Data Completeness, Data Consistency, Data Integrity, Extens

11、ibility, Flexibility, Maintainability, Monitoring, Performance, Recoverability, Scalability, Timeliness, Usability Checklist items to satisfy the non-functional requirements. XaaS-ATIS CSF CDN-I, VDI and Inter-provider Telepresence Public, Private, Community/Vertical, Hybrid Burst, Span, Storm, Sour

12、ce Connectivity Subareas, Compliance Subareas, Compatibility Subareas, Contractual Subareas , Conformance Subareas, Custom Subareas ATIS CSF Standard Use Cases and Requirements Checklist items to satisfy the functional requirements. Availability, Accessibility, Accuracy, Alarming, Archiving, Audit-a

13、bility, Capacity, Compatibility, Data Completeness, Data Consistency, Data Integrity, Extensibility, Flexibility, Maintainability, Monitoring, Performance, Recoverability, Scalability, Timeliness, Usability Checklist items to satisfy the non-functional requirements. ATIS-0200009 13 The XaaS-ATIS CSF

14、 service model includes those higher order service types that are the focus of ATIS CSF agenda: CDN-I, VDI, and Inter-provider Telepresence Requirements. Its checklist items correspondingly include the ATIS CSF use cases and requirements from other ATIS CSF contributions dealing with these service t

15、ypes. The XaaS-NIST SPI service model represents the SaaS, PaaS, and IaaS standard core service types as defined by NIST. However, for functional requirements its checklist items use the standard NIST use cases, the standard ODCA use cases, the ATIS CSF enhancements to those use cases (when needed),

16、 and the corresponding ATIS CSF requirements derived from such and defined for each XaaS-ATIS CSF service type: CDN-I, VDI, and Inter-provider Telepresence Requirements. This allows for the XaaS-ATIS CSF service model to be distilled to the granularity required using the underlying NIST standard cor

17、e service types when providing guidance in the framework output. Note that non-functional requirements also are included in the checklist items as appropriate. Table 8 - Framework Outputs and Categories VECTOR GOAL EXECUTIVE GUIDANCE DIRECTION/COURSE FOR GOAL PEOPLE & PROCESS TOOLS TIMELINE SOLUTION

18、 COMPENSATING CONTROL TESTING PROCEDURE STANDARD TOOL METRIC MILESTONE DATE Experienced Solution Experienced Control Experienced Procedure, Guideline Procedure with Control Points Experienced Standard, Guideline Standard with Control Points Experienced Tool, Guideline Tool Experienced Metric, Guidel

19、ine Metric Experienced Milestone, Guideline Milestone Experienced Date The framework output shown above is mapped to an individual vector goal in the framework input. It first provides vector goal executive guidance and then subsequently details such in the context of the people & process, tools, an

20、d timeline needed to achieve said goal. The framework output is a product of an individual application of the framework and is defined during exercise of such using the provided guideline process and tool items. With respect to people & process, solutions are provided by the end user corresponding t

21、o the checklist item. For those checklist items that cannot be fulfilled, equivalent compensating controls achieving the same end are instead described. Further, testing procedures and corresponding standards that should be applied to achieve the vector goal are recommended by the framework along wi

22、th their respective control points. With respect to tools, the tools suggested to augment the process guidance and the associated metrics to measure the results of such are described by the framework. Finally, with respect to timeline, suggested milestones are provided to outline the major steps in

23、the cloud services lifecycle for the given context. Note that the initial caps format is used to depict value categories in the framework output shown above. 5 Framework Lifecycle The framework itself must evolve to accommodate the rapid change occurring in the various cloud models and thus must hav

24、e a lifecycle of its own. Examples of change could include extending the framework to new CSF service types such as CDN-I, VDI, and Telepresence within a given cloud model. There are two main phases to the framework lifecycle: formalization and automation. ATIS-0200009 14 5.1 Formalization Formaliza

25、tion includes definition of and update to the framework and artifacts surrounding such for use in a given context. Updating the existing models, defining new ones, specifying stakeholders, specifying their respective focus and goals, and updating the framework inputs and respective framework outputs

26、 all are part of formalization. The artifacts involved would primarily be checklist items which could be used in a manual process (e.g., RFI, RFP, RFT, RFQ) to adjudicate the cloud service providers cloud service lifecycle offerings. In the formalization phase, the checklist item is a question that

27、the corollary actor uses as a means of discovery of the cloud service provider. 5.2 Automation Automation includes realizing the framework definition and artifacts from the formalization phase, which are predisposed to such (e.g., control points), in a software system. More specifically, this includ

28、es creating a means of query and response regarding predefined checklist items in predefined contexts from the formalization phase. Here, the discovery has been completed and the checklist item now is automated and becomes a service provided by the cloud service provider. Automation represents a val

29、ue add to cloud service providers and can be used by their corollary actors to programmatically adjudicate the providers cloud service lifecycle offerings. 5.3 Framework Lifecycle Outline The framework lifecycle is outlined below. Phase 1A: Formalization of the Framework Inputs Context Hierarchy. o

30、Define and/or update the Principal goals model. Define and/or update the Stakeholders and their focus. Define and/or update their Principal goals per lifecycle function. Build (ASSESSMENT, ACCEPTANCE). Capture (AUDIT). Modify (AUGMENTATION, ABRIDGING, ANNULMENT). o Define and/or update Custom Vector

31、s and Vector subareas. o Define and/or update the Vector goals model. Define and/or update the Stakeholders and their focus. Define and/or update their Vector goals. Build (ASSESSMENT, ACCEPTANCE). Capture (AUDIT). Modify (AUGMENTATION, ABRIDGING, ANNULMENT). o Define and/or update the Cloud Models.

32、 o Define and/or update the Vector Subareas. o Define and/or update the Context Hierarchy model. Assemble the primary stakeholder and focus principal goals, the primary stakeholder and focus vector goals, the cloud models and the vector subareas. o Define and/or update the functional requirements fo

33、r a given context. o Define and/or update the non-functional requirements for a given context. ATIS-0200009 15 Phase 1B: Definition of the Framework Inputs Checklist Items. o Utilize context worksheet techniques to derive the checklist items. Identify, aggregate, and multi-dimensional analyze key ph

34、rases in each level of context. Derive the corresponding checklist item(s) against the given requirement in the given context detailing such in the categories of People & Process, Tools and Timeline. People & Process (Solution/Control/Procedure/Standard). Tools (Tool/Metric). Timeline (Milestone/Dat

35、e). Phase 1C: Formalization of the Framework Outputs Guidelines and Control Points. o Define and/or update Framework Outputs guidelines and control points based upon the updated Framework Inputs. Process Testing Procedure o Guideline procedure with control points. Standard o Guideline standard with

36、control points. Tools Tool o Guideline tool. Metric o Guideline metric. Timeline Time o Guideline milestone. Phase 2: Automation of the Framework Inputs and Outputs. o Define and/or update the Enablers in a software system. Framework Inputs Define query facilities for checklist items in context(s).

37、Framework Outputs Define response for context and include actual along with guidelines and control points. 6 Goal Oriented Architecture This section describes the Goal Oriented Architecture (GOA), select components of such, and what role each performs with respect to the Cloud Services Lifecycle Che

38、cklist Framework. Note that this document assumes the reader is familiar with the concept of Service Oriented Architecture (SOA), and Service Enablers. There are multiple references available with respect to the former. See ATIS-0200001, Service Enabler Characterization Technical Report, for more in

39、formation regarding the latter. ATIS-0200009 16 6.1 Service Enablers The Service Enabler represents a step towards automation in exercising the framework and has a primary role regarding such: facilitating automatic adjudication of the cloud services as is programmatically feasible from a service or

40、iented perspective. In short, this includes qualifying a given service for use through characterization of that service. 6.2 Goal Enablers Similar to the Service Enabler, the Goal Enabler also represents a step towards automation in exercising the framework and has a primary role regarding such: fac

41、ilitating automatic adjudication of the cloud services lifecycle as is programmatically feasible from a goal oriented perspective. In short, this includes qualifying a given course of service for use per a specified goal through characterization of that goal. This includes managing the permutations

42、of framework inputs applicable to the given cloud services environment and the corresponding framework outputs that satisfy such in order to adjudicate the cloud services lifecycle. The Goal Enabler simply adds another layer of characterization beyond the Service Enabler, and is thus a higher order

43、form of such. 6.3 The Goal Oriented Architecture The GOA is a level of abstraction above SOA. Whereas SOA presents a service as a discrete unit of function, GOA presents a goal as a discrete course of service. Using SOA components as constituent parts, GOA describes the course to satisfy the goal. L

44、ikewise, using Service Enablers as constituent parts, Goal Enablers enable GOA automation to that same end. Succinctly put, with respect to the framework an actor would present an XML document describing a goal in a context to satisfy a cloud service lifecycle need. The actor would in turn receive a

45、n XML document describing to what degree and in what manner (per the categories of people & process, tools, and timeline) to meet that goal in that context (direction/course for goal). If needed, “fallout” from such would defer to an exception-based manual process similar to what was suggested in th

46、e formalization section above. Here, discovery occurs to satisfy that goal not automated to a sufficient degree. Once discovery is complete, the respective goal could then be updated in the automation as an ongoing process of enhancement. 7 Encoding To better support automation, GOA and the Goal Ena

47、bler approach, a means of encoding may be appropriate in order to effectively describe programmatically the full breadth of lifecycle functions, contexts, use cases, checklist items, service levels, and so forth common across the industry. While the exact form it takes is beyond the scope of this do

48、cument, an overview of a candidate scheme is mentioned here for future consideration. Briefly put, schemes similar to that employed in the medical industry could also be used in describing cloud service characteristics, goal characteristics, formulations, and the conditions they are appropriate for.

49、 These in turn could be used to support automation in a uniform, reusable manner across the industry. For example, a scheme similar to ICD-9 (International Statistical Classification of Diseases and Related Health Problems) used to classify and encode diseases, injuries, symptoms, and conditions could be used to classify and encode all aspects of framework inputs (conditions). Likewise, a scheme similar to CPT (Current Procedural Terminology) used to classify and encode medical and surgical services performe