federal enterprise architecture (fea) and network services · white paper © 2009 cisco systems,...

.

White Paper

© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. of 12

Federal Enterprise Architecture (FEA) and Network Services

Enterprise architectures, the IT frameworks that govern the alignment between business and technology

architectures, come in a range of styles. For example, the pioneering “Zachman framework” emphasizes

the classification and proper assignment of artifacts. TOGAF, a widely used architecture developed by the

Open Group, lays out a process for moving from generic values to industry-specific and then

organization-specific structures through a repeatable cycle of steps. Enterprise architectures vary widely

on the basis of differing views of the relationship between the business and its IT resources, differing

problems the organization must solve, and differing historical and technological factors. The architectural

methodology that an organization creates, adopts, or tailors reveals a great deal about that organization’s

underlying values. Often the gaps between an architectural vision and its specific technological enablers

are wide, but they commonly can be bridged by examining the values captured in the architecture and

looking at how technologies support them.

This paper performs that exercise on the sprawling, ambitious Federal Enterprise Architecture (FEA) and some of the

technologies that can be used to realize its goals. Specifically, it focuses on the significant but underrecognized role

of network-based services. Network services are assuming a variety of processing-intensive functions that can

hamper and complicate architected applications. Just as importantly, network services offer unique capabilities that

can enrich innovative composite applications. Architects who work with FEA will be interested to see how well

network services are matched to FEA’s needs, approaches, and values. This paper gives a brief overview of FEA

contents, a distillation of FEA’s underlying values and goals, and a survey of some of the relevant services provided

by Cisco.

FEA Overview

When asked what enterprise architecture is, a FEA practitioner can give an authorized answer: “a strategic

information asset base which defines the mission, the information necessary to perform the mission, and the

technologies necessary to perform the mission.” This is the definition used by the federal government of the United

States, which is FEA’s principal instigator, implementer, and proponent.

FEA emerged in response to a piece of legislation, the Clinger-Cohen Act of 1994 (officially the Information

Technology Management Reform Act), which instructed federal agencies to develop a master plan for integrating new

technologies, managing IT acquisitions, and measuring and reporting on performance. The first version of FEA (it

was then called FEAF, with the word Framework at the end) was released in 1999. It has been undergoing

modification and expansion ever since. Most of the major pieces have become available only in recent years.

Given the diversity of concerns that federal agencies deal with and the many levels of scale at which the federal

government works, FEA is large, complex, and multilayered. It is actually more a collection of management principles

expressed in IT terms than it is a taxonomy or a formal methodology, though it contains some of both. As Roger

Sessions writes in his book Simple Architectures for Complex Enterprises, “FEA can be viewed as either a

methodology for creating an enterprise architecture or the result of applying that process to a particular enterprise—

namely the U.S. Government. . . . It includes everything necessary to build an enterprise architecture for probably the

most complex organization on earth.” The principles and methodologies that FEA contains are applicable beyond the

federal government, since the problems FEA addresses are common to large, diverse, hierarchic organizations of all

kinds.

White Paper


FEA Highlights

To call FEA “multidimensional” is a massive understatement. It attempts to map a complex organization-that-is

against an equally complex organization-to-be and lay out a path between them. It attempts to impose certain

commonalities on a 200-year-old enterprise composed of hundreds of semi-autonomous organizations handling

dozens of distinct interest areas, each operating at multiple levels of governance. It is no surprise that FEA diagrams

(see Figure 1, for example) are packed with pyramids, arrows, stripes, boxes, and dotted lines. Or that FEA

documentation fills many volumes.

Figure 1. The FEA overview diagram

It is beyond our scope to give even an introduction to FEA’s many aspects. But a sense of its scope and values can

be gained from a summary of FEA’s five reference models, its measurement concerns, and its division of the

enterprise into a structure of architectural levels.

Reference Models

The FEA-Program Management Office advises that the “framework for describing important elements of the FEA in a

common and consistent way” lies in FEA’s five reference models, one each for Performance, Business, Components,

Technology, and Data (Figure 2).

White Paper


Figure 2. The Reference Model stack

Together, this “set of interrelated ‘reference models’ is designed to facilitate cross-agency analysis and the

identification of duplicative investments, gaps, and opportunities for collaboration within and across agencies“ (FEA

Consolidated Reference Manual). At the most fundamental level, the reference models establish a common

vocabulary in order to promote communication and cooperation. Specifically:

● The Performance Reference Model (PRM) provides standard ways of measuring performance and

determining which IT investments lead to the best outcomes. The goal is improved resource allocation and the

identification of “performance improvement opportunities that span traditional organizational structures and

boundaries.”

● The Business Reference Model (BRM) organizes government operations in terms of function (“Disaster

Management”) and mode of delivery (“Transfers to States and Local Governments”) rather than by agency or

administrative department. It is a counterforce to the long-established “stovepipe” organization of the

government.

● The Service Component Reference Model (SRM) is a horizontal, IT-level view that provides a common

foundation for reusing applications, application capabilities, components, and business services. The highest

level here are service domains such as “Customer Services,” “Process Automation,” and “Back Office

Services” that are entirely independent of specific business functions.

● The Technical Reference Model (TRM) is a super-framework (there are numerous agency-level technical

models) for categorizing in a uniform way the standards and technologies used by the government, with an

eye toward encouraging reuse, interoperability, and economies of scale. A typical category here is “Service

Requirements,” which includes Legislative/Compliance, Authentication/Single Sign-on, and Hosting.

● The Data Reference Model (DRM) is a standardized way to describe, categorize, and share data. As can be

imagined from the diverse agency domains covered, “the standard description and discovery of common data

and the promotion of uniform data management practices” is by far the largest of the Reference Models.

Measurement

True to the evaluation and reporting directives in the original act of Congress, FEA devotes much attention to

measuring organizational success. Each agency implementing a FEA-compliant architecture is instructed to

“measure the value of enterprise architecture products and services” to achieving mission objectives. Detailed lists of

White Paper


stakeholders, value indicators (“total cost savings/avoidance as a percentage of the total IT budget,” “number of

architectures integrated with cross-agency initiatives,” and so on), sample questionnaires, and a recommended

survey methodology are provided. Agencies are rated on their “maturity levels” in the areas of architectural

completion, architectural use, and architectural results. Each category contains multiple well-defined “grades” that tell

the agency (and any organization that wants to use this framework) how well it is doing at developing, adopting, and

realizing the benefits of a FEA-like architecture.

Architecture at various levels

Other high-level FEA features include a well-defined process for any government department or agency to create a

FEA-compliant “segment architecture” that, while specific to a particular domain, is aligned with the strategies,

mandates, and standards specified at a higher, more abstract level and is able to take advantage of the common

technology layer that FEA establishes down at the other end of the stack. Reflected here is FEA’s perspective on

three useful architectural levels within a large organization: enterprise architecture, segment architecture, and

solution architecture. They work at different levels of detail, and though the concerns they address are related and

aligned, each has a distinct “territory.”

● Enterprise architecture deals with strategic, organizationwide concerns and shared assets such as strategies,

business processes, and technologies.

● Segment architecture deals with the issues around a specific mission area or business service. Its aim is to

“improve the delivery of services to citizens and agency staff.” Segment architecture extends the FEA

framework to suit the specialized needs of its business area. The data or service interfaces defined by the

segment architecture for its mission area will, in turn, be used by the solution architecture for individual

projects.

● Solution architecture, the purview of system users and developers, specifies an agency’s IT assets for a single

project. It puts the interfaces defined at the segment level into real-world use, and it always reflects the

technologies and standards specified at the enterprise level.

FEA Values

Even from this brief tour of FEA highlights, it is possible to perceive some of the issues FEA is grappling with and the

approaches it has chosen to take. Among its central concerns seem to be:

● Unifying diverse constituent agencies

● Keeping multiple levels aligned

● Handling complex relationships with diverse constituents

● Using measurement and reporting to increase accountability

It is worth taking a closer look at each.

Unifying diverse agencies

Encouraging collaboration, cooperation, and communication among departments is a challenge for any organization,

but the federal government encompasses a daunting range of domains: border security, arts funding, water

management, education standards, foreign aid, health care for veterans, weapons procurement, scientific research,

nutritional advice. These tasks are managed through hundreds of different suborganizations, many of which have

little to nothing in common. Even the most diversified holding company in the private sector does not deal with such

dissimilar concerns.

In addition, many federal agencies are over a hundred years old and have well-entrenched traditions and cultures.

Each has one or several IT organizations that predate FEA and already represent a sizable investment. They depend

on a largely civil-service work force that is famously (though perhaps unfairly) considered innovation-averse.

White Paper


Clearly, even as FEA promotes the development of mission-supporting architectures within suborganizations, it is

also working to arrive at a transcendent architecture that crosses agency boundaries. The initial work on a federal

enterprise architecture was done by a CIO Council representing all major federal departments; their goal was to

prevent agencies from “buying and building systems that are duplicative, incompatible, and unnecessarily costly to

maintain and integrate.”

Thus the five Reference Models can be seen as attempts to arrive at a core set of terms, strategies, and technologies

at levels both higher (more abstract) than and lower (more technical) than the particular business domain concerns

that separate agencies from one another. To use an analogy, if the builders of all kinds of different buildings can be

prevailed upon to keep an overall city vision in mind and also to use the same kinds of beams and concrete, then

even office towers and bungalows will have something in common and certain kinds of shared efforts will be possible.

Keeping multiple levels aligned

Each of the hundreds of different agencies in the government is segmented horizontally. Often the organization is

divided into large geographic regions, then states within those regions, counties within those states, down to

neighborhood offices. Obviously, the enterprise architecture for such a hierarchic organization would itself be

organized hierarchically. Thus FEA emphasizes a methodology for creating “segment” architectures that can be

repeated at multiple levels of specificity while remaining internally consistent. The Segment Architectures should refer

“upward” to common, shared assets (FEA’s “Enterprise” level embodies both “business values” such as service to

citizens and respect for due process, and the “technical values” of preferred strategies, business processes, and

technologies) and “downward” by providing data and interface definitions to the lower-level solution architecture level.

Handling complex relationships with diverse constituents

The federal government employs, interacts with, and stores information about millions of individuals and

organizations. It interacts with foreign governments and participates in multinational ventures. Like all organizations, it

maintains many kinds of relationships, often multiple kinds with the same entity, and must keep track of identities,

affiliations, and roles. User identification issues are unusually critical for the government because the security issues

are more sensitive. The government must observe a balance between access and protection, maintaining many fine

gradations of security without undue secrecy. This is a balance that enterprise architecture plays a part in

implementing.

While one of the stated goals of FEA is to “improve delivery of services to citizens,” the relationship is more

complicated than that. Citizens are not only the customers of government agencies but also their funders and

overseers. Communication between citizens and the government has always been a two-way street, and in the age

of the Internet and social networking it is increasingly so. Citizens provide input (letters, petitions, tax returns, grant

proposals, census data, geophysical survey information, epidemiological data, and so on). Citizens also access

information. Ideally, citizens are the government, and it is the job of IT and the architecture underlying it to help bring

this ideal closer.

Using measurement to increase accountability

Accountability is a FEA cornerstone. It is no coincidence that the agency responsible for FEA is the Office of

Management and Budget, one of the most ”quantitative” parts of the government.

The legislation that created a federal enterprise architecture initiative spoke specifically about achieving quantifiable

improvements in agency performance. It directed agency heads to “establish measurable criteria” that would be used

to evaluate IT initiatives. One of the five FEA Reference Models, the PRM, is designed to “clearly articulate the

cause-and-effect relationship between inputs, outputs, and outcomes.” It calls for measurements in the areas of

customer benefit, service coverage, timeliness and responsiveness, service quality, and service accessibility. There

are specific instructions for measuring technology effectiveness in the categories of

White Paper


● Technology costs

● Quality assurance

● Efficiency, measured in terms of response time, interoperability, user accessibility, and improvement in

technical capabilities or characteristics

● Information and data, of which “standardization” is a key element

● Reliability and availability

● Effectiveness

The FEA Practice Guidance manual includes an extensive section on “Measuring EA Program Value,” with both

subjective and objective criteria for determining success. EA is designed to include extensive feedback and

continuous-improvement mechanisms, and one agenda of the Federal Enterprise Architecture is to bring the same

sort of accountability to the agencies that use it.

Performance measurement is one of the few ways of making meaningful comparisons among agencies that deal in

fundamentally incomparable products and services. There are few ways to compare the National Park Service’s

effectiveness at controlling fires against the Department of Health and Human Services’ effectiveness at providing

school lunches. Performance metrics provide a leveler, a common denominator that makes it possible to see how an

agency stacks up against other agencies and against its own past performance.

Network Services for FEA Architects

Having introduced some FEA concepts and extrapolated some of FEA’s underlying goals and values, let us approach

the most implementation-oriented part of FEA, the Technical Reference Model. Architects working with this model

have the job of finding technical solutions, using hardware, software, patterns, and services, to build systems and

applications that accomplish specific tasks in the context of FEA directives. They make the design decisions that put

FEA guidelines and methodologies to work for their agencies. FEA’s high-level goals become concrete here.

Cisco, a long-time leader in networking technologies, foresees a larger role for services that reside in the network.

FEA solution architectures, like all enterprise architectures, already rely on computer networks for transport, traffic

routing, and other low-level ”plumbing.” Increasingly, they can rely on the network layer for higher-level services as

well, many of which improve upon traditional application services. FEA architects need to become familiar with the

capabilities of the increasingly intelligent network and understanding how these services support the Technical

Reference Model.

White Paper


Figure 3. Technical Reference Model components with network-service areas indicated

Figure 3 illustrates the expansion of network services. In this FEA chart of TRM concerns at various levels, those

areas in which network services have traditionally been employed are enclosed within a rectangular box; those areas

where today’s application-aware network services can be employed are indicated with a large red bullet. Network

services have dramatically expanded their scope, and can be of much wider use to the FEA practitioner than in the

past.

The following section highlights those features of the Cisco® “application-aware” network that most enable TRM

requirements, and then broadens the discussion to show how these sorts of services promote FEA’s larger and more

abstract goals. The services are discussed from the viewpoint of an enterprise architect rather than a network

architect, since the goal is the network’s contribution to the overall enterprise framework.

Transport Services

Moving traffic around is the network’s most basic job. Cisco’s Transport Services include the many functions involved

in delivering content in a variety of traffic formats with predictable speed and quality. Included here are “primitive”

services that Cisco continually optimizes to provide a strong foundation for all higher-level services and also expands

to include more specialized, advanced capabilities.

The Transport Services category delivers:

Quality of Service (QoS)

QoS services reserve network resources so that they will be available when needed to deliver consistent

performance for appropriately configured applications, services, and other bandwidth-dependent needs.

Enterprise architects, increasingly challenged to support service-level guarantees for their end-to-end

White Paper


deliverables, may be surprised to learn that there are more performance-tuning capabilities in the network

than in any other layer of the technology stack.

Network heuristics

Heuristics services let the network learn a great deal about the data flowing through it. They look beyond the

packet header into the payload itself. This information can be enormously valuable when networks are used

by diverse parties for diverse uses, as government networks certainly are. It can be used for threat detection,

performance and routing optimization, and statistical analysis of the data.

Alternative delivery modes

Transport Services support applications with a range of delivery modes, especially multicasting. Networks can

now support more than two-way conversations. Multicasting allows message traffic to be sent simultaneously

to whole groups of pre-specified receivers.

Transport services make it possible for networks to support the complex needs of emerging applications, reliably

ensuring the required service levels as well as fundamental reliability and survivability considerations.

Application Delivery Services

Cisco’s network-based Application Delivery network services can improve the performance not just of applications in

the planning stages, but of those already running. The network can assume tasks that are currently burdening the

application server layers, freeing up capacity, improving overall application performance as well as improving

scalability and manageability. These include:

XML services

XML is the lingua franca of today’s application and server-oriented message interchange. It can be shaped to

carry virtually any kind of message and do so with carefully architected syntax. The network layer provides

rich XML-related services: XML validation, for checking the correctness of the XML message by measuring it

against an XML schema; XML translation, for translating among formats using standard XSLT transformation;

plus various authentication and authorization filters for checking the security levels of a incoming XML

messages. It makes sense to offload these tasks from busy network servers to the network, which is easier to

control, monitor, and optimize for highly repeatable functions.

Message translation

Cisco’s suite of Application Delivery services can perform many other kinds of data-format conversions on a

variety of standard data formats and, with custom adaptations, on even nonstandard formats. This could be

immensely useful for data transformations between different government agencies. Because the data would

be converted inside the communication pipe, the endpoint applications could continue to operate unchanged

and be shielded from the data inconsistencies.

Compression

Resources can be compressed or expanded as they travel through the network. Industry-standard

compression algorithms can be provisioned into specific communication streams.

Caching

Critical resources can be cached in the network without having to change the client and server partners at the

endpoints. This can mean dramatic performance improvements that reduce the painful delays that occur

between far-flung endpoints.

Content distribution and routing

White Paper


Routing optimizations in the network can take content in many forms of content and get it from one point to

another in as few stops as possible. The network can preposition really busy content (for example frequently

used multimedia content) nearer to the consumers that need these resources frequently.

Application Delivery services take the distributed-network goals of the preceding Transport category and supercharge

them with a variety of tune-ups and optimizations. These tune-ups effectively make a coast-to-coast interaction

behave more like a intra-campus interaction. To the extent that FEA prescribes a snappier, less sluggish user

experience for both government employees and citizens, Application Delivery services in the network are an

important enabler. In addition, network data conversion capabilities permit interconnectivity and collaboration among

agencies whose legacy systems may not be compatible.

Real-Time Communications

Enterprise architects tend to use the term “real-time” communications to refer to any network-based communication

that isn’t delayed by queuing or staged processing. Cisco’s Real-Time Communications services permit an ad hoc

group-of-purpose to define itself and almost instantly establish a virtual network for instant messaging, voice/video

conferencing, crowd-sourced events, and more to come. Aspects of these services are:

Session tools

Using the highly dynamic Session Initiation Protocol (SIP), a community can define a virtual network of

unanticipated scope that rides on top of the existing IP network. The virtual session created can have end-to-

end performance metrics just like the underlying static network. Furthermore, session information such as

participant identities, duration, routine information, and resource and media usage can be captured for

accounting or auditing purposes.

Multimedia capabilities

Real-Time Communications can enhance multimedia traffic on dynamic networks by aggregating increasingly

media-rich data streams, managing their distribution, and even performing media conversion on them. Status

information on the state of the stream and control of record and playback is available instantly.

Presence

Organizations within government and beyond are interested in simultaneously extending their application

reach to distant (even global) collaborators while reducing the time and travel expenses involved in

collaborating in person. Presence Services are the network’s contribution to increasing the efficacy of virtual

presence in place of physical presence, ensuring that collaborators can define their preferred method of being

reached based on any number of contextual considerations.

Real-time communications form the network basis for quickly setting up temporary networks linking unanticipated

parties. Emergency response and military maneuvers are obvious examples, but increasingly these sorts of networks

can be used for interagency planning exercises, citizen forums, nationwide “town halls,” constituent-representative

interactions, and more.

Virtualization

Virtualization is transforming all layers of distributed systems: servers, clients, and the networks that connect them. In

the network, virtualization enables the creation of multiple virtual networks on the same physical network. These

networks can be separately provisioned and can offer highly secure partitions between multiple tenants sharing data,

processor, and transport resources.

Virtual everything: VPN, VLAN, VSAN

Segmentation of private networks (VPN), LAN services (VLAN), and storage (VSAN) gives the enterprise

architect a new set of options for optimizing network resources. Managing these networks is relatively simple

White Paper


because it considers only the community being serviced by the particular virtual instance. The actual

resources are secure because the virtual machines keep all aspects of one virtual machine’s existence

private, invisible to any neighboring virtual machine. Yet the ability to use a common physical pool means

many more options for sharing resources.

I/O virtualization

A particularly elegant feature of virtualized environments is the elimination of the requirement for redundant

physical host adapters, cables, and ports. Because the addresses of these devices can be virtualized as well,

the environment no longer needs to bind the server to specific pieces of hardware.

Virtualization advances an important FEA goal: avoiding duplication of resources. A single physical network can now

run multiple virtual networks, each separately purposed, in secure isolation from one another. This creates truly

radical opportunities for simplifying complex configurations and dealing with the diverse constituencies that make up

FEA’s audience.

Security

Security architectures have become stronger in the past few decades as threats to computers and networks have

increased. Cisco has developed important network-based services to help in the job of protecting infrastructure, data,

and application layers from constantly evolving threats. The network is now a source for many of the standard

security protections (authentication, authorization, and accounting) and adds additional capabilities specifically for

large, distributed systems. These include:

Policy-driven security enforcement in the network

As architectures become more secure they can become overly rigid. To counterbalance this rigidity, the

security constraints need to be malleable and conditioned by customized policy statements. The security

network services provide a built-in policy engine to combine the crucial security factors (identity, role, location)

to arrive at an intelligent and flexible determination of access and authorization rights toward application, data,

or function.

Multiple threat protections from spam, viruses, or intruders

Most security threats propagate through the network, and the network is the place where these threats should

be intercepted. Security-tasked software agents in the network are well positioned with usage profiles and

other network data to detect security threats.

Endpoint posture validation

Even an anticipated threat can be harmful if the protection against it has not been installed. Endpoint posture

validation services can ensure that a particular device has the required hotfix and is running key antivirus or

other security software.

Every architect faces tough challenges balancing security against shareability. The FEA architect, in particular, has to

respond to critical security concerns on the one hand and political pressures for government transparency on the

other. Effective systems need the power and subtlety of network-based security services to continually fine-tune the

balance between locking down and opening up, as time, place, and identity require. The goal, implicit throughout

FEA, is to make sure that each government employee and each citizen gets the information he or she is entitled to in

the form that suits him or her best.

Mobility

When networks started, in the telephone era, endpoints were static and humans the only type of user. Computer

networks added intelligent devices as another type of communicating party. Then the communicating devices

became light and wireless, meaning that the shape of the network itself became vaporous and assumed the shape

White Paper


that its consumers required. These days, the once-evident facts of who-am-I and where-am-I are pieces of data that

have to be provided for meaningful conversations to take place. The network layer offers:

Location services

Location services tell the network where an endpoint is. This information can be inferred from GPS sensors or

other network cues.

Device identity

Device identity services use sensors to read the identity of tag-carrying inanimate (possibly animate) objects.

They can also supply other necessary data and services depending on their type.

Mobility services are central to the FEA goal of managing complex relationships with diverse constituents. As these

relationships are increasingly maintained through continually morphing, continually on-the-move networks, identity

and location services provide critical application support. They also support the reach across multiple organizational

layers. As the architect can be more comfortable with endpoints on the move, whole new classes of applications

emerge. Some recent food-safety applications that the Department of Agriculture is evaluating have used these

services to track agricultural products as they move through the supply chain. Mobility services also enable a more

mobile government work force, more flexible and more responsive to citizen concerns.

Management Services

Network management services offer configuration and reporting capabilities along with tools for configuring and

maintaining network resources. In particular, Cisco’s early commitment to standards for “self-healing” infrastructure

has fostered a proactive approach to high availability. Enterprise architects who have been seeking robust, nonstop

application software can build upon a network services layer that has anticipated this trend.

Tools to configure and manage network resources

These services provide exceptional depth in the ability to configure, provision, and manage a highly disparate

network. In addition to user tools, external XML-based services are available to enable network management

services collaborate with other automated partners.

Automatic asset management

The network can probe nodes to discover the presence of particular devices, so that real-time inventories can

be performed.

Performance monitoring

The performance of virtually any aspect of the network can be detected and analyzed. This can ensure long-

term ability to satisfy customer quality of experience expectations.

FEA devotes an entire Reference Model, the PRM, to the importance of performance-monitoring to align outcomes

across diverse agencies. Metrics are a key FEA implementation tool, and networks provide a set of measurement

capabilities that have previously been achievable only at great expense. This should be one of a FEA architect’s

major resources for achieving better accountability.

Summary

It is hard to underestimate the value of network services to an enterprise architect. It is not simply a matter of

improved performance and expanded scope: Many capabilities that were previously achievable only at prohibitive

cost come into range.

As with many innovative movements, understanding network services and how to use them to best advantage

requires a shift in the architect’s thinking. Cisco offers an extensive library of explanatory white papers and technical

references, along with a variety of consulting and professional services offerings. Cisco has long been a trusted

White Paper


advisor on network-architecture issues, and now it can be an important resource for application-level and enterprise-

level architecture as well.

The FEA mandate for collaboration within the government and improved interaction with its citizen-customers is a

wide-ranging one and needs to be implemented at many levels through many technologies. Network services have

an important role to play in helping deliver a government IT architecture that promotes collaboration, flexible security,

iron-clad dependability, and a better user experience for users both in and outside of government.

Further Resources:

Cisco Enterprise Architecture website: http://www.cisco.com/en/US/netsol/ns858/index.html

Cisco Services Business Transformation Solutions website:

http://www.cisco.com/en/US/products/ps8222/serv_group_home.html

Main FEA website: http://www.whitehouse.gov/omb/e-gov/fea/

Printed in USA C11-542359-00 06/09

http://www.cisco.com/en/US/netsol/ns858/index.html�

http://www.cisco.com/en/US/products/ps8222/serv_group_home.html�

http://www.whitehouse.gov/omb/e-gov/fea/�

federal enterprise architecture (fea) and network services · white paper © 2009 cisco systems,...

Documents