Kevin Jackson - DoDIIS Worldwide 2010

2. Cloud Computing. Not a Panacea Lower Gain From Clouds Higher Gain From Clouds Lower Pain To Cloud Delivery Higher Pain To Cloud Delivery Collabora -tion Transactional Content SME ERP LE ERP On-Line Storage Web2.0 Application Dev’t. DB Migration Projects Data Archive Situational Apps Web Scale Analytics [Enterprise Data] Dep’t. BI Applica-tion Test US Situational Awareness European Situational Awareness US has more network bandwidth available in the battlefield, therefore higher gain from using external cloud Courtesy IBM “ DB-Centric” Architecture “ Content-Centric” Architecture “ Loosely Coupled” Architecture Storage and Data Integration Architecture

4. Sample Functional Capability Profile Narrower Scope Broader Scope Mission Requirement Solution Capability X X Capability C6 C1 C2 C3 C4 C5 C6 C7 C8 Requirements Capabilities Capability/Domain Independent Technical/Economic Feasibility

5. Technical Feasibility Dimensions Value Dimension Smaller Risk Larger Risk Inter-System Time Binding to Achieve Capability Strategic Tactical Transactional Real Time Run-Time Computing Resources Needed <1% of existing system resources 1-10% 10-50% >50% of existing system resources Service Mgmt. Resources Needed Negligible Within Current Net Service Capacity Within Planned Net Service Capacity Beyond Planned Net Service Capacity Net Resources Needed (FD) Negligible Within Current Net Capacity Within Planned Net Capacity Beyond Planned Net Capacity Interface Development Complexity <1% of system size 1-10% 10-50% >50% of system size Technology Readiness Level For Net Use TRL Levels 8-9 TRL Levels 6-7 TRL Levels 4-5 TRL Levels 1-3

6. Domain Dependent Values Cloud Computing SCOPE Model Management Coupling What is the degree of coupling between operational responsibility and execution resource ownership for: Network Resources Computing Platform resources Data resources Service resources What is the degree of coupling between relationship management and consequence management Range of Services What is the dynamic range of services associated with: Platform scalability Storage scalability Network access scalability/Network entity reach Types of applications supported Types of coupling to the physical environment Types of coupling to the political/social environment Network Infrastructure Capacity What is the network infrastructure capacity between cloud provider and consumer? LAN Bandwidths WAN Bandwidths and latencies Mobile network Bandwidths and latencies Dedicated communication links (point to point) Low bandwidth and intermittent links Asymmetric network links Platform Types What execution platform types are provided by the cloud? Domain Specificity What is the degree of domain-specificity of the cloud-based services offered? Data portability Service Level interoperability Levels of privacy/security/anonymity Levels of redundancy and/or physical dispersion Speed of allocation of resources Level of management visibility/control

7. Mission Driven Cloud Computing Solutions SCOPE MODEL General Net-readiness Capability/Domain Dependent Capability/Domain Independent Technical/Economic Feasibility

Notas do Editor

Cloud computing is no panacea. It’s not the right choice for every mission nor is the effort to build a mission-specific cloud always worth the cost. With this in mind, how should organizations go about deciding if cloud computing is appropriate?
Clouds provide capabilities and act as an abstraction layer above the underlying systems and technologies. This make a explicit methodology for measuring capabilities a critical tool in developing cloud-based systems. A future world of inter-clouds will only increase this need. Luckily, the Network Centric Operation Industry Consortium (NCOIC) has such a tool. For your background, NCOIC is a global industry consortium focused on network centric, industry neutral, best practices that support the work of central governments worldwide. The Systems, Capabilities, Operations, Programs, and Enterprises (SCOPE) Model for Interoperability Assessment, or SCOPE tool, offers a means for characterizing system capabilities in a definitive way. Other well know tools, such as the LISI model and DoDAF views don’t do this. SCOPE can also be used as a way of normalizing these and other interoperability strategies and processes. Boeing, LMCO, SAAB, Raytheon and others have adopted SCOPE but we are now customizing it for cloud computing. Using SCOPE, organizations can quantitatively and qualitatively measures how well a system can operate in a network centric environment. The addition of cloud computing domain specific dimensions and metrics can provide a means for directly mapping mission requirements to available, or planned, cloud computing capabilities.
To conceptualized this process, let’s say you have a mission that requires capabilities C1 through C8. Using the SCOPE methodology, the program manager could quantitatively and qualitatively evaluate options. Here I have only shown the Domain Independent and Technical/Economic Feasibility categories. The scale measures Capability C6 along a specific dimension. Below that, the Kiviat diagram aggregates all of the measured capabilities, presenting an aggregated view that compares mission requirements to the proposed solution’s capabilities. The resulting spider graph
This chart gives you an idea of some of the SCOPE technical feasibility dimensions. Technical Feasibility dimensions assess the degree to which the interface services between systems are technically feasible given the technical architecture constraints and resources available to effect the interface services. This chart presents technical feasibility as increasingly more challenging as one moves from level 1 to level 4. This corresponds to the increasing impact on program or capability implementation cost and risk as one moves to the right, as has been done with the other dimensions. A key technical feasibility measure is the degree of time-binding needed between systems to effect a capability. The tighter the time binding, the greater the demand on the technical architecture elements used to implement the interface service. Often the technical architecture elements make it infeasible to meet the time-binding needed to support a capability like time-critical targeting or ballistic missile defense. One resource requirement dimension is shown here as being that of GIG/NCES resources needed by the systems involved to implement a given capability at some Measure of Effectiveness. Typically this would be bandwidth on some portion of the GIG network, but it could also be some service invocation rate for NCES or COI services. Another technical feasibility measure is whether a particular system interaction will require a significant portion of run-time computing resources of the current or envision systems. Since it is difficult to talk about technical feasibility in absolute terms (given enough time and money, almost anything is technically feasible), the measures shown here are relative to the overall sizing estimates or actual costs incurred for the systems envisioned or involved in implementing an operational capability. As technical feasibility becomes increasingly challenging as the resources required for a capability consume increasingly large portions of the overall system capacity. Similar logic applies to the dimension of interface development complexity, although this dimension is more an acquisition time concern than a run time concern (although it may also impact the ease of change/evolution over the life cycle of system/interface). Again, this dimension is best measured relative to the overall scope of the envisioned system or capability. When an interface needed to effect a capability begins to dominate the development size of the system being acquired, sponsors may well consider it to be technically infeasible. They may also question whether the technical architecture assumptions might need to be re-examined and newer/alternate technologies and technology standards considered. The technology readiness level dimension applies in the case where an operational capability requires technical architecture elements that are not yet part of the baseline. In other words, the capability is feasible if we relax the technical maturity level below production level. However, lower TRL’s imply added development cost and technical/schedule risks and thereby impact the feasibility of implementing a particular capability.
Here are some of the Cloud Computing domain specific characteristic we have added to the SCOPE methodology. Since the user doesn’t own the cloud infrastructure, the degree of coupling between operational responsibility and resource ownership is an important facet. For example, coupling between the operational responsibility of a military unit to a DISA cloud would be much tighter that the coupling between that same unit and a commercial cloud service. Looser coupling implies more risk. By enhancing the basic SCOPE model with cloud computing specific dimensions like these, advantages and disadvantages of using a a cloud can be quantitatively and qualitatively measured and compared with other, more traditional options. A future world of inter-clouds will only increase the importance of methodologies like this.
Though the use of this enhanced SCOPE methodology, cloud computing solution design can truly be mission driven.

Kevin Jackson - DoDIIS Worldwide 2010

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (11)

Semelhante a Kevin Jackson - DoDIIS Worldwide 2010

Semelhante a Kevin Jackson - DoDIIS Worldwide 2010 (20)

Mais de GovCloud Network

Mais de GovCloud Network (20)

Último

Último (20)

Kevin Jackson - DoDIIS Worldwide 2010

Notas do Editor