.
White Paper
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.
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 1 of 12
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).
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 2 of 12
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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 3 of 12
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.
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 4 of 12
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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 5 of 12
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.
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 6 of 12
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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 7 of 12
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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 8 of 12
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-toend 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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 9 of 12
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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 10 of 12
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 longterm 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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 11 of 12
White Paper
advisor on network-architecture issues, and now it can be an important resource for application-level and enterpriselevel 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
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
C11-542359-00
06/09
Page 12 of 12