Establishing a Network Centric Capability: Implications
for Acquisition and Engineering
DYNAMIC SYSTEMS, SOFTWARE ENGINEERING INSTITUTE
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
• Identify Engineering Implications of Network Centric Missions
Copyright 2006 Carnegie Mellon University 1
• 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
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
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
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
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.
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.
MOSAIC information will soon be available on the SEI Web Site.
More information about PAN may be found at http://www.brl.com/toolsets/pan.html
Copyright 2006 Carnegie Mellon University 3
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
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
• 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
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
c. establish communications mechanisms that keep others informed of
2.6 Establish a Network Centric Integration Environment
Copyright 2006 Carnegie Mellon University 4
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
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.
The SEI has seen examples of several programs of this nature
Copyright 2006 Carnegie Mellon University 5
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
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
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
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
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
Application Application Application
X Y Z
SOA Infrastructure Internet
Security Tools Discovery
Service Service Service External
A B C System
Enterprise Legacy or New
Information System Code
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
• 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
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
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 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
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
single business unit, to projects that integrate multiple business units, to potentially a
virtual enterprise where all applications are built based on services .
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 . 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
• 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
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
Traditional Systems SOA-Based Systems
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
Known set of users and usage Potentially unknown
patterns service users and usage
System components all within Multiple organizations
the same organization providing and supporting
These differences impact the way software is developed throughout the life cycle. For
• 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
• 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
Copyright 2006 Carnegie Mellon University 11
• Maintenance requires more sophisticated impact analyses and greater coordination
of release cycles
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.
Cherinka, R., Miller, R., and Smith, C. Beyond Web Services: Toward On-Demand,
Complex, Adaptive Environments. The Mitre Corporation, 2005. http://www.mitre.org/
W.K. Fithen “On the Security of the Cyber Battlefield”, Software Engineering Institute.
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.
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. http://www.dtic.mil/ndia/2005systems/
Copyright 2006 Carnegie Mellon University 12