Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 1 Establishing a Network Centric Capability: Implications for Acquisition and Engineering DENNIS SMITH DYNAMIC SYSTEMS, SOFTWARE ENGINEERING INSTITUTE ______________________________________________________________________ 1. Introduction The landscape of system development and evolution has changed significantly over the past decade. It is a truism that many government and commercial systems can no longer be thought of as individual systems developed and acquired through traditional means. Instead the trend is approaching systems that have been characterized in a number of ways as systems of systems (Maier, 1996), complex systems (White, 2006), ultra-large systems (Northrop, 2006), cyber systems (Fifthen, 2006). The precise characteristics and definitions continue to emerge as systems of systems become more predominant and increase in complexity. The definition and characteristics of such systems will be discussed through a number of other papers in this symposium. This paper focuses on specific challenges of migration to network centric operations. Network centric operations refers to the moving and sharing of information in an agile manner among personnel and systems with the network as a central enabling mechanism for the sharing of information. Section 2 outlines a preliminary set of acquisition and development strategies that need to be considered in developing a network centric capability. Since a migration to network centric operations implies the use of a service oriented architecture (SOA), section 3 identifies a set of key SOA challenges that need to be addressed. 2.0 Establishing a Network Centric Engineering Capability A key for developing capabilities that can support network centric operations is agility. Capabilities must be assembled rapidly and address real problems. Engineers building these capabilities should have ready access to the latest technologies, and most importantly, an ethos of agile support. Building on the work of White (2205) and Cherinka (2205), as well as deriving from a set of strategies proposed by Morris and Place (2007), we recommend the following strategies: • Identify Engineering Implications of Network Centric Missions Copyright 2006 Carnegie Mellon University 1
  2. 2. 2 • Adopt an Inclusive View of the Network Centric Community • Characterize the Existing Technology Base • Characterize the Gaps between Doctrine/Mission and the Technology Base • Collaborate with Others to Develop Governance Rules • Establish a Network Centric Integration Environment • Establish a Reward Structure • Train Network Centric Command and Engineering Staff • Prepare for Novel Forms of Acquisition These strategies are discussed in subsequent sub-sections. 2.1 Identify Engineering Implications of Network Centric Missions As suggested by Gabbard (2206), the first priority should be to determine the strategic and tactical missions that Network Centric operations will perform. These definitions are as critical to identifying and constructing necessary computing support as they are to understanding future training and continuing education requirements. Developing missions that are network centric analogues of existing missions will lead to an initial set of useful missions. The network centric missions should be defined in terms of broad characterizations of the desired outcomes rather than specific solutions. White (2005) suggests that good outcome spaces include “own the night”, which encouraged development of several night-fighting capabilities, and the DARPA Grand Challenge, which lead to rapid improvement in self-guided vehicles. We recommend the following analysis activities to determine the engineering support for network centric operations: 1. Describe missions in sufficient detail to determine the types of information and steps necessary to perform the missions. 2. Gather information on the processes, capabilities, techniques, and system support used to perform analogous physical missions 3. Gather information about the types of collaboration tools necessary to support network centric operations (i.e., the distribution of personnel across many locations) 4. Derive broad outcome spaces. These outcome spaces should identify the types of capabilities necessary to support pragmatic needs of operational users 2.2 Adopt an Inclusive View of the Community Copyright 2006 Carnegie Mellon University 2
  3. 3. 3 In order to gain maximum advantage, network centric planners need to take a very inclusive view of the community. We recommend the following groups be considered as part of the community: • All organizational components • Collaborating organizations • Open source communities • Vendor and standards organizations • Academic researchers • Potential end users and customers 2.3 Characterize the existing technology base There is a large amount of effort being expended in moving toward network centric operations among DoD organizations, the Department of Homeland Security, other government organizations, and corporations. Thus, a key challenge involves identifying existing efforts and making that information widely available to the operational and engineering communities. Recommendations for addressing this challenge are: 1. Consider a broad community in identifying useful technologies and capabilities. 2. Characterize technologies and capabilities in terms of being immediately useful, readily adaptable, and potential useful. 3. Develop a lightweight catalog of potential assets. This catalog must be actively maintained, easily searchable, and editable by participants in the cyberspace integration environment. Consider using the open source model of community maintenance of the catalog. 4. Develop capabilities to rapidly analyze and characterize components submitted to the catalog1 2.4 Characterize the Gaps between Demand and Supply In the world of network centric operations, demand is represented by the needs of operational users and supply by the capabilities and desired missions that are available and planned for. Gap analysis techniques such as MOSAIC2 and PAN3 can be used to describe the difference between demand and supply. Indeed, even within the supply side there may be gaps between the goals as defined by the broad outcomes and the capabilities available to achieve those goals. 1 The SEI has developed several processes that may be useful, including PECA, which supports the analysis of components to determine whether they are appropriate, and SMART, which analyzes legacy components to determine whether they are appropriate for migration to service oriented architecture. 2 MOSAIC information will soon be available on the SEI Web Site. 3 More information about PAN may be found at Copyright 2006 Carnegie Mellon University 3
  4. 4. 4 Use the information about operational users, the goals of network centric operations, and available capabilities to determine: • Current operational capabilities • Current and planned operational needs • Needs that cannot currently be met • activities we cannot coordinate Our expectation is that the above gaps will be fairly large, but can be satisfied in the following ways: 1. directly using capabilities from various providers in the community and adapting them to support network centric operations 2. building new capabilities from existing components 3. fostering research into novel solutions to network centric problems(e.g., identifying the “fingerprints” of adversaries in cyberspace). 2.5 Collaborate with Others to Develop Governance Rules Governance describes many facets of management and policy for systems. These facets typically include: • creating, overseeing and enforcing policy (business and technical expectation) that directs activities • coordinating people, policies, and processes • identifying rules for participation, including testing, deploying, operating, and decommissioning capabilities While network centric operations must establish rules of governance for its own systems, it cannot do so in isolation. All relevant organizations will execute strategies to defend and potentially attack in cyberspace. In order to encourage coordination, minimize conflict, and avoid duplication of effort, network centric organizations must collaborate with others to define governance: 1. Establish a governance committee and encourage participation by all relevant participants. The goals of this committee should be to: a. establish guidance for network centric operations b. establish rules for testing, deploying, operating, and decommissioning capabilities c. establish communications mechanisms that keep others informed of activity 2.6 Establish a Network Centric Integration Environment Copyright 2006 Carnegie Mellon University 4
  5. 5. 5 We believe that the majority of software and system capabilities required by network centric operations will be assembled from existing components rather than specially developed. We recommend: 1. Establishing an integration environment focused on integration of components rather than new development. We expect the integration environment will have several levels with increasing fidelity to the operational environment. These levels should support wide community participation for developing prototypes while minimizing security and other dangers to ongoing operations.4 2. Stocking the environment with tools that support the integration of independently developed components. Tools should support: a. transforming interfaces and data formats b. establishing connections between components c. mediating and coordinating among components d. analyzing and monitoring the interactions among components 3. Populating the environment with components that can be assembled to support network centric operations. The initial population should include as many readily available as possible. 4. Investigating programs with success in rapidly improving capabilities by building bridges between disparate systems5. Ideally, engineering and integration activities would occur directly within those areas where network centric operations will operate. Practically, network centric operations must provide a controlled area in which to support broad experimentation and rapid transition of ideas to, but firewalled from, operations. 2.7 Establish a Reward Structure As already stated, network centric operations cannot operate in a vacuum and will depend on the participation of others. A reward structure needs to be established that encourages wide community involvement. We recommend the following: 1. Reward participants for sharing problems, solutions, innovations, and technologies with others. 2. Reward participants for actively searching for problems and opportunities to develop useful capabilities 3. Reward participants for reusing existing capabilities rather than developing their own. 4 Control of the access to levels will vary from most permissive at the lowest levels to most controlled at the operational level. Several good arguments can be made for including adversaries at some levels: 1) The community will police itself like the open source community to quickly detect and remove malicious capabilities 2) An open approach will provide good insight into who are the potential adversaries, and what they are thinking and doing in cyberspace. 5 The SEI has seen examples of several programs of this nature Copyright 2006 Carnegie Mellon University 5
  6. 6. 6 4. Reward solutions that minimally limit the flexibility of others (e.g., open interfaces are preferable to proprietary ones) 2.8 Train Acquisition and Engineering Staff Given the nature of network centric systems, it is necessary to be prepared to work in the new environment. They must be able to synthesize and act on information from a variety of sources. In order to be effective personnel must be self-motivated and have an entrepreneurial spirit. They must be flexible and willing to change direction as needed. Individuals possessing the necessary skills are rare, thus the need to train staff with appropriate skills is more critical than ever. It may be easier to take entrepreneurial personnel and train them in the new set of skills than to take domain experts and make them entrepreneurial. Staff will be constantly performing new integrations of existing assets or developing new special-purpose tools to combat a particular threat. Thus the distinction between operational staff and engineering support staff must become increasingly blurred. We recommend the following: 1. Blur the distinction between operational and engineering support staff 2. Institute new curricula to train engineers with an emphasis on rapid integration and the use of relevant technologies such as SOA. 2.9 Prepare for Novel Forms of Acquisition The most important driver for acquisition is the ever-changing nature of network centric operations. Thus the acquisition strategy cannot be based on a traditional strategy of acquisition of large, long-term solutions. We recommend the following: 1. Adopt an agile acquisition strategy that provides rapidly assembled solutions for short-term problems. 2. Prepare to acquire imperfect tools that can be used immediately rather than tools carefully crafted to meet rigid requirements. 3. Allow implementers and integrators significant freedom in developing solutions. 4. Expect organizational distinctions to become increasingly blurred 3 SOA Implications Because network centric operations assume an SOA orientation, the implications of SOA need to be understood and addressed. This section elaborates on some of the concepts introduced earlier within the specific context of SOA. Copyright 2006 Carnegie Mellon University 6
  7. 7. 7 3.1 Basic SOA Concepts Services are reusable components that represent mission or business tasks, such as customer lookup, account lookup, or credit card validation. Services can be globally distributed across organizations and reconfigured to support new business tasks. They are reusable in the sense that they can be used by many business processes. They usually provide coarse-grained functionality, such as customer lookup as opposed to finer grained functionality such as customer address lookup. More formally, a service is a coarse-grained, discoverable, and self-contained software entity that interacts with applications and other services through a loosely coupled, synchronous or asynchronous, message-based communication model. SOA is a way of designing systems composed of services that are invoked in a standard way. SOA is an architectural style, but it is not a system architecture, and it is not a complete system. In this architectural style, an SOA-based system is composed of services, applications that use services, and an SOA infrastructure that connects applications to services. This will be further explained in Section 3.2. 3.2 Building Blocks of SOA Systems Common goals for the adoption of SOA are to eliminate redundancy, assemble new functionality from existing services, adapt systems to changing needs, and leverage legacy investments. An SOA approach is an attractive option to expose functionality in legacy systems. By allowing access to the legacy system thorough a standard service interface, the details of connecting to the legacy system are the responsibility of the SOA infrastructure and the service interface and not of the applications. As a result, the legacy platform diversity is transparent to the applications. An SOA-based system consists of 1) services, 2) applications that discover and use services, 3) and an SOA infrastructure that connects applications to services, as shown at a very high level in Figure 1. In this context, the SOA Infrastructure provides a standard communication mechanism between applications and services. Each application invokes the services in the same way. Each service provides an interface that is invoked through a data format and protocol that is understood by all the potential clients of that service. Copyright 2006 Carnegie Mellon University 7
  8. 8. 8 Application Application Application X Y Z Service SOA Infrastructure Internet Internet D Development Security Tools Discovery Service Service Service External A B C System Enterprise Legacy or New Information System Code Internal Users Fig. 1. Components of an SOA-Based System Infrastructure developers focus on providing a stable infrastructure that includes standards, common services and development tools. The infrastructure supports the protocol and data formats of the service's current and potential clients. Tasks for infrastructure developers include: • Selecting standards to implement as part of the infrastructure • Developing a set of common infrastructure services for discovery, communication, security, etc. • Identifying and developing binding mechanisms to satisfy the largest set of potential service users • Providing tools for application and service developers • Documenting and supporting the infrastructure Application developers focus on the discovery, composition and invocation of services, either statically at design time or dynamically at runtime. Key tasks for application developers are: • Understanding the SOA infrastructure • Discovering appropriate services to be incorporated into applications • Retrieving and understanding service description documentation • Invoking identified services in applications, including any data conversions, error handling and availability handling • Testing services for correctness in the context of the application being developed Service providers focus on the description and granularity of services so that applications can easily locate and use them with acceptable Quality of Service (QoS). Tasks include: • Understanding requirements of potential service users • Understanding SOA infrastructure • Developing code that receives the service request, translates it into calls into new or existing systems, and produces a response • Describing and publishing the service • Developing service initialization code and operational procedures With the increasing popularity of software as a service, it is becoming common for each of these components to be developed by different organizations. The tasks and risks associated with the development of each will largely depend on the distribution of the Copyright 2006 Carnegie Mellon University 8
  9. 9. 9 development effort across multiple organizations. If the three types of components are developed within the same organization, the challenges are less. However, if the development is distributed across multiple organizations, decisions made locally by any one of these development groups can have an effect on the other groups. 3. 3 Pillars of SOA-Based Systems Development It is common to view SOA-based systems development as a technical problem with a technical solution. However, successful SOA-based systems development requires attention to four pillars as illustrated in Figure 2. These pillars can be considered to elaborations of several of the implications of network centric operations that were identified earlier – with a specific focus on the needs from an SOA perspective. These are each outlined briefly in the following subsections. SOA-Based Systems Development Governance Technology Evaluation Change of Alignment Strategic Mindset SOA SOA Design Principles Fig. 2 Pillars of SOA-Based Systems Development 3.3.1 Strategic Alignment Any successful SOA strategy has to be aligned with mission and business goals. The high level goals dictate the focus of an SOA implementation. For example, a goal to increase information available to customers will focus on intuitive portals and creation of services related to customer information. A goal of integrating new partners will focus on a flexible SOA infrastructure, a strong service repository, and clear guidelines for composition. A goal of maximizing security may lead to a proprietary SOA infrastructure. Services are identified through a top down analysis of business processes, a bottom-up legacy system inventory, or a combination of the two. High priority services are selected based on their relationship to critical business goals. SOA implementation starts with pilot projects that provide high impact and visibility with the lowest risk. Successful pilot projects will potentially lead to projects that integrate a Copyright 2006 Carnegie Mellon University 9
  10. 10. 10 single business unit, to projects that integrate multiple business units, to potentially a virtual enterprise where all applications are built based on services [9]. 3.3.2 SOA Governance Governance has been addressed earlier within the overall context of network centric operations. Within the specific context of SOA, governance has been rated as the main inhibitor of SOA adoption [10]. A well-defined governance model is essential for SOA success and needs to answer such questions as: • What is the process for determining what services to create? • What is the process for evolving, and changing services if there are many consumers of the service? • Many business services are common across several lines of business in an enterprise. Who "owns" these common services? • Who owns the actual data if more than one service is using it? • What is the resolution mechanism if there are conflicting requirements or change requests for shared services? • What happens if the same (or similar) service is being developed by more than one service provider? • What mechanisms, tools and policies are used for maintaining and monitoring deployed services? • How are enterprise-wide policies enforced across various services both internal as well as external to the organization? • Who owns and maintains the shared repository of services in an organization? • How are service level agreements (SLA) defined and enforced between service consumers and providers? 3.3.3 Technology Evaluation Because an SOA implementation may use a number of technologies in novel contexts, it is important to evaluate whether a specific set of technologies is appropriate for the task at hand. All technologies work well within a specific context and under certain conditions. For example, Web services work well for asynchronous communication over the Internet. In a business environment these conditions are very common. However, this may not be the case in a military tactical command and control environment where high performance and availability requirements prevail. A formal evaluation process that can allow organizations to experiment with technologies before they are inserted into organizations is necessary. This process must consider the context in which the technology will be used in order to make the right decisions. Lewis outlines an approach for context based technology assessments that can be appropriate for SOA technology evaluations [Lewis, 2005]. This process evaluates technologies within the context that they will be used. It includes hands-on experimentation with the technology for a greater understanding of its implications, as well as early competence development of the people conducting the experiments. An Copyright 2006 Carnegie Mellon University 10
  11. 11. 11 integral part of this process is the use of TechChecks (formerly known as model problems) to verify claims about different technologies and approaches. The approach involves (1) formulating hypotheses about the technology, and (2) examining these hypotheses against very specific criteria through experimentation. In this way the hypotheses are either sustained or refuted. The TechCheck approach has the advantage of producing very efficient and representative experiments that not only evaluate technologies within the context of their future use, but also generate hands-on competence with the technologies. 3.3.4 Awareness of a Different Mindset There are a unique set of challenges in building SOA-based systems. These challenges require a different development approach that deals with the characteristics of SOA- based systems. Although it is difficult to generalize, some of the contrasts of SOA systems versus traditional systems are presented in Table 1. Table 1. Differences between Traditional Systems Development and SOA-Based Systems Development. Traditional Systems SOA-Based Systems Development Development Tight coupling between system Loose coupling between components applications and services Shared semantics at design time In the future, semantics ideally enable dynamic discovery and execution of services Known set of users and usage Potentially unknown patterns service users and usage patterns System components all within Multiple organizations the same organization providing and supporting system components These differences impact the way software is developed throughout the life cycle. For example: • During requirements, it is important to have close ties to business process modeling and analysis. In addition there is the need to anticipate potential requirements from unknown users • During architecture and design, it is important to have technology evaluations and to perform explicit tradeoff analyses • Implementation decisions will be impacted by emerging standards and may require simulation of the deployment environment • Testing requires a strong emphasis on exception handling, and requires all users to be online Copyright 2006 Carnegie Mellon University 11
  12. 12. 12 • Maintenance requires more sophisticated impact analyses and greater coordination of release cycles 4. Conclusion The common theme throughout this white paper is that the migration to network centric operations presents a set of acquisition and engineering challenges. We have outlined a preliminary set of these challenges and the types of issues that need to be addressed. We have also taken the specific case of an SOA environment and drilled down to the specific issues that such an environment presents. References: Cherinka, R., Miller, R., and Smith, C. Beyond Web Services: Toward On-Demand, Complex, Adaptive Environments. The Mitre Corporation, 2005. work/tech_papers/tech_papers_05/05_0683/05_0683.pdf W.K. Fithen “On the Security of the Cyber Battlefield”, Software Engineering Institute. 2006 Gabbard, May & Thieret. Air Force Cyberspace Command: Recruit, Organize, Train, and Retain. Software Engineering Institute, 2006. Lewis, G. and Wrage, L. “A Process for Context-Based Technology Evaluation”, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005. Maier, Mark. Architecting Principles for Systems-of-Systems. 1996. Morris, E. and Place, P. Air Force Cyberspace Command: Engineering for Cyber Operations, Software Engineering Institute, forthcoming. Northrop L, et al, Ultra-Large-Scale Systems: The Software Challenge of the Future. Software Engineering Institute, 2006. White, B. E. A Complementary Approach to Enterprise Systm Engineering, NDIA Systems Engineering Conference, October, 2005. wednesday/white.pdf Copyright 2006 Carnegie Mellon University 12