![](media/image1.png){width="8.95486111111111in"
height="10.602083333333333in"}

[1 Executive Summary 4](#executive-summary)

[2 Modernization Principles 6](#modernization-principles)

[2.1 Service Orientation 6](#service-orientation)

[2.1.1 Service Oriented Architecture 6](#service-oriented-architecture)

[2.1.1.1 Service Frameworks 7](#service-frameworks)

[2.1.2 Service Oriented Infrastructure
7](#service-oriented-infrastructure)

[2.1.2.1 Enterprise Service Bus 8](#enterprise-service-bus)

[2.1.2.2 Scale Invariance 9](#scale-invariance)

[2.1.2.2.1 Server Consolidation and Virtualization
9](#server-consolidation-and-virtualization)

[2.1.3 Social Computing 10](#social-computing)

[2.1.3.1 From Communication Platform to Collaboration Medium
10](#from-communication-platform-to-collaboration-medium)

[2.1.3.2 Blogs and Wikis 10](#blogs-and-wikis)

[2.1.3.3 User Tagging 10](#user-tagging)

[2.1.3.4 Rich Interactive Experiences 11](#rich-interactive-experiences)

[2.1.3.5 The Programmable Web 11](#the-programmable-web)

[2.1.3.6 Personnel Productivity 11](#personnel-productivity)

[2.1.3.7 Horizontal Teams 11](#horizontal-teams)

[2.1.4 Enterprise Computing 12](#enterprise-computing)

[2.1.4.1 Quality of Service 12](#quality-of-service)

[2.1.4.2 Privacy, Trust, and Non-Repudiation
13](#privacy-trust-and-non-repudiation)

[2.1.4.3 COOP and Disaster Recovery 13](#coop-and-disaster-recovery)

[2.1.4.3.1 Replication 13](#replication)

[2.1.4.3.2 Mesh Networking 14](#mesh-networking)

[2.1.4.3.3 Syndication 14](#syndication)

[2.1.4.3.4 September 11^th^ and Katrina 14](#september-11th-and-katrina)

[2.2 Enterprise Architecture 14](#enterprise-architecture)

[2.2.1 Model Driven Architecture 15](#model-driven-architecture)

[2.2.2 Business Process Management 15](#business-process-management)

[2.2.3 Application and Data Agnostic 16](#application-and-data-agnostic)

[2.2.3.1 Pervasive Computing 17](#pervasive-computing)

[2.2.3.1.1 Client Services 17](#client-services)

[2.2.4 Design Locally, Deploy Globally
20](#design-locally-deploy-globally)

[2.2.5 Executable Architecture 21](#executable-architecture)

[2.2.6 BA/RA/SA/RI 22](#barasari)

[2.2.6.1 Business Architecture 22](#business-architecture)

[2.2.6.1.1 Collaborative Role Interactions
22](#collaborative-role-interactions)

[2.2.6.1.2 Systems of Systems 23](#systems-of-systems)

[2.2.6.1.3 Organizational Design and Human Capital
23](#organizational-design-and-human-capital)

[2.2.6.1.4 Investment Endpoints 23](#investment-endpoints)

[2.2.6.1.5 Information Exchange 23](#information-exchange)

[2.2.6.1.6 FEA Integration and 'Line of Sight'
24](#fea-integration-and-line-of-sight)

[2.2.6.1.7 Navigability 24](#navigability)

[2.2.6.1.8 SME Validation 24](#sme-validation)

[2.2.6.1.9 Portfolio Management as Resource Rationalization
25](#portfolio-management-as-resource-rationalization)

[2.2.6.2 Reference Architecture 25](#reference-architecture)

[2.2.6.2.1 Patterns and Blueprints 25](#patterns-and-blueprints)

[2.2.6.2.2 Infrastructure and Mission Enabling Services
26](#infrastructure-and-mission-enabling-services)

[2.2.6.2.3 Generalization/Specialization Framework
27](#generalizationspecialization-framework)

[2.2.6.3 Solution Architecture 27](#solution-architecture)

[2.2.6.3.1 COTS Map/Gap 28](#cots-mapgap)

[2.2.6.3.2 Infrastructure Services 28](#infrastructure-services)

[2.2.6.3.3 Certification & Accreditation (C&A) Boundary
29](#certification-accreditation-ca-boundary)

[2.2.6.4 Reference Implementations 29](#reference-implementations)

[2.2.6.4.1 System Verification 29](#system-verification)

[2.3 Business Activity Monitoring 30](#business-activity-monitoring)

[2.3.1 Business Intelligence 30](#business-intelligence)

[2.3.2 Activity Based Costing 30](#activity-based-costing)

[2.3.3 Regulatory Compliance 31](#regulatory-compliance)

[2.4 Disruptive Technologies 31](#disruptive-technologies)

[2.4.1 Open Source 31](#open-source)

[2.4.2 Semantic Web 33](#semantic-web)

[3 Business Opportunities 33](#business-opportunities)

[3.1 FAB, FAM, and Mediation Services
34](#fab-fam-and-mediation-services)

[3.1.1 Mediation Services 34](#mediation-services)

[3.1.1.1 Recommenders and Ratings 34](#recommenders-and-ratings)

[3.1.1.2 Stateful Process Services 35](#stateful-process-services)

[3.1.1.3 Semantic Mediation Services 35](#semantic-mediation-services)

[3.1.1.4 Autonomic Configuration Services
35](#autonomic-configuration-services)

[3.2 Federal Lines of Business and eGov Initiatives
35](#federal-lines-of-business-and-egov-initiatives)

[3.2.1 Financial Management 36](#financial-management)

[3.3 Model Based Acquisition 37](#model-based-acquisition)

[3.4 Dynamic Supply Chain Assembly and Optimization
37](#dynamic-supply-chain-assembly-and-optimization)

[3.5 Open Source eGov Reference Architecture
37](#open-source-egov-reference-architecture)

[4 People and Process 39](#people-and-process)

[4.1 Reportable Conditions, Material Weakness, and Management Challenges
39](#reportable-conditions-material-weakness-and-management-challenges)

[4.1.1 Reportable Conditions: 39](#reportable-conditions)

[4.1.1.1 System Non-Conformance: 41](#system-non-conformance)

[4.1.2 Material Weakness 41](#material-weakness)

[4.1.3 Management Challenges 42](#management-challenges)

[4.1.3.1 ACQUISITION PROGRAMS 42](#acquisition-programs)

[4.1.3.2 CONTRACT MANAGEMENT 42](#contract-management)

[4.1.3.3 INFORMATION TECHNOLOGY 42](#information-technology)

[4.1.3.4 AGING FEDERAL BUILDINGS 42](#aging-federal-buildings)

[4.1.3.5 INTERNAL CONTROLS 42](#internal-controls)

[4.1.3.6 PROTECTION OF FEDERAL FACILITIES AND PERSONNEL
43](#protection-of-federal-facilities-and-personnel)

[4.1.3.7 HUMAN CAPITAL 43](#human-capital)

[4.1.4 Federal Acquisition Service, Public Building Service, and GM&A
43](#federal-acquisition-service-public-building-service-and-gma)

[4.1.5 The 80/20 O&M/DM&E Problem 43](#the-8020-omdme-problem)

[4.1.6 Disintermediation 43](#disintermediation)

[4.1.6.1 http://www.gcn.com/print/25_20/41341-1.html
43](#__RefHeading___Toc148944441)

[5 Tactical Recommendations 43](#tactical-recommendations)

[5.1 Service Oriented Enterprise (SOE)
43](#service-oriented-enterprise-soe)

[5.1.1 SOE Operational Model 44](#soe-operational-model)

[5.1.1.1 BSC and EAPMO for BA 44](#bsc-and-eapmo-for-ba)

[5.1.1.2 ITC, ITAPC and EAPMO for RA/SA
45](#itc-itapc-and-eapmo-for-rasa)

[5.1.1.3 SSO PMO for RI 45](#sso-pmo-for-ri)

[5.1.2 Industry Standards 45](#industry-standards)

[5.1.2.1 SCA 45](#sca)

[5.1.2.2 JBI 45](#jbi)

# Executive Summary

"And so the way that they beat their competition is the way they apply
IT to their supply chain, beginning from the customer to delivery."

            Thomas Friedman, The World is Flat: A Brief History of the
21st Century

Today, Federal agencies are in a state of transformation: transformation
caused by globalization and transformation caused by policy directives.
Globalization and its effect on National Security may require that
Federal agencies transform in response to events that require immediate
and visible results. Policy directives may require that some Federal
agencies, once independent units sheltered from privatization and
cross-agency competition, transform into collaborative cross-agency
partnerships. This transformation is slow and painful, but the
transformation is underway and the agenda is clear.

The General Services Administration is presented with a well defined set
of strengths, weaknesses, opportunities and threats due to globalization
and policy directives. Customers, like the Department of Defense,
require new capabilities through assisted acquisition and next
generation government-wide acquisition contracts. Our strength as
Federal supply chain intermediary supports citizens and the war fighter
from New Orleans to Baghdad. Federal workers require assured identities
as well as safe, productive workplaces with continuous operation in the
event of an emergency. Events that affect citizen services such as
privacy loss and natural disasters require call centers that ensure tax
payers the Federal government is aware of their needs. And our role as
policy champion positions us to capitalize on policy directives like the
Office of Management and Budget's Federal Transition Framework, and the
Infrastructure Optimization Initiative that represent drivers towards a
highly optimized infrastructure shared across agency boundaries.

Responsiveness to commoditization and privatization of our services
remains a weakness. Proliferation of government-wide acquisition
contracts reduces the scale of GSA's service value to customer agencies.
And both cultural and technical integration of FSS and FTS detracts from
our focus on customer service.

On balance, opportunities clearly outweigh threats as long as we address
our weaknesses and leverage our strengths. Technology is a means to
achieve an end. And technology leadership is a means to retain our
position as the leading Federal agency in acquisition and asset
management. This information technology strategic plan "Strategies for
Modernization in a Flat World" describes four technology strategies when
combined with effective leadership and relevant business savvy will
allow us to retain and enhance our service value to the American tax
payer. The four technology strategies are as follows:

1.  We will apply process standardization and service orientation to
    position our information technology investments so we can guarantee
    high levels of service at a competitive cost and choose which core
    capabilities to retain as a shared service provider while remaining
    mindful of high exit costs in collaborative public/private
    partnerships.

2.  We will be a leader in the knowledge and technologies required for
    our customers to integrate in a secure, private and identifiable
    manner with our systems and collaborate with our associates such
    that we increase customer satisfaction and reduce cycle time in the
    Federal supply chain.

3.  We will attain a high level of efficiency in our portfolio of
    information technology investments such that our planning supports
    the ability to introduce new technologies and retire inefficient
    technologies based on effective methodologies without failure or
    disruption in support of our business objectives at a sustainable
    operating cost.

4.  We will provide information technology capabilities that transform
    GSA into a real-time acquisition and asset management enterprise
    where knowledge and information flows in a timely manner across
    organizational and functional boundaries and enables cooperation and
    collaboration among customers, suppliers and associates.

The four strategies above position us for near and long term
opportunities while assuring we address our weaknesses and overcome
threats so we retain our relevance in a flat world driven by
globalization and policy directives.

The text that follows remains in the form of an assessment of current
and future technology trends with strategic implications. In the near
future we plan to recast this technology assessment in the form of a
strategic plan that aligns with the GSA Strategic Plan which is
currently in the process of being updated. The section on modernization
principles describes key principles that enhance our capabilities to
modernize. The section on business opportunities describes opportunities
that follow from our technology assessment. The section on people and
process describes a set of reportable conditions, material weaknesses
and management challenges. And the plan concludes with a set of tactical
recommendations.

# Modernization Principles

## Service Orientation

Service Orientation is the key strategic driver and tactical imperative
in industry and government to optimize business and IT alignment and
enable organizational agility. Service Oriented Architecture (SOA) is a
style of service design that enables a composition of independently
owned and operated services to realize multiparty business processes
across value chains. Service Oriented Infrastructure (SOI) enables SOA
with runtime platform characteristics and capabilities that provide
uniform approaches to interoperability and Enterprise QoS. This section
explores key concepts of SOA and SOI.

### Service Oriented Architecture

Service Oriented Architecture (SOA) is a style of designing business
services that can be flexibly composed to support changing business
processes, by maximizing reuse of existing service implementations and
easing the implementation of new services. In SOA, the idea of an
application or system is viewed as a composition of independent services
which can be in-sourced or out-sourced across different GSA internal
lines of business and external value chain partners. The application is
therefore a virtual boundary drawn only by the functional composition of
services employed in business collaborations; the system is not a single
physical entity, but a collection of functional capabilities. These
services as opposed to applications or systems can each be independently
managed, owned and operated, resulting in the capability to interoperate
across so-called 'black box' and 'white box' service implementations. A
black box is where the details of how a service is implemented are
unknown to the consumer of the service. A white box is where the details
of the service implementation are known, usually because the service is
being provided rather than consumed. The distinction between these
informal terms of black and white boxes will likely be drawn between
different partner agencies or enterprises, because the way in which an
enterprise implements a service is a competitive differentiator in a
market driven community of interest that provides and consumes services.
A service providers white box is their service consumers' black box, and
vice versa. The virtual application or system, as a composition of
services, is often referred to as a 'composite application' in SOA
parlance.

The SOA style addresses the 'Peer to Peer' (P2P) relationship that
arises from Internet and Web enabled interactions by extending '3 tier'
architecture to 'N tier' architecture, where there is no 'edge' to the
network. In a 3 tier application, the tiers are user interface, business
logic and data or legacy/heritage resource access. This approach is
usually associated with the idea that an application is hosted on a
'server', and will be accessed by 'clients'. While this 3 tier approach
may still be used to implement service orientation, an N tier approach
assumes that service interactions must be able to cross enterprise and
geographic boundaries, and can therefore be independently deployed and
operated in disparate service host environments owned by different
enterprises. This approach highlights the idea that any given service,
hosted by a service container extending the idea of an application
server, will also be a client of another service, perhaps hosted
elsewhere. This reinforces the idea of how composite applications
combine black box and white box visibility of service implementations.

Because of these basic principles in the SOA style of computing, the
emphasis is on the 'contract' of interaction between dependant services,
as they are provided and consumed across their business community
entailments. The idea of 'design by contract' has long been a focus in
distributed computing, from object to component based development. Here
again, the difference between an object or component interface and
service contract is that the service contract is at the business level,
and is therefore directly relevant to business processes, associated
policy requirements, and technical capability promises. This business
contract, expresses these service level agreements, business policies,
and service interfaces in human and machine readable form so that the
service may be properly invoked and executed. The use of Web Services,
as a dominant SOI implementation style for SOA, has this notion built
into the basic concept of operations, often referred to as 'publish,
find, bind, execute'. A service provider publishes their contracts to a
service registry, so that service consumers may find the descriptions of
the service contracts ( SLA's, interfaces, and data exchanges) and bind
to a service implementation 'endpoint' using some network protocol, in
order to execute an interaction with that service for mutual data
exchange.

#### Service Frameworks

Often a layered approach is used to describe a 'framework' of services,
in order to categorize services by their functional responsibility. The
service framework idea begins by externalizing presentation, logic, and
resource tiers from the 3 tier component paradigm into the N tier
service paradigm, whereby all layers can be externally callable (or
'remotable') and composable. The DNI SOA Reference Model is an
instructive example of a taxonomic 'framework' for service orientation
that loosely describes a categorization or layering of service types.
Common to many other approaches to an SOA 'Framework', the DNI SOA RM
describes four layers of services; Visualization, Mission, Mission
Enabling, and Infrastructure services.

Visualization services provide UI capabilities independent of a
particular application; they can be called remotely and passed
information in accordance with their service contract that will produce
a view, or some visualization of the information for a particular UI
platform. Example views might be adapted for a Web browser, a PDA or
smart phone, an office productivity suite application, or a view
associated with some other custom client. This is useful for enabling a
common approach to multi-modal, multi-device information delivery and
interaction.

Mission services are functional or vertical domain oriented services. In
GSA's case, these mission services would be related to GSA's lines of
business, such as Acquisition, Financial Management, etc. Mission
Enabling services are value added capabilities that enable Mission
services, which are often 'mediation' services that may provide support
for executing composite applications, such as content (message syntax or
lexical) translation, message routing or orchestration, or data access
services that expose operational data stores. A Service Registry that
enables providers to publish and consumers to discover service contracts
is often considered a Mission (or domain) enabling service, as are
services that expose data sources used by domain services in composite
applications.

Infrastructure services are cross cutting concerns and non-functional
requirements common to all services, such as security services that
enable authentication and authorization, or logging services that enable
auditing or business intelligence. Other management and monitoring
services would usually be considered core infrastructure services, in
that any service environment will require lifecycle visibility and
control over deployed services.

### Service Oriented Infrastructure

Service Oriented Infrastructure (SOI) includes the enterprise middleware
and IT infrastructure 'plumbing' that enables service compositions to
interoperate while independently deployed and managed across disparate
organizations and geographies. Given that SOA is a style for designing
and developing services in any service framework layer, the basic
requirement of SOI is to normalize the ability to deploy and manage
services in any layer of an SOA framework (like the DNI framework
described above).

A service, regardless of whether it is a visualization, mission, mission
enabling or infrastructure service or resides within some other service
framework taxonomy, should be able to be provisioned to, managed and
maintained by a service host in a similar fashion. This continues with
the trend of application servers, also referred to as 'containers',
where the objective is to push the non-functional (purely technical)
capabilities to the service containers, thus liberating the service
implementers from repeatedly designing common non-functional
requirements, enabling them to focus on the functional, or business
requirements of the new service and reuse existing core, enabling,
domain or visualization services. Examples of common non-functional
requirements include (but are not limited to) container managed
transactions, persistence, security, and so on. These container managed
capabilities are now common in mature Enterprise distributed computing
application servers like the Java Enterprise Platform, and are further
evolved as the application server becomes a service host container.

#### Enterprise Service Bus

The so called 'Enterprise Service Bus' is an example of SOI. The dialog
around an ESB as the foundation of modern IT infrastructure begins with
the distinction between an ESB as a 'pattern' and an ESB as a 'product'.
Most high level depictions of ESB products look very similar to the 'hub
and spoke' mediation engines common to the Message Oriented Middleware
(MOM) infrastructures that formed the foundation of Enterprise
Application Integration (EAI) product suites. MOM oriented EAI
infrastructures usually provided guaranteed messaging and were
differentiated by value added services that helped integrate the
information from multiple disparate systems. These systems were most
often assumed to be part of the same networking infrastructure, and as
such usually began with the assumption that the boundary of an EAI
problem was within a single organization that had multiple information
resources to integrate. EAI solutions were and continue to be very
successful in providing solutions to this type of integration problem.
One view of the ESB pattern is that the same EAI functionality must be
extended across organizational, geographic and network boundaries in
order to support the desired flexibility in customizing or specializing
composite applications in a Peer to Peer fashion as exemplified by SOA
and implementations using the Internet and Web based computing today.

The best ESB products offer multiple networking and middleware
communication protocols, will support multiple message exchange
patterns, and also offer Enterprise QoS and value added capabilities
that effectively extend EAI functionality to support multi-party and
multi-enterprise computing. These products typically still fall into
either the hub and spoke or peer to peer style of integration. The ESB
product segment is not mature in that these differences are not yet well
understood by end user organizations or well described by ESB vendors.
The risk in attempting to procure ESB products will quickly resemble
previous infrastructure consolidation efforts, where all of the service
host containers will need to be homogenized. Even where this solves
technical interoperability problems, this is a known issue and
impractical for a decentralized organization. GSA's Enterprise
Middleware Bricks are a good example of this problem. Even though
enterprise middleware standards exist to drive toward consolidation of
platforms to leverage buys and skills, we still end up with panoply of
heterogeneous implementations.

The recommended approach for successful implementation of an ESB
infrastructure at GSA is to focus on enterprise computing platform
standards like SCA and JBI described below and uniform interoperability
principles across service host containers. Service host containers are
the software engines that populate the hardware nodes on the computing
grid. The relationship of service host containers to each other is 'Peer
to Peer', in that they provide and consume services from each other. The
composition of service hosts is the virtual infrastructure we want to
call an ESB. We deploy as many hardware nodes and service host
containers as needed to support provisioning of services that enable
business operations and their required nonfunctional characteristics
like fault-tolerance, or \'ilities\' like scalability, reliability,
accessibility, etc. The focus is therefore on the uniformity of
interoperability principles and standards that enable interoperability
with Enterprise QoS - secure, reliable (guaranteed) asynchronous (long
running) message choreographies with transaction (acid or compensating)
semantics.

By focusing on the context of service interactions and their normalized
deployment to a service host container regardless of what type of
service is being deployed, a tremendous simplification in both the
design and deployment and management of service interactions will be
achieved. It is this uniform approach to specifying and realizing
service implementations and their managed deployment environments that
will enable flexible specialization of business operations across GSA
lines of business and Regions.

#### Scale Invariance

Scale invariance is a deployment objective where the set of services
that make up a composite application can each be scaled as appropriate
for non-functional requirements, such as availability and
fault-tolerance, both characteristics of 'scalability'. The idea is to
think of all composite applications as a collection of services that can
be operated and managed in the same way, regardless of whether the
target service containers that will host services participating in the
composite application are a desktop productivity suite, a single server
in a data center, a cluster of blade servers, or a cluster of blade
servers in redundant data centers. GSA should take the existing approach
to enterprise middleware standards and platforms and pursue scale
invariance based on defining application profiles that describe the
'ilities' (accessibility, reliability, serviceability, scalability,
etc.) of a given composite application deployment to a host container
profile with similar well defined non-functional capabilities.

##### Server Consolidation and Virtualization

Virtualization has two styles. One is based on making multiple machines
look like one machine from the operating system perspective. Grid
computing focuses on normalizing how services are provisioned and
managed, consistent with service host containers that support service
profiles. Both styles can be used together, but the recommendation is to
get beyond thinking about virtualization purely from the machine
resource perspective, and begin to think about the purpose of those
machines in the first place; to host business applications. For this
reason, the blade computing approach is most directly aligned with the
model driven, scale invariant application and data agnostic strategy
presented here.

###### Blade Computing

The objective here is to make routine the ability to deploy a service
host container to a blade, cluster that container with another on a
different blade, and cluster multiple blades across data centers as
described by the 'scale invariance' principle. Blades are popular
because they allow for simplifying the management of machines while
decreasing the footprint and in some cases power consumption.

###### Grid Computing

The technologies to enable grid computing are slowly but surely merging
with existing technologies that provide an implementation platform for
SOA. Put another way, SOI and Grid computing are coming together. The
ability to normalize the uniform interoperability and Enterprise QoS
capabilities of a service host container, that can be used to provide
any service in a SOA framework, is where the two worlds collide. Many of
the types of services the Grid computing community talks about are
virtualized versions of what would be called 'infrastructure' services,
such as providing disk space, or compute power in general. Combined with
profiles of services and their container requirements, the P2P approach
to realizing the ESB as described here is largely equivalent to the
architectural goals of Grid computing.

### Social Computing

Web 2.0 is characterized by new collaboration tools like blogs and
wikis, rich user experiences with enhanced Web browser interactions, the
ability for users to 'markup' Web content, and the 'programmable' nature
of the Web as an applications development platform. These innovations
have progressed with astounding speed and utility in the sphere of
'social computing'. This section compares and contrasts what
techno-savvy citizens expect and what they're being given by progressive
businesses, with how Agencies currently interact with information
technology and their perspective of 'eGov'.

#### From Communication Platform to Collaboration Medium

Early philosophical statements (such as 1999's Cluetrain Manifesto)
about the many to many communicative capabilities of the Web have come
true. The Web is no longer a just place for a company to communicate
with their customers or stakeholders in a 'one company-to-many (users or
customers)' fashion; it is a platform for companies to collaborate with
them. This means that the Web is no longer just a corporate presence for
company collateral, or an advertisement to existing or potential end
users, companies now dialog directly with their end users, from self
help support to product development.

#### Blogs and Wikis

Blogging is about self-publishing, and wikis are about community
refinement. Blogs can be used for taking meeting minutes in real time,
or perhaps expressing customer satisfaction, but they are most powerful
when users link to what other uses say. There is no company statement
from an Agency or Enterprise that can be as powerful as what your
customers say about you to each other. Wikis are often used to maintain
FAQ's, or 'how-to' documentation, in a way that puts the control in the
hands of the subject experts in the extended community. Rather than
requiring a workflow with someone appointed to maintain a web page, a
wiki page is directly writable. Wikipedia is one of the most successful
and globally accessible knowledge bases human kind has ever seen. Open
collaboration of communities of interest are fueled by blogs and wikis,
and other mainstays such as question and answer forums, formerly known
as threaded discussions, which are functionally similar to what people
used to do with the Network News Transfer Protocol (NNTP), except using
the Web for interaction instead of News reader clients.

#### User Tagging

So called 'folksonomies' are based on an individuals' capability to
markup the information on the Web with their own tags, asserting their
own semantic relationships on externally published content available on
the Web. Instead of just book marking a page, a user can annotate a page
in a way that allows for software to reassemble the information into
customized views. Enabled by Semantic Web technologies, this liberates
users and content providers. Instead of guessing how information is best
served with restrictive interactive metaphors and interfaces, users can
make of the content as they wish, combining it in new and novel ways for
the individual and the enterprise. For an example of such as Semantic
Web user driven application, see 'Piggy Bank', part of the SIMILE
project.

#### Rich Interactive Experiences

Rich interaction is a maturation of existing user interface
technologies, with the introduction of some innovations that make Web
interfaces rival the most sophisticated 'fat' ,or custom clients, while
maintaining the distributed maintenance aspects so appealing on the Web.
The newest browser interaction technologies are usually based on
'Asynchronous JavaScript And XML' (AJAX), and include other mature and
well established Web UI technologies, including Extensible Hyper-text
Markup Language (XHTML) for Web content, Cascading Style Sheets (CSS)
for styling Web content rendering, among others like XSLT commonly used
for transforming XML documents or document fragments. Perhaps the most
compelling Web 2.0 innovation is the combination of AJAX interfaces with
Representational State Transfer (REST), or 'RESTful' style of
request/response. Using the basic stateless protocol of the Web, the
Hypertext Transfer Protocol (HTTP) is the basic content broker that
transmits representations of Web content expressed in some Extensible
Markup Language (XML) format, like XHTML, Resource Descriptions
Framework (RDF), the Web Ontology Language (OWL), or any standard or
custom XML taxonomy.

#### The Programmable Web

The RESTful and SOAP oriented Web Service Application Programming
Interfaces (API's) provided by many of the most successful sites on the
Web, including Google, Yahoo, eBay and Amazon, in addition to many
others, have given rise to the Web as an application platform. The
'programmable Web' is the ability to use these capabilities that are
published as service interfaces, or the business software API of the
respective site, and create new applications that may leverage or
compose services from across these distinct organizations into new and
novel Web applications, created by an external party, that fulfills an
unforeseen value proposition for some community of interest. This
phenomenon is known as a 'mashup' in Web 2.0 parlance, and when combined
with the rich interactive user experience technologies described above,
the Web is now more ready than ever to enable sophisticated business
applications.

#### Personnel Productivity

GSA is firmly rooted in Web 1.0 thinking, and needs to learn to leverage
the Web in a way that is more aligned with Web 2.0 capabilities, as a
tool to enhance human capital and institutional knowledge, create a
better and more informed dialog with our customers, and discontinue the
tremendous loss of productivity associated with 1980's style computing,
where the day to day business discourse relies on print outs of
unstructured documents from office productivity suites stored on shared
drives, often in multiple places, by various users. This approach to
knowledge management for information workers doesn't have the ability to
be leverage the tremendous power of the Web and the human sharing and
machine learning it can contribute to our business operations. Systems
integration efforts will also be enhanced by adopting Web 2.0
technologies and techniques as our business collaboration medium,
because information is created, managed and maintained in a way that is
usable by software as well as humans.

#### Horizontal Teams

The point for GSA to understand about the impact of Social Computing is
the capability to form customer service teams horizontally, removing the
constraint that the localized customer must be serviced by GSA regional
proxy team. Teams can be assembled based on the unique capabilities of
the individuals, and interact with local customers transparently,
without necessarily being in the same geographic region. For a thorough
examination of the phenomenon and its impact on customer service teams,
the author Peter Fingar's 'Extreme Competition' is given for reference.

### Enterprise Computing

The interoperability of Federal Lines of Business (LoB) and GSA Lines of
Business should be driven by the same principles. Web 2.0 mashups are a
useful contrast for comparison with existing GSA SSO interoperability
capabilities and Federal LoB interoperability alike. With the desire for
both GSA and Federal LoB to leverage the Internet and the Web as a
platform for Enterprise Computing, the basic goal is equivalent for GSA
SSO or Federal LoB mashups. Well defined service contracts that are
either published on the Web or discoverable in some other fashion is the
starting point. Add a common approach to engineering user experiences
using the newer rich interactive technologies, and a way of sharing and
refining these that leverages the creativity of decentralized
contributors, and the path to more modern Web applications as a
foundation for Enterprise Computing becomes clear.

#### Quality of Service

G2G, G2B and G2C composite applications (aka. mashups) will have higher
standards for interactions than most if not all of the programmable Web.
Businesses, and the Government alike, require that 'Enterprise Quality
of Service (QoS)' concerns be applied to interoperability scenarios,
where secure, reliable, asynchronous message transaction choreographies,
are enabled as basic assurances across business community interactions.
In G2G/G2B/G2C transactions, as in B2B, securing the wire and the
message is the basic requirement. Encrypting and signing messages that
travel over encrypted channels should become part of the default
messaging practice and technology infrastructure available today. 'End
to End' transactions are the ability to maintain transaction semantics
across enterprise boundary crossing interactions. Transactions should
maintain ACID (Atomicity, Consistency, Isolation, Durability)
characteristics where possible, and otherwise must be engineered with
'compensating' transaction semantics throughout long-lived and long
running G2B and G2G interactions. This will require trading partners to
understand how transaction coordinators will be used and how to rollback
the state of a business information system when business and technical
interaction exceptions and transaction failures inevitably occur.
Solutions must integrate and extend the capabilities of GSA's HSPD-12,
eAuthentication, Identity Management, Single Sign-On infrastructure, and
consider the ISS-LOB, FEA Security Profile and reference models, and
other security, privacy, and governance concerns, as well as federal and
international standards developed by such organizations as NIST, W3C,
and OASIS.

GSA should normalize our approach to enterprise quality of service
concerns across internal SSO Lines of Business as we will be required to
with external trading partners. In doing so, Java and Web Services are
assumed to be the dominant implementation platform, and therefore the
focus of End to End transactions will take on realization of OASIS
standards including WS-Coordination, WS-Policy, WS-Addressing,
WS-Reliable Messaging, WS-Business Activity and WS-Atomic Transaction.
As the Web Services tier is handled by some underlying enterprise
computing platform, the objective of End to End transactions is to carry
through the information from the Web tier to the underlying computing
platform. Using Java as an example, a SOAP message as one of many Web
Service messages must maintain its Enterprise QoS as it is translated
into the Java application server, possibly by putting the contents of
the SOAP message on a Java Message Service (JMS) queue. GSA should seek
to understand how these standards and their capabilities can be
implemented in conjunction with IT infrastructure modernization as we
progress towards service host containers that populate the ESB and
enable composite applications. These standards and their capabilities
exist today and have open source implementations, and GSA should raise
the expectations of these capabilities with COTS vendors.

#### Privacy, Trust, and Non-Repudiation

Extending Enterprise QoS concerns beyond secure, reliable asynchronous
message transaction choreographies will lead directly to the ability to
establish trust and maintain privacy for non-repudiation of business
transactions and proof of proper handling of personally identifiable
information. These aspects of business transactions represent a
tremendous growth area and business opportunity for mediation services
that will be required for G2G, G2B and G2C composite applications in the
near future. Of these, non-repudiation is the simplest, which will be
directly linked to basic infrastructure capabilities like logging, and
will transform the way we think about the Extraction, Transformation and
Loading (ETL) process used to create knowledge discovery data marts and
warehouses to support 'business intelligence'.

The requirement is to understand the 'business process playbook', which
will contain a set of business scenarios that exercise paths through
architected multi-party trading relationships, capturing all of the
audit related information at each step in the long running business
transaction. At each stage or activity in a business process, the
information captured about the interaction must be sufficient to explain
the complete or incomplete outcome. The accumulation and
contextualization of this information should be ETL'd into information
stores used by business optimization analysts, who continuously monitor
and manage the efficiency and effectiveness of the enterprise business
process playbook.

The recommendation is for GSA to understand the Semantic mediation
service space, and establish an internal center of excellence that will
enable GSA to provide semantic mediation services and determine their
viability, since these services will be both the market space and
delivery channel of potential new products for GSA.

#### COOP and Disaster Recovery

The relationship of COOP and Disaster Recovery are similar from an IT
infrastructure perspective. The requirement is for GSA to be able to
dynamically re-establish trading partner networks from the ground up.
Since the Internet and the Web is a public network that was specifically
designed to prevent single points of failure, GSA's emphasis should be
on replicating the business applications infrastructure beginning with
some new (public or private) network access point, in the event that
either are taken offline. Obviously GSA has and will continue to mediate
risks against the GSA WABN and mission critical data centers being taken
offline, however the COOP principle expressed here is to extend the
hardening and redundancy to replication and syndication in order to
reinstitute a network of services and the data used by those services.
GSA should be able to stand up the applications infrastructure that is
required to access all mission critical data quickly and efficiently.
Accomplishing this represents a tremendous business opportunity for GSA,
by addressing concerns arising from natural disaster recovery scenarios
like Katrina, and many of the information warfare issues inherent in the
'post 9/11' world.

##### Replication

It is useful to note that the power of yesterday's server is loosely
equivalent to today's laptop, and that much of our purchased computing
power is wasted, in that the majority of machines on our local and wide
area networks use less that 10% of their processing power. The
capability of the computing grid, when considering the power of today's
latent processors and the availability of commodity hardware, should be
leveraged to support business continuity as a result of normalizing
service host containers. If we view the large number of machines that
can host business services as computing nodes, then Grid computing can
leverage any available processing power by applying the same techniques
to transform a machine previously used only for requesting services and
information into a machine that can provide services and information.
Data centers are just an ideal computing scenario, but the fabric of
computation must maintain its capability if these data centers are taken
offline.

##### Mesh Networking

Given a peering point, the network can be established by chaining
wireless routers across the geographic areas of interest. This is a
capability being built in to many leading operating systems and also
used with various wireless networking standards, as in Wifi or WiMax
'chaining'. This is the basic idea of creating a network of machines
where either a network didn't exist. Given the capability to reestablish
the service host containers, data sources, and redeploy services to
those containers and operate on that data, GSA can enable a mission
critical capability beyond redundant failovers, and this may represent a
significant potential service requirement in the near future.

##### Syndication

Data services that expose mission critical data should take advantage of
the P2P 'swarming' protocols and their capabilities (see bittorrent.com
as a popular example). This would provide for a consistent image of
mission critical data that can be turned into a relational or semantic
store as needed by business applications in a localized COOP or disaster
recovery scenario.

##### September 11^th^ and Katrina

The problem with COOP and disaster recovery scenarios such as September
11^th^ and Katrina, is that the infrastructure and all its hardware and
software must be available and ready just as an ambulance is dispatched
to a disaster scene from any number of hospital emergency rooms. The
virtual nature of software alleviates the problem of not knowing how
much hardware and software will be required to support the dynamic
recovery of information infrastructure. Hardware capabilities required
for a service host container is practically a ubiquitous commodity, and
software distribution is easily solved in this scenario by certain
styles of open source licenses. The ability to replicate software
services using commodity computing machines as service host containers
across the nodes of the mesh network can be planned for against disaster
recovery 'profiles'.

If GSA were a private corporation attempting to provide these services
then we'd likely partner with or invest in a (green) power generation
facility. GSA's COOP ability with mesh networks and service hosts on an
ad-hoc grid don't mean much without electricity, which is of course
likely to be one of the principle targets in an asymmetric war.

## Enterprise Architecture

Enterprise Architecture (EA) means different things to different people.
For a government Agency, EA often begins and ends with capital planning
support. For a Systems Integrator (SI), EA often begins and ends with
software design, development, testing, deployment and management of a
single application. At GSA, EA intends to encompass both of these
strategic and tactical perspectives as a progressive elaboration from
high to low level architecture abstractions and corresponding assets.
This can only be accomplished by a federated effort across SSO's.

The relationship of the most salient IT trends can be summarized by
linking the concepts and capabilities found in what may appear to be
three separate communities of practice; Model Driven Architecture (MDA),
Service Oriented Architecture (SOA), and Business Process Management
(BPM). The desired properties of the Real Time Enterprise, including
agility, executability and traceability are best served by incorporating
the capabilities of MDA, SOA and BPM into a holistic methodology that
can be executed and governed by business and technical stakeholders in
GSA.

We assert two key properties of EA assets throughout this process,
executability and traceability to unify concepts in SOA, MDA and BPM. In
this section we explore the capabilities of Executable Architecture and
its explicit traceability from high level business representations
through successive refinements to managed code and applications
inventory. The focus is on the 'service orientation' of business
processes and supporting IT infrastructure in order to standardize core
operations while facilitating specializations that may be required in a
particular GSA LoB or Region.

### Model Driven Architecture

The purpose of being 'model driven' is to isolate the business
functionality from the underlying implementation technology, thereby
decoupling the business mission and IT infrastructure in order to enable
each to change more flexibly. We often find ourselves unable to keep up
with change; change of implementation technologies and change in
business operations. Keeping those two things in sync is all that is
meant by 'business and IT alignment'. The concepts inherent in Model
Driven Architecture provide an approach to understanding the
functionality of business applications in a way that is independent of
an implementation. Capabilities to focus on in GSA's engineering
practices are then the manner in which models of business functionality
are used as a specification that can be utilized to automate the
transformation from the source specification through various levels of
detail to a target infrastructure platform realization. This approach
enforces explicit traceability of architecture assets across levels of
detail, and enhances interoperability across heterogeneous platform
selections. When combined with a SOA design style for creating business
model specifications, this contributes significantly to resulting
agility of adaptation to changes in business requirements when they do
occur as part of a reengineering or an optimization effort.

### Business Process Management

BPM is discussed by Gartner as a 'management theory'. The foundational
ideas include business process modeling and simulation, direct
executability and deployment of process models, and continuous
improvement based on direct observation of actual business activities
and information exchanges. In order to introduce this management
discipline into an organization, Gartner asserts that business
professionals need to acclimate themselves to the capability of BPM
analysis tools to validate (as-is and to-be) models and their (standards
based) visual representations, so that the simulations these modeling
tools enable can be used to either understand an existing problem or
describe a desired solution in a business process. Gartner asserts that
IT professionals need to enable the direct execution of these models
using SOI and ease the integration with existing systems portfolios. In
the BPM community, the SOI is referred to as a Business Process
Management Suite (BPMS). Finally, Gartner asserts that the distinction
between what was once called Business Process Reengineering, and what is
now called BPM, is that BPR was primarily focused on understanding and
implementing an idealized business process. BPM acknowledges there is no
such thing, and therefore focuses on improvement iterations based on
observations of the actual business transactions, as enabled by the
agile SOI infrastructure.

MDA is an enabler of successive refinement of architecture assets from
business abstractions to technical concretions. Given design modeling
and runtime infrastructure standards, the process of successive
refinement of a business service to a realization on a technical
platform can be largely automated. This code generation capability is
similar to past attempts of the so called 'case tools', except MDA
approaches to automating transformations from source to target assets
are based on open design, runtime and metadata standards. MDA
transformations are often discussed as being horizontal or vertical, and
isometric or isomorphic in nature. Horizontal transformations are
intended to express the same level of detail, structure and semantics in
different views. Using a business process as an example, a UML2 Activity
Diagram can be transformed into a BPMN diagram that represents the same
business process. A vertical transformation is typically one that
introduces new detail, structure and semantics and is considered
isomorphic in nature. MDA provides a basis for automating these
transformations.

By using MDA standards for architecture models, beginning with a 'domain
specific language' for representing SOA, and by realizing business
processes as a composition of those services described in the BA
collaborative role interactions, the capabilities and themes of MDA,
SOA, and BPM can be united in an Executable Architecture practice and
methodology. This has been the focus of the approach to creating the
'OneGSA' target architecture.

### Application and Data Agnostic

The principle being described by 'application and data agnostic' is one
that says no matter what the business functionality or utility presented
by a service or a composite application, the ability for client
interaction and service implementation interoperability should be
normalized. An example illustrating this principle is webmail; the only
difference between the information contained in an email using a 'fat
client' such as Lotus Notes or Outlook and interacting with that
information via a 'thin client' Web browser is the degree to which the
information is coupled to a delivery medium, including a specific client
and specific transport and message protocols, for example SMTP/POP-IMAP.
The information exchanged via the Web or Notes and the interactive
capabilities are or should be identical. The ability for an information
exchange to be repurposed across a variety of interactive modalities is
based on the use of structured information formats and standard
transports. Expressing the content of an email message has a structure
that can be leveraged across interactive modalities, and thus our
ability to interact with email via a custom client or a Web client
browser using different message and transport protocols. Here again, the
Web is the great normalizing example. GSA should examine all business
applications and consider HTTP as a transport protocol, XML for defining
message formats, and XSLT/CSS for designing user interfaces as a
baseline for any business interaction, and look to leverage custom
clients where it's either easy or necessary.

Extending this idea beyond email, is to say that all service
interactions are 'designed by contract', and this contract describes
structured information exchanges through service provider and consumer
specifications including interfaces and their structured information
exchange message payloads. The Web enablement of business applications
began this transition, and the opportunity to exploit these principles
allows for 'pervasive computing' techniques that can incorporate
'occasionally disconnected' and multi-device interactivity, regardless
of the business application functionality, be it email or an acquisition
wizard. The pursuit of these principles has a unifying and simplifying
effect on how software that implements business functionality is
designed, and the infrastructure required to support the business
software. In addition, this principle promotes and prepares business
systems for new interactive requirements which may be useful for
individual customer adaptations and regulatory mandates, such as
M-O6-16.

#### Pervasive Computing

Pervasive Computing is an informal term used to describe the
'occasionally connected' world of multiple devices people use to access
their corporate and personal networks. As part of the 'right data, right
time, and any device' outgrowth of web enabled personal digital
assistants and cell phones, this section explores the evolution and
desired characteristics of client capabilities across 'multi-modal'
network access devices.

##### Client Services

The past few decades of computing infrastructures have seen a continuous
improvement of architectural paradigms that have informed the design and
development of compute infrastructures. From time sharing on mainframes,
to the PC revolution and its client server software, to the Web
revolution and its 3 tier applications, to SOA and the natural fit with
N tier, P2P and Web Services, one thing has maintained primacy in the
utility of these computing styles: human factors. User Interface
technologies have seen a constant refinement of capabilities, because if
the user experience doesn't deliver a combination of interactive
simplicity and business utility, users will almost always supplant the
software system and find some other way to get their job done. The lack
of sufficient human factors utility will never justify the support costs
of a software maintenance organization.

The evolution of the user experience has been an interesting one,
beginning here with client server and the PC, where much if not all of
the business logic was localized to take advantage of cheaper PC
processing than expensive server processing and the cost of moving data
over the usually private network. As such, the user interface evolved to
be largely what we continue to experience today in the so-called office
productivity suites. The custom (or 'fat') client is jam packed with
features and functionality that only power users learn how to exploit,
that the majority of information workers never use, contributing to
complexity driven management cost with literally no business driver
other than status quo acceptance.

Other problems with client server computing are that business logic
algorithms and user interfaces become tightly coupled in this so-called
2 tier application approach. The Web drastically changed this and made
distributed management of applications more prevalent, where the
business logic migrated to servers with the advent of the public network
and the desire to leverage the ubiquitous 'thin' client, a Web browser.
Applications then became very page based, and Web user interfaces were
also often tightly coupled with business logic, but outside the client
on the server side. The Web browser as default client platform had a
positive effect on distributed management costs of clients, but the
application tiers were often interdependent in ways that were difficult
to manage, because if you changed a data structure, the interface often
broke, among other common ailments of early Web applications. The user
experience also suffered, because of the round-trips required from the
dumb client (Web pages) to the server at each interaction. Web clients
were really dumb, after users had just gotten used to custom (fat)
clients with tons of features that responded quickly.

With the maturation of Web application engineering discipline, and now
with Web Services, what ultimately gets displayed to the end user from a
single browser request might be the result of multiple Web application
environments independently processing information that gets assembled
into a single view for the user, as is common in aggregation
technologies like portals. This has helped decouple data from logic from
presentations, and the underlying technologies now have standardized
patterns and best practices for dealing with these issues.

Today Web browsing enables rich Web interactive functionality based on
decoupling data from the behavior of user interface controls and their
style of displaying that data. Basic functionality like interacting with
spreadsheet cells, the population of those spreadsheet cells with
requested data, and the style of rendering them are all functionally
independent capabilities of various human factors 'plug-ins' to the
interface features of a standards based Web browser. PC processing power
has increased dramatically in accordance with Moore's law, and so users
constantly desire more enhanced interface functionality commensurate
with the power of their desktop or laptop systems.

The result of this evolution has given rise to the idea of 'client
services', where thin clients are enhanced with best practice approaches
to enable the richer interactive capabilities of custom or fat clients,
and the information is captured from composite applications. The ability
of any of these types of clients to access the network and invoke
services is how we derive the term 'client services'. GSA should pursue
the use of these standards based approaches uniformly across business
software development efforts, and create consensus around the ability to
use enhanced Web client service functionality as a baseline. When custom
clients are desired or required, the way in which information access,
repurposing, visual rendering and interactive behaviors should have a
direct correlation from Web based client services and custom client
based client services. The effect of this would be to provide standard
human factors approaches to either Web or custom client services based
user interface development.

###### Role Driven Widget Composition

The Windows Presentation Framework (WPF) as part of Windows Vista
(formerly codenamed 'Avalon' clients) is an example of this move toward
client services functionality, for custom clients. The emphasis is on
providing and therefore maintaining and managing only the interactive
functionality required for the business interaction. The interactive
environment is more focused on the information worker and their
activities, enhancing simplicity and utility for the end users. The
resulting custom clients are based on a similar functional framework of
information access, display and interactive control behaviors. Each
client is just a custom and declaratively configured 'skin' over the
common toolkit or 'bones' that make up an Avalon client. Other examples
of this evolution in Web clients include Mozilla's XML User interface
Language (XUL), and more recently the combination of Adobe's Flex and
Flash, where Flex serves the usability components to Flash that displays
and controls interactive behaviors. The idea is to decouple the
component functionality of user interactive controls, their behaviors,
rendering approaches, and information retrieval in a way that supports
the client services paradigm, and makes them easy to compose into custom
clients using the same set of tools. You only include the spreadsheet
control when the business activity dictates using cell summation or some
other standard use of a spreadsheet.

The opportunity to create these client services interfaces should be
driven by the functional decomposition of the activities required in a
business operational scenario, and as such can be directly defined in
accordance with specific end user responsibilities, giving rise to
custom client services tools with human factors that adhere to the
principle of 'role driven widget composition'. This idea exploits the
Business Architecture's depiction of operational activities, and the
definition of the rich client functionality directly from the Reference
Architecture's elaboration of the Business Architectures activity
definitions. GSA should focus on understanding the model driven nature
of client services functionality, and determine how to create equivalent
functionality across the various types of client service foundations,
such as WPF, JWS, or AJAX based Web interfaces. The components will have
the same functional and non-functional requirements, and it is possible
to automate the derivation of any target client from the same source
model.

###### RCP's and AJAX

Rich Client Platforms (RCP) such as those based on Eclipse use a similar
philosophy as WPF. Eclipse provides a client that can be easily
customized for specific views required for composite application
functionality in the information technology workers business activities.
IBM uses Eclipse as a foundation for all of the custom clients that
surround its WebSphere product line.

Java Web Start (JWS) is already a part of the standard Windows desktop
image at GSA, and has for years included a similar powerful declarative
approach to managing custom client distribution and their Java based
componentry, or widgets. The Java Network Launching Protocol (JNLP)
standard is an XML file that is read by JWS when a managed Java client
is instantiated that looks to a centralized location for any updates or
for the overall composition of the client functionality.

The Sun Netbeans environment also offers this capability. What
distinguishes both Eclipse and Netbeans is their independence from any
given operating system, where Avalon clients will require and only run
on the Windows Vista platform, both Eclipse and Netbeans are client
services toolkits, or rich client platforms that are platform
independent. In addition, both Eclipse and Netbeans are free and open
source toolkits.

###### Presence and Location

Any interest at GSA in enabling our customers to walk into a GSA managed
building and start using GSA computing resources with whatever device
they're carrying? If so, presence is more than something that occurs
within the Notes Chat client.

###### Internet protocol Version 6 (IPv6) and Radio Frequency Identification (RFID)

**IPv6**

The migration from IPv4 to IPv6 must be business and capability focused.
From a capability perspective, there are a few reasons to migrate to
IPv6 including bigger address space, support for mobile devices, and
built-in security.

Bigger address space: As the universe of potential uses of IP address
space increases, the bigger address space IPv6 offers is the most
obvious enhancement it has over IPv4. The larger address space negate
the need to employ creative address manipulation to support
infrastructure needs. Hence, IPv6 allows full, unconstrained IP
connectivity for today\'s IP-based machines as well as upcoming mobile
devices like PDAs and cell phones.

Mobility: There are a number of business and consumer application that
can benefit from the mobility feature inherent in IPv6. However, support
to mobile devices will require a special protocol \-- called \"Mobile
IP\"; and is one of the requirements for every IPv6 stack. Thus, if you
have IPv6 going, you have support for roaming between different
networks, with global notification when you leave one network and enter
the other one. Support for roaming is possible with IPv4 too, but there
are a number of hoops that need to be jumped in order to get things
working. With IPv6, there\'s no need for this, as support for mobility
was one of the design requirements for IPv6.

Security: When it comes to integrated security and identification
management in general, the IPv6 security feature can support a rich
array of business implementations. The IPv6 protocol stacks are required
to include IPsec. IPsec allows authentication, encryption, and
compression of IP traffic. With some limited exceptions, (e.g.,
application-level protocols like SSL), all IP traffic between two nodes
can be handled without adjusting any applications. The benefit of this
is that all applications on a machine can benefit from encryption and
authentication, and that policies can be set on a per-host (or even
per-network) basis, not per application/service.

**GSA IPv6 Implementation Strategy**

Market Approach: Because IP service providers are expected to drive the
early adoption of IPv6, requiring organizations with IPv4-based networks
to establish necessary capability to interoperate with IPv6-capable
service providers, GSA is following market penetration of IPv6 and will
include the requirement for IPv6 compatible products in future IT
investments.

Selecting Products and Capabilities: GSA has a defined implementation
plan that builds out IPv6 from a central core. The Office of the Chief
Information Officer (OCIO) is working closely with the Chief Acquisition
Officer to address IPv6 technology acquisition. To avoid unnecessary
costs in the future, GSA will, to the maximum extent practicable, ensure
that all new IT procurements are IPv6 compliant. Any exceptions to the
use of IPv6 requires that the agency\'s CIO give advance written
approval. An IPv6 compliant product or system must be able to receive,
process, and transmit or forward (as appropriate) IPv6 packets and
should interoperate with other systems and protocols in both IPv4 and
IPv6 modes of operation.

**RFID**

Within GSA, the ability to manage the supply chain and business assets
is critical to our success. Radio frequency identification (RFID)
systems are emerging as an essential enabler to address this and other
business issues. The maturation of RFID technologies has added to the
enterprise arsenal - the ability to manage supply and assets in a way
that promises a level of efficiency and accuracy that is not easily
matched by legacy technologies.

RFID system consists of several components: tags (mobile devices), tag
readers (interrogator), edge servers, middleware, and application
software. A number of business and technical factors should be
considered when making a decision on the appropriateness of a RFID
solution; such as:

-   The anticipated business uses of RFID technologies.

-   The stability, cost/ROI, and performance characteristics of a
    specific RFID technologies

-   The required level of internal investment and that of our customers
    (e.g., read capability). Also, the expectation of their compliance.

-   The complexity of the environment into which the technology is
    expected to be employed (e.g., global and local technology
    restrictions imposed by national interests, physical environment,
    and, privacy and security concerns).

-   The variety and mix of solutions being employed by both private and
    public partners.

-   The level of information that must be available (i.e., performance
    characteristics/smart versus dumb tags and information exchange
    characteristics)

-   The difficulty of implementing specific RFID systems.

RFID will likely change more than the way data is collected; it had the
potential to result in new types of actionable information that create
opportunities to operate differently and more efficiently. The
deployment of RFID can provide visibility into operations that were
previously inaccessible because of limitations inherent in legacy data
collection/identification technologies. GSA can take advantage of
ability to track assets in more places, without human intervention, to
create new features and applications. The capabilities realized through
RFID technologies will result in software applications needing to be
modified or developed to take advantage of the resultant capabilities.
The IT infrastructure may need to be extended to support RFID
operations. Hence, identification data and ID event-related data (such
as time, and location) being pushed across the IT infrastructure will
need to be processed using flexible business rules, prior to being
pushed to a business application, or submitted in response to a request
for data. Otherwise, the RFID system could produce too much data and not
enough quality information.

The shift has taken hold in the private marketplace. Middleware is
constantly being developed to support RFID systems employment in legacy
IT system and software environments. Enterprise resource planning and
inventory management system software providers are offering middleware
or software modules to support RFID use with their applications.

GSA's embracing RFID technologies is predicated on both internal
business efficiencies and the fact that a key customer, DOD, has
published requirements that their vendors place RFID tags on all
shipments to improve supply chain management. The importance of this and
other customers and suppliers adds to a need for an enterprise RFID
strategy.

###  Design Locally, Deploy Globally

Given the established principles of model driven, scale invariant,
application and data agnostic approach to composite application design,
and the ubiquity of service oriented infrastructure that supports direct
deployment of these composite applications, the result is freedom to
design, develop and deploy custom applications that serve the unique
needs of localized business communities and their unique economies. This
is the meaning of the principle 'design locally, deploy globally'. This
principle will alleviate most of the tension between advocates of
centralized bureaucracy or regional autonomy, and is perhaps the most
compelling idea for IT modernization to support GSA's existing culture
in a peaceful co-existence of regional and central economies of
specialization and scale. The principles, patterns, and existing
infrastructure enabling the service oriented architectural style in the
design and development of business applications becomes a federation of
best practices, where management and maintenance of deployment
infrastructure can be consolidated, but management and maintenance of
business applications can be localized for best support to end users.

This idea simply means that when a local business development desires
new functionality, they know how to discern whether or not existing
services can support their composite application (functional and
non-functional) requirements, and how to design new functionality and
compose this with existing functionality to achieve their requirements.
The local designers' deployment of their composite application to global
IT infrastructure resources is done in accordance with the 'profile' of
the composite application, and the division of labor is clear -- the
local IT designer/developer supports the business algorithm, and the
management and monitoring of their globally deployed composite
application leverages infrastructure consolidation.

The ability to present both standardized core operations and the
flexibility to specialize those operations is a primary challenge for IT
infrastructure in either decentralized or federated business operations.
The assumption here is that GSA is currently decentralized with respect
to business applications, and desires to become a federation based on
the principles and capabilities described in this strategy document. The
Business Architecture directly supports business process orientation, as
collaborative role interactions that are realized by a composition of
mission or domain services. This \'flexibility\' capability and balance
between standardizing core operations and allowing for business
creativity is key to the balance between operational standardization and
localized operational innovation that allows for different realizations
of the same business processes. This enables the federation of business
operations using centrally managed IT infrastructures, and will
alleviate the brittle integration problems that currently plague GSA's
systems portfolio from an Agency wide perspective.

The way in which a business service gets implemented can be a unique
composition of other services in any organization or region, since the
emphasis of SOA and its enabling SOI is on the interoperability
\'contract\', including the interface specification, the message
specifications, and other aspects of contracts such as business policy
expressions and technical service level agreements. By focusing on the
interoperability contract and interface specification, we can encourage
creative implementations that are specialized for a local constituent or
differentiated from competitors who offer a similar service. This is
important for a variety of reasons; because (we need to understand that)
COTS implementation will never lead to competitive differentiation, and
the local business economy is always best understood by local management
rather than centralized management. With all the emphasis on A-76 for
Federal Lines of Business, and the inevitable future of non-appointed
and market driven shared service providers, ultimately GSA will be
subject to the same market dynamics regardless of whether we are
considering our internal systems portfolio or the portfolio of external
customer facing systems, such as those where we are an eGov or Federal
LoB provider. Solving the SOA/SOI/SOE design by contract problem enables
a seamless progression from composite application outsourcing to supply
chain globalization. This is the principle driver for GSA to create
uniformity in the way in which a service is defined (SOA) and deployed
(SOI) through the progressive elaboration of BA to RA to SA to RI.

In this circumstance, the 'hammer and nail' analogy is positively
applied. Every SOA defined mission, enabling, infrastructure or human
factors service is a nail to the uniform provisioning and
interoperability capabilities of the SOI hammer. In this fashion,
business constituencies don't notice a custom white box or outsourced
black box implementation anywhere, they only notice and care that the
service provider and consumer contracts are upheld. This approach to
infrastructure is in stark contrast to conversations with vendors of
proprietary monolithic products that are often not yet SOA/SOI enabled,
such as Comprizon or Momentum, and in the recent past, SAP. It should be
noted here that SOA/SOI are common pursuits of COTS vendors, and
typically the more market segment entrenched the COTS tool is, the more
difficulty that vendor has in adapting their product roadmap to the
obvious best practice requirement in industry and government in the move
toward SOA/SOI modernization. We are, or have been forced to deal with
many of these systems as a COTS customization and integration problem -
one that is point to point, idiosyncratic, and brittle across
dependencies, amounting to the anathema of uniformity in SOA design or
deployment to modern SOI.

What we desire is an SOI infrastructure that allows for services that
fulfill SOA designed contracts to be hosted and managed, regardless of
how they might be specialized for a particular line of business or
regional implementation. This requires both an operational functional
requirements understanding, of the kind described by Business
Architecture, and the non-functional requirements of the service host
container. The service host container must allow us to uniformly specify
and deploy services where their contracts can be fulfilled, instead of
approaching COTS customization and COTS to COTS integration from a
specific product point of view, which we are forced into. Ideally, we
don\'t want to have to deal with proprietary API's or module
customization, but rather specializing service implementations that all
have identical contract specifications and host container capabilities.

### Executable Architecture

GSA's Executable Architecture methodology employs open standards based
structured modeling techniques for business processes composed of
service collaborations and their information exchanges called
\'Executable Architecture\' (EA). Technologies that enable EA come
primarily from the Model Driven Architecture (MDA) and Semantic Web (RDF
and OWL) structured and knowledge modeling communities, managed by the
Object Management Group (OMG) and the World Wide Web Consortium (W3C)
international standards bodies respectively.

With this standards based foundation, \'Model to Integrate\' (M2I)
capabilities automate the generation and deployment of runtime
implementations directly from design time abstractions. M2I is
equivalent to the objective of BPM Suites. The difference is that the
MDA approach enables a broader scope and better visibility of the
enterprise wide Service Oriented Architecture, and a more thorough and
mature approach to the realization (either build or buy) of components
that implement services supporting business operations.

EA is therefore a tool used to reduce the resource burden in Capital
Planning and Investment Control (CPIC) and to collapse the Software (or
Solutions) Development Lifecycle (SDLC). During design or \'inception\'
and \'elaboration\' phases, business analysts and operational subject
matter experts use EA to *validate* the functional decompositions
described by the Business Architecture. When the FEA is applied as an
\'aspect\' of the business operations, we can automate the generation of
CPIC related assets. When M2I is applied, we can leverage the Business
Architecture directly as we move into the \'construction\' and
\'transition\' phases of an SDLC, by automating much of the code
generation and provisioning in realizing business services. When the
resulting composite application is shown to successfully fulfill unit
and component interaction test suites, the system\'s implementation of
the desired business functionality is *verified*. This methodology is
described in the next section.

### BA/RA/SA/RI 

A Business Architecture (BA) models the service orientation across all
business domains (functional segments) and their operations. It is the
business system conops of the enterprise as a whole. A Reference
Architecture (RA) models the logical software system and provides
detailed service specifications required to realize the business
services described by the BA. It is the software system conops. A
Solution Architecture (SA) is a model specific to the target technology
platform or existing systems infrastructure, representing the particular
concrete implementations that are directly traceable to the RA and BA. A
Reference Implementation (RI) is the actual asset that is managed and
deployed as software source or application binaries or both. Where GSA's
systems provide a traceable alignment to SA, RA, and BA, RI's are the
GSA IT Portfolio. This section explores the goals and objectives these
architecture abstractions and their relationship to each other and GSA
stakeholders.

#### Business Architecture

The EA practice within the OCIO at GSA employs MDA standards as a
language and grammar for describing service orientation of target
business processes and composite applications. This section describes
the capabilities and characteristics of this approach to Business
Architecture modeling and the resulting utility for strategic alignment
and tactical planning.

##### Collaborative Role Interactions

The OCIO Executable Architecture methodology describes Business
Architecture using a simple grammar of Collaborative Role Interactions.
The focus is on the functional responsibility of the Role, and its level
of granularity, or decomposition. A GSA line of business is referred to
as an Enterprise Discipline, which contains Enterprise Roles, which are
further decomposed into Work Roles, each having Activities and Sub
activities. A business process is a composition of roles specific to an
orchestrated information workflow that supports a collaborative outcome.
Business collaborations across value chain partners are then described
by a 'community process' across the multi-party, multi-enterprise
including GSA white box and our buyers and supplier black box
Collaborative Role Interactions.

##### Systems of Systems

This approach is useful to understand the 'system of systems' both from
a business and system interaction context, and as such forms the basis
for understanding a Certification and Accreditation (C&A) boundary for
supply chain globalization. This approach also presents an opportunity
to generalize desired areas of enterprise wide standardization, while
allowing individual Organizations and Regions to easily 'build out'
specialized functionality to support their unique implementations of
standardized functions as required or desired, using the same simple and
flexible Business Architecture abstractions.

##### Organizational Design and Human Capital

Although the Business Architecture is organizationally agnostic in this
depiction, when we use this grammar and these conventional distinctions
consistently, Collaborative Role Interactions can directly support
Activity Based Costing, by aligning the relationship of an Enterprise
Discipline to an Organization, an Enterprise Role to an Organizational
Office, a Work Role to an individual's position description, and the
activities they perform described by Work Role Activities and Sub
activities. The result of this approach to business modeling produces an
interactive depiction of the organizational concept of operations, which
should be used to canonize the organizations institutional memory and
support Human Capital training. The Business Architecture adds the
context of interactive dependencies to ABC.

##### Investment Endpoints

The Business Architecture is also IT infrastructure agnostic, however at
this point, the concept of a Work Role can also be used to describe the
service orientation of business process orchestrations, in the SOA
context. The set of mission or domain services that enable the
choreography of interconnected business processes across enterprise and
geographic boundaries is the composite application inception, defining
the community of interest or practice and their functional
responsibilities to each other. The Work Role level of functional
decomposition is then seen as describing the service granularity for
alignment with GSA's existing IT infrastructure and systems portfolio
aligned with the Exhibit 53 and their service orientation. The portfolio
of systems are said to be systems 'actors' that provide the functional
responsibility described by Work Roles in the Business Architecture
decompositions. These systems actors either fully automate the
operational procedures or provide a service 'proxy' for human
interaction required by GSA information technology workers, and the
activities they perform as defined by their position descriptions. Where
the analysis of the opportunity for leveraging existing investments in
the realization of the Work Role leads to an understanding or functional
fulfillment by an Exhibit 53 investment, the existing investment is
referred to as an Investment Endpoint. When the analysis shows a lack of
alignment, representing gaps in our existing IT Portfolio, we refer
simply to a target Service Endpoint, which is used to analyze COTS
offerings and further to guide procurement or development in the
elaboration and realization of a target Service Endpoint.

##### Information Exchange

Information models are used to describe the business concepts and terms
that are individual data elements that get aggregated into message
taxonomies. These messages, or 'business transactions' can be directly
transformed into XML schemas, and their real or example instances get
attached to the services information exchanges, as defined by the
Collaborative Role Interactions in the Business Architecture. Related
business transactions are grouped into topics of business conversations
between interoperating roles, called protocols. The protocols, when
populated with messages derived from information models, combine to
specify the service interface, which is a requisite part of the service
contract that should also include other policy and service level
agreement descriptions. Roles can both initiate and respond to business
conversations, and this forms the basis for interface impact and
information dependency interoperability analysis from both an
operational and infrastructure perspective.

##### FEA Integration and 'Line of Sight'

The Business Architecture should be annotated with the information
required to report on our budget alignment using the Federal Enterprise
Architecture Reference Models (FEA RM). The Business Reference Model
(BRM) describes the generic functional domains of all Federal Agencies,
and can either be shown to incorporate or be extended by GSA's internal
lines of business. The Service Component Reference Model aligns the
functional responsibility of the Service and Investment Endpoints to the
SRM functional categories. The information model that describes the
interactive information content, or the message flow across services,
can be represented by the Data Reference Model. The technologies used to
realize the Service and Investment Endpoints and data flows that support
Agencies business domains are categorized according to the Technical
Reference Model. Metrics associated with the technologies used as inputs
enables service outputs. The contribution of services that support the
business processes throughout various value chain interactions
contribute to business outcome(s) metrics. The Performance Reference
Model describes this relationship as a 'Line of Sight'.

##### Navigability

The Business Architecture can be navigated by business analysts in an
interactive fashion that allows for the analyst to inspect each exchange
of information in each business conversation that is initiated and
responded to by the roles that have been composed in any business
collaboration. It is in fact this process that creates the Business
Architecture, it cannot be created by EA experts, they can only
facilitate the creation of the Business Architecture from a technical
point of view, including how to use modeling tools and apply appropriate
decomposition and annotation conventions. In this way, the Business
Architecture is 'owned' by the business, but managed and maintained by
EA related organizations. When a business analyst can validate in
conjunction with an authoritative business Subject Matter Expert (SME)
that the functional responsibility of the roles, their contextual
dependency and interaction with other roles, their information
exchanges, and their FEA categorization and metrics as depicted in the
Business Architecture are representative of the business goals, the
Business Architecture is said to be 'correct'. When the Business
Architecture provides this level of role decomposition, information
exchange, and FEA annotations that have been validated by authoritative
business SME's across all of GSA's lines of business and functional
segments, the Business Architecture is said to be 'complete'.

##### SME Validation

To the extent that the Business Architecture or functional segments are
complete and correct, the Business Architecture can be used to automate
the contribution to EA and FEA related sections of Exhibit 300's and
support Capital Planning and budgetary management procedures. Where
there are duplicative Investment Endpoints, a redundancy analysis is
suggested and should be examined for potential consolidation in order to
reduce O&M costs. Where Service Endpoints are described with no
sufficient existing Investment Endpoint, a DM&E effort is suggested, and
should be used to guide a Program initiative that will either buy or
build a realization of the target Service Endpoint. The set of
identified duplicative Investment Endpoints or unrealized Service
Endpoints should be analyzed in order to create a Sequence Plan that
prioritizes resource allocation and scheduling of Program initiatives.

##### Portfolio Management as Resource Rationalization

With this approach to completeness and correctness of the target
Business Architecture with an enterprise wide (One GSA EA) scope, from
the perspective of OMB, all of the Agency wide resource rationalization
requirements of an Enterprise Architecture Program have been met, and
GSA will have achieved most of the requirements for the highest levels
of maturity using OMB, GAO, or any other maturity model, based on the
use of complete and correct segment coverage that can clearly be shown
to have driven results in budgetary resource rationalization and
infrastructure portfolio optimization. The resource rationalization and
infrastructure portfolio optimization may require further successive
refinements of the BA in order to fully understand the capabilities of
Investment Endpoints or Target Endpoints. We may require more detailed
understanding of existing systems, COTS applications, or service
specifications in order to move from the inception that guides a
transition plan, to an elaboration that guides a sequence plan. A
transition plan helps GSA understand 'what' systems need elaboration,
based on alignment with the BA. A sequence plan is used when we know
'how' to execute a DM&E effort that becomes a Program initiative, either
to enhance an existing system in our portfolio or to develop
specifications of services to acquire. The Reference Architecture
process is the elaboration of the BA, described next.

#### Reference Architecture

Reference Architectures (RA) describe the logical relationship between
individual services in a SOA Framework. The way in which business
services require interactions with 'enabling' and 'infrastructure'
services are given as best practice blueprints in a RA specification.
This is a key pursuit to institutionalizing uniformity of
interoperability principles, where each and every business service will
need to utilize common capabilities.

##### Patterns and Blueprints

Reference Architecture is a logical model of a software system that can
realize the business operational functionality described by the Business
Architecture. Reference Architecture produces specifications of software
components that help fulfill the service contracts defined in the
Business Architecture. The focus of RA is to define patterns as best
practice solutions to recurring requirements of service specifications
and their software component implementations, usually with respect to
distributed computing paradigms, like 3 Tier, N Tier, Peer to Peer and
Grid computing. An opus of design patterns are well known in distributed
object computing and the 3 Tier engineering discipline, and are often
employed by mature practitioners in GSA software development or
integration initiatives.

Identity, Security, Privacy are just some of the common, cross cutting
concerns of any business service that should be addressed by RA
blueprints. GSA needs to have a consistent, shared and integrated view
of the relationship between entities defined in each of the; federal
Information Systems Security Line of Business (ISS-LOB), the FEA
Security Profile, the GSA Identity Management and Single Sign On
infrastructure, eAuthentication, NIST standards like FISMA and FIPS and
HSPD-12. An RA blueprint will enable GSA to unify how it will provide or
consume these services intra and inter Agency, and describes how they
should be discovered and bound to by business services.

The problem for GSA to solve with respect to enterprise wide
development, use and sharing of RA blueprints is how to harmonize
isolated organizational design and development practices such that a
knowledgebase is co-evolved by all the practitioners. Most often
however, the specification of a software component for a desired service
capability begins directly with the platform technology, since the basic
procurement approach at GSA and in the Government in general incorrectly
asserts that a technology selection will have already been done, based
solely on the natural language specification of functional and
non-functional desired capabilities, which typically won't include
either an enterprise wide or single application scope of contextual
interdependencies specified. When this happens, there is no opportunity
to assert the best practice patterns for developing software outside the
discipline brought by the individual practitioner. This individual
software system architect/designer, usually a contractor from a systems
integration vendor, may or may not bring personal or corporate best
practices to the government implementation. GSA currently makes this
capability maturity type of effort only within a line of business that
may or may not have a consistent technical support team, which can
optimally only enable silo implementations of best practices, and at
worst systemically lock in a vendor and create a barrier to exit for a
business organization.

GSA has no personnel or cross organizational effort to address the
issues of a lack of having a Reference Architecture that addresses best
practice software implementations across SOA frameworks or SOI
infrastructure. It is useful to contrast this with any organization that
routinely performs systems integration, as these organizations can only
develop their internal practices by creating Reference Architecture
frameworks, so that they can reuse their own intellectual capital across
their client engagements without dependencies on individuals to achieve
economies of scale and increase their bottom line. These RA frameworks
will address common computing requirements and provide solutions for use
in procurement that will either guide development or be used as a basis
for examining COTS features and functionality. GSA needs to harmonize
the tools and techniques of how software gets analyzed for purchase or
development, and begin with model driven principles above the level of a
particular platform or software solution. In doing so, GSA should
address the discipline of sharing logical systems assets across the
enterprise.

As an example, the manner in which a relational database is accessed
will largely be based on the same best practices regardless of the
business application, and indeed will often be the same type of business
application and identical relational database platform. Prior to service
orientation, this level of design and development discipline was the
sole focus of 'component' reuse, and there are reasonable economies of
scale to be realized here without much debate on principle. For example,
the relationship of a custom client or Web client and its implementation
of how information is accessed and displayed independent of interface
control behavior is an area where low level software component reuse can
take place without regard to any apriori understanding of specific
business application functionality. The same can be said for exposing or
retrieving data from legacy resources or relational operational stores,
there are simply best practice approaches that should be consistent
across GSA and support contractor implementations.

The biggest challenge for GSA to achieve this level of utility in a
Reference Architecture is a human capital challenge, since our emphasis
is usually only on Project Management skills, and the knowledge of basic
software discipline is usually external to GSA program initiatives, with
some notable exceptions that are inconsistent across the enterprise. The
next biggest challenge is creating a collaborative partnership across
currently isolated and autonomous operating units in GSA in order to
achieve a useful RA that has a traceable relationship to the BA.

##### Infrastructure and Mission Enabling Services

Services that expose data from operational data stores are one of the
most basic steps to take towards service orientation and the flexibility
resulting from composite applications. The Reference Architecture should
show how operational data stores share, use, manage and own data across
the organization. Understanding how that data is aggregated from the
many operational data stores into an information model used to create
the message payloads for business transactions in the Business
Architecture domain services is the primary goal. This will drive
clarity around problems of redundancy and integrity of data by requiring
that both the provenance and lifecycle of data be understood across the
organization in the context of business operations. Other value added
services will have immediate value once data services are available,
such as data searching, aggregation, transformation or message
translation services, perhaps even those that adapt transport protocols
while providing data services described above.

A Service Registry and Repository are basic infrastructure services.
These can be used to facilitate the discovery and use of domain enabling
services, such as the data related services described above. Any service
that facilitates a non-functional capability might be categorized as a
core infrastructure or domain enabling service. Content, document or
records management service implementations might all have endpoints
exposed in a registry service that can be bound to and executed
regardless of the specific business operational context.

A Service Repository is one where the functionality of service
realizations can be made directly accessible for use in a new deployment
infrastructure that might extend or enhance GSA's existing global
compute infrastructure. Normally, a Service Repository will contain the
actual implementation code and related source artifacts, or a binary
component realization of the service under lifecycle management within
the Repository that may be directly deployed to an either existing or
newly established computing node on the ESB. ESB computing engines
themselves, previously described as service host containers that are
instances of (SCA/JBI or other) standards based computing platforms, may
be accessed from a Service Repository and stood up in some network
environment in order to augment existing nodes on the ESB.

##### Generalization/Specialization Framework

GSA lines of business need to show how their business operations and
supporting IT infrastructure aligns with the Business Architecture. A
Work Role described in the Business Architecture will be realized by
software components that must implement the service contract defined by
the Business Architecture, including the workflow of Activities and Sub
Activities that the Work Role is responsible for in providing the
business service. The realization of a Work Role will require the use of
other domain services, other domain enabling services, and other core
infrastructure services. Transformation and adaptation services will be
common in the realization of these service compositions. A set of Work
Role implementations, each using a set of supporting services, will then
contribute to the composite application as described by the Business
Architecture. The ability for GSA lines of business and regions to
produce specializations that realize the Business Architecture services
provides the flexibility to support the unique functionality that may be
required in a localized business community.

#### Solution Architecture

Solution Architecture models exactly how existing or planned systems
will implement the Reference Architecture, which is a set of models used
to describe the logical software specifications that realize the
Business Architecture. Solutions that intend to leverage existing custom
business systems infrastructure require that their documented business
service (the BA and RA assets that they are refinements or elaborations
of) and logical component functionality are sufficient to serve as a
foundation for analyzing the fitness of the system to the target service
and the supporting components it requires. Solutions that are intended
to be developed on mature enterprise computing platforms must take into
account the well known design patterns that are specific to that
platform, which are published by the platform technology company.

Using the Java Enterprise platform, GSA's current 'enterprise
middleware' standards as per the ITAPC, any visualization, domain,
domain enabling or core infrastructure service has a concrete
realization best practice for 3 tier or N tier computing, known in the
Java development community as 'blueprints'. These blueprints describe
the patterns and provide design solutions for functionality that
implements a Reference Architecture specification as a Solution
Architecture specific to the Java Enterprise platform. The solutions are
given as platform specific models, and code samples.

##### COTS Map/Gap

Analyzing potential GOTS or COTS as a SA to a business service is
facilitated either by the BA or the RA, or both. A thorough 'build or
buy' analysis will most often want to be based on a complete and correct
BA and RA. Basic modernization criterion is the capability of COTS or
GOTS to be 'SOA enabled', in that the solution offers discrete business
service granularity that may be used in composite applications that are
not directly part of the packaged product, ala the mashups previously
described. Given that SOA is a relatively new paradigm within the
government marketplace of vendors, their domain oriented solutions are
often not SOA enabled. This is often the case especially when the vendor
implementation dominates the market share of a particular computing
domain, such as Enterprise Resource Planning, Financial Management,
Acquisition related Contract Writing Systems, etc. If an alignment is
shown to be sufficient using existing systems (COTS or GOTS) and the
desire is the leverage that Investment Endpoint, then the process of
understanding how to 'wrap and adapt' that system for use in SOA
composite applications will require a thoroughly complete and correct BA
and RA, for comparison against the promise made by vendors with
proprietary systems that cannot or will not provide SA models or
documentation other than low level API's that are significantly more
fine grained than the desire business service functionality of a BA or
even the logical view from an RA.

In some cases, techniques from the mature 'legacy transformation'
community will need to be applied, such as the bottom up systems
analysis techniques referred to as Architecture Driven Modernization
(ADM). ADM tools can be used to help automate the understanding of a
codebase that created the legacy application, for understanding the call
and data flow of the software. The knowledge gained from these
techniques can then be analyzed with respect to the service contracts
and component dependencies described in the RA and BA, either for
migration to a new computing language and platform, or for understanding
how to aggregate low level functionality expressed by the vendor API's
into more course grained business functionality described in the desired
SOA design approach using BA and RA as described here.

##### Infrastructure Services

Infrastructure services are used by domain enabling services, from the
perspective of a SOA framework. Fortunately, most of what is required
here is given 'out of the box' by modern middleware platforms. For
example, the core capabilities of a Java or Windows application server,
having now evolved into a service host container, are often referred to
as providing 'container managed' capabilities, include managing;
transactions, the persistence of data, container clustering and
redundancy of business logic for fault-tolerance, security (including
authentication and authorization), messaging, logging, lifecycle
monitoring and management, and more. The challenge is to maintain this
level of managed control across all computing nodes as a composite
applications traverses the Internet, moving in and out of multiple and
likely heterogeneous engines (service host containers) that constitute
the topology of the ESB. This means that we need to be able to
externalize some or all of the functionality that service host
containers provide, as services that support End to End transactions for
participation in composite applications.

The goal of eAuthentication can be seen in exactly this light, the idea
being to provide an authentication service that is independent of any
particular application, but can provide authentication services for any
application. The eAuthentication service itself will be deployed to a
service host container, but used in conjunction with other related
services likely deployed in other containers, such as policy decision
and enforcement points required for access to a data or domain service.
This may appear to add tremendous complexity given the machine to
machine coordination required, until we remember that the
interoperability of any service participating in a composite application
flow is always predicated on the explicit contract of that service,
including the human and machine readable business policies and technical
service level agreements. This is another way of saying that to the ESB
that is made up of computing nodes that are service host containers, a
service is a service is a service, regardless of whether it is a core
infrastructure service, a domain enabling service, a domain service, or
a visualization service. Everything is normalized and enabled by the
contract specifications of any service, as is the orchestration of
services in a composite application.

The choice of considering the SOA framework categorization of services
is one to be derived by consensus leading to convention within an
organizational practice. Whether or not an eAuthentication service is
seen as a domain enabling service or a core infrastructure service is
arguable, and the same can be said of other services described from the
list of container managed capabilities above.

##### Certification & Accreditation (C&A) Boundary

When we reach the solution architecture, we know exactly which systems
and services are contributing to the community of interest that any
given composite application supports. Where the BA defines the
conceptual C&A boundary, the RA defines the logical C&A boundary, and
the SA establishes the physical C&E boundary of G2G/G2C/G2B composite
applications. To the extent that all contributing systems and services
fulfill the requisite Enterprise QoS concerns, we can prove viability of
the C&A assessments and have a precise understanding of the requirements
for testing and verify those assessments can be successfully fulfilled.

#### Reference Implementations

Reference Implementations are Investment Endpoints that have known
traceability through the lowest level to the highest level architecture
assets. RI's may be realizations of services in any SOA Framework layer.
A RI has been through the portfolio resource rationalization process,
and is an investment that has a well understood and agreed to O&M plan
consistent with the Agency wide sequence plan that guides resource
allocations and budgets for program initiatives. A RI is one that will
be given first consideration in subsequent definitions of new composite
applications that require the functionality provided by the RI, and can
either be directly reused as currently deployed, or can be stood up in
supplemental service host container on any computing node of the ESB. Of
the latter, open source RI's will have the most freedom to be resident
in a Service Repository for instantiation on any available hardware. A
RI will be used in a specialization context, where existing
functionality is augmented for a unique business need, and as such will
be returned to the Service Registry as another RI (where not restricted
by licensing, lack of source code, etc.). Architecture as a practice
discipline doesn't make the decision of whether or not a RI investment
is authorized. Architecture can only provide a means for the qualitative
assessment of existing Investment Endpoint viability and target Service
Endpoint functionality. The decision is a strategic, capital planning
requirement of Executive Management.

##### System Verification

A RI has successfully passed a test suite associated with the various
functional requirements and non-functional (purely technical
requirements) BA, RA, and SA refinements. The SA set of platform
specific components used to implement the RA specifications that realize
the BA service orientation that achieve test suite success are said to
verify the RI, just as the business analyst and domain subject matter
experts were said to validate the BA. With the proper emphasis on the
User Experience, and possible exploitation of the client services
platform approached described herein, User Acceptance Testing (UAT) is
also successful. At this point, we have complete closure and confidence
that the system has met the technical needs of the ESB/SOI
infrastructure and the functional needs of the business stakeholders.

To facilitate the continuous improvement of GSA's portfolio of RI, a
persistent test domain for any service should be maintained by the
service owner or operator, enabling testing of their services by other
parties who may be creating composite applications. In this way,
existing services can always be tested for potentially new
implementations of business operations with other, external services not
originally designed as part of the functional or non functional
requirements. This is they key to leveraging service oriented reuse, and
a unique leverage point within the SOA paradigm, since the N-tier nature
of the service design is expressly concerned with independent
deployment, or loose coupling of service implementations. The
conventional use of a service framework, along with an understanding of
what BA, RA, SA and RI artifacts can be found in a Service Registry and
Repository, along with the persistently available test domains, enable
'test driven' service based procurement.

## Business Activity Monitoring

Business Activity Monitoring (BAM) is simply the ability to observe the
information flow across deployed services on the ESB. BAM is a
fundamental idea in BPM as a management theory, and the key
characteristic of the Real-time Enterprise. With the ESB established as
a flexible composition of computing nodes made up of service host
containers, the RTE is one that continuously monitors and optimizes the
efficiency and effectiveness of the information flow across the
composite applications that operate the business. This section explores
how the idea of Business Activity Monitoring enabled by SOI forms the
foundation of Business Intelligence. Given that the choreography of
business transactions and systems interactions has been architected,
this observational technique solves well known GSA problems like
'Unfilled Customer Order' as a side effect.

### Business Intelligence

The use of enterprise data warehouses, data marts, and associated
Extraction, Transformation and Load (ETL) processes are built into the
business transaction models themselves. The Business Architecture
describes when real-time information capture occurs, exactly what
information gets captured, and the purpose of the capture. Business
transactions will likely be analyzed for determining the state of a
process for regulatory compliance, for auditable events, public records
archiving, and for assimilation into aggregated knowledge stores such as
data marts or warehouses for time slicing business intelligence.

### Activity Based Costing 

When the compute nodes are known to host RI's of services with explicit
traceability to the activities of the BA, Business Activity Monitoring
(BAM) can be used to provide a direct observation of Activity Based
Costing predictions, because ABC are described by the BA. In this
fashion, ABC is not just a timesheet exercise; it is a literal decision
support system that will show a direct correlation between the human
capital and information technology infrastructure 'workload' and its
support of top line revenue and bottom line margin generation by the
work that has been done, not by what is said to be done. There is a thin
line between enabling this capability and what is required for most
non-repudiation audit scenarios for regulatory compliance.

### Regulatory Compliance

With an established collaborative information model that defines the
business transactions across operational workflows from internal white
box and partner black box implementations, the ability to capture
information state in the context of a business process playbook forms
the basis for understanding when various compliance checks are required.
In this case, there is no technical difference between a business
transaction that reached a state that must produce a public record that
will need to consume an archiving service, or the incursion of a fine
that will consume an alerting service that will notify an official.

Since the business transaction payloads are the business documents, the
use of document repositories are again no different than repositories
that maintain the state of a business process, which is made up of
numerous business transactions. The format of a 'document' is only
meaningful to the human user as an interface to the information, not the
state of the information in the process itself. The point is to manage
the information within the context of the business process, not
documents. This interface can be created as needed for human
consumption, but shouldn't be done in a way that makes the information
content inaccessible to other Business Intelligence activities that will
operate on that data.

## Disruptive Technologies

In any IT strategic plan, one objective is to survey the technologies
and capabilities that may impact the way that infrastructure is
conceived of, perhaps transforming our perspectives of how design,
development and deployment are pursued most efficiently and effectively.
Certainly SOA, SOI, and Web based P2P computing have already been
established and made a disruptive impact on the topology of computing
infrastructures, and are now firmly established in enterprise computing
pursuits, regardless of the speed of implementation in government and
its lag behind industry. Based on the acceptance of these ideas, we turn
our focus to two other significant technologies fixed at the 'tipping
point' of industrial innovation and acceptance as disruptive aspects of
enterprise computing, Open Source and the Semantic Web.

### Open Source

Open Source Software (OSS) is a commoditization driver in the software
marketplace at large. Beginning with the operating system, mature Open
Source technologies now exist in the enterprise middleware space that
implement mature enterprise middleware platforms such as Java. The
increased awareness of this trend in the software marketplace is pushing
the business model into 'software as a service', rather than software as
a product. The product is a commodity that is most often freely
downloadable and distributable. It is the effective use of these Open
Source products, including the training, support and consulting for
software specialization that is monetized. When a market segment is
dominated by a particular vendor, competitive OSS products inevitably
emerge to erode the market share using this innovative business model.

Numerous examples of this have played out over the past few years, with
Red Hat and their recent acquisition of JBoss as a significant example.
Red Hat took advantage of the OSS movement that created the Linux
operating system, and became a dominant Linux 'distributor', primarily
based on the services and support business model, with relatively
insignificant software fees. The purchase price of their version of
Linux is seen more as a value added packaging of what a user could
actually do themselves for free. The price of the software then is more
of a convenience fee, allowing purchasers to quickly make use of the
aggregated and integrated a set of 'value added' software in addition to
the core Linux kernel. This business model is widely acknowledged as
creating a software market, while simultaneously challenging Microsoft
as the dominant operating systems vendor. By commoditizing the operating
system, Red Hat gained market share.

A similar story happened with JBoss, where an open source certified Java
middleware suite was made available free for download and use. Over the
years, millions of developers downloaded and used the JBoss middleware,
because it worked, and it was free. There was no 'barrier to entry', and
the fact that this application server worked, and allowed companies to
not incur the cost of development licenses from commercial providers,
quickly became a common practice for systems integrators. Meanwhile,
thousands of individuals in a global JBoss community of interest
contributed to the maturity of the software, and after a short while (a
few years), companies began using it in production in order to avoid
expensive fees of closed source vendors of Java platform software. A few
short years later, JBoss was a disruptive force in the Java application
server and middleware marketplace, with an established business model
based on training, support and consulting. JBoss was acquired by Red Hat
for \~\$400M in 2006, and the combined operating system and middleware
software suites with their continued service oriented business model
continues to erode the market share of larger operating system and Java
middleware vendors alike, and contributes to Red Hat's \~\$4B market
capitalization. The lifecycle briefly depicted here is a common story in
open source successes.

More important than low 'barriers to entry', Open Source technologies
are disruptive because the have no inherent 'barriers to exit', meaning
that organizations utilizing Open Source technologies have full control
over the lifecycle of continuous improvement of their software based
infrastructure, as opposed to the proprietary or closed source software
vendors. Most mature Open Source solutions are COTS solutions, with
significant representation in almost every aspect of enterprise
computing market segments, including but not limited to; ERP, CRM, BI,
ECM, etc. Operating systems and desktop productivity suites also have
well known, mature, and professionally supported systems, notably the
many flavors of Linux (such as Redhat) and the Open Office suite, which
has a number of commercial implementations. Companies that produce
enterprise Open Source software can maintain their intellectual property
through copyrights associated with various styles of licensing. The OSS
paradigm therefore better supports companies that make software,
allowing them to enter markets they would otherwise be excluded from,
and supports end user companies through the enhanced visibility and
control, a truly 'win-win' scenario.

GSA should closely examine this desktop and enterprise computing trend
from a number of different perspectives. The application of OSS is
likely to be proven 'best value' in a number of GSA and Enterprise
Computing scenarios, including but not limited to: the licensing costs
inherent in 'wrapping and adapting' systems in our existing portfolio,
the ability to consolidate the skills and training of human capital, the
ability to support the principle of 'design locally, deploy globally',
the flexibility for scale invariance across engines corresponding to
required functional and non-functional requirements on the ESB, the
ability to populate Service Repositories with services and the
supporting engines themselves, and in desktop computing scenarios that
leverage role driven widget compositions' of rich client services
platforms. Fundamentally, GSA should give OSS a close look for best
value and lowest cost in every aspect of portfolio resource
rationalization and enterprise computing today.

### Semantic Web

The Web was originally disruptive in business computing because of its
ubiquity, in large part fueled by free OSS Web servers and browsers like
Apache HTTPD and Mozilla. In addition, the simplicity and human
accessibility of the Web technologies made them instantly accessible to
information technology workers. Pretty much anyone could create a Web
page, because it was so simple. Businesses embraced the Web because it
was an inexpensive way to publish information to prospective end users
and customers, much less so than traditional publishing and advertising
media. The Web was largely about humans reading Web pages, and
discovering information of interest in a proactive way, rather than
reactive to what they saw or heard through traditional communication
channels. The business model coupling search and advertising was born
and created fortunes for many. Search engines weren't necessarily
'smart', they were just brute force indexing engines that were initially
driven only by keywords, and really only by lexical character encodings,
there wasn't really any sense of what the word was or meant.
Sophisticated schemes followed, and today, the average information
worker and citizen use these capabilities routinely.

The Semantic Web takes this human readable Web and makes a machine
readable knowledgebase out of it, again based on simple and accessible
open standards that can be used to create relationships of information
beyond the simple hyperlinking of the human readable and navigable Web.
People use a simple assertion grammar to associate properties with
information on the Web in a machine readable and interpretable format,
the basis of which is Resource Description Framework (RDF). While HTML
is an executable information asset, its structure is display centric, as
it was originally only intended to be executed in a Web browser, which
is a software applications that assumes there is a human that will read
what the browser renders from the HTML markup. RDF, like HTML, is simple
to create and use, however this executable markup enables software to
combine the information independently from how it was originally
published.

The following are excerpts and edits taken from the Wikipedia entry for
the Semantic Web (found here http://en.wikipedia.org/wiki/Semantic_Web):
"RDF is a simple data model for referring to objects, or 'resources' and
how they are related. An RDF-based model is most often represented in
XML syntax. RDF Schema is a vocabulary for describing properties and
classes of RDF resources, with a semantics for
generalization-hierarchies of such properties and classes. OWL adds more
vocabulary for describing properties and classes: among others,
relations between classes (e.g. disjointness), cardinality (e.g.
\"exactly one\"), equality, richer typing of properties and
characteristics of properties (e.g. symmetry), and enumerated classes.
The intent is to enhance the usability and usefulness of the Web and its
interconnected resources."

The recommendation for GSA is to pursue the use of Semantic Web
technologies, as they will help to integrate disparate information
sources derived from community of interest vocabularies. More
importantly, business policies can be expressed using Semantic Web
standards, and this enables 'agents' to mediate service provider
capabilities and service consumer requirements at design and runtime.

# Business Opportunities

This section explores business opportunities that arise from
establishing executable and traceable architecture and supporting
service oriented infrastructure as described in this document.
Continuing with GSA's business model legacy, this approach enables a
number of mediation services, each capabilities of the real-time
enterprise.

## FAB, FAM, and Mediation Services

The Federal Acquisition Bus (FAB) is the GSA branded instantiations of
an ESB as described herein, the virtual topology of interoperable
service host container deployments on the Web. To complement the FAB,
real-time observations of business transactions that form the foundation
of business intelligence and decision support using Business Activity
Monitoring, is referred to as the Federal Acquisition Monitor (FAM).
Mediation services are themselves an opportunity and those that provide
Identity, Security and Privacy capabilities are of the most interest and
demand from the marketplace that is forming around the establishment of
eGov and Federal LoB's that are composite applications leveraging SOA
and SOI. By understanding the relationship, GSA will be able to
capitalize on the federated development and consolidated deployment of
services based on uniformity of the underlying FAB infrastructure and
its FAM and Mediation Service capabilities. The realization of the FAB
and FAM will be key differentiators for GSA in the shared services
future of the federal enterprise, and forms the foundation for value
added Mediation Services that themselves are deployed, managed and
monitored by the FAB and FAM.

### Mediation Services

The basic service model of a mediator service is a broker of some sort,
consistent with GSA's basic business model today. Composite applications
and the services provided and consumed therein will require numerous
brokered 'middleman' services. Many of these are already described in
the SOA literature, such as the 'mission enabling' services in the DNI
SOA RM, or discussed above. eAuthentication is a mediation service. The
entire Enterprise Information Integration market segment can be seen as
a set of mediation services related to data transformation and the
services called to enact these transformations.

#### Recommenders and Ratings

A Service Registry containing service contracts that are executable
artifacts including interface specifications, business policies and
service level agreements enables a human to examine these assets in
order to create composite applications, by matching service provider
capabilities with service consumer requirements.

If the artifacts are designed using a known syntactic formalism that is
semantically grounded, automated agents may infer an appropriate
composition of service providers and consumers. In this way, when users
either publish service consumer requirements or attempt to find provider
capabilities of interest, software agents can facilitate the discovery.
This idea is similar to the user preference, profile and product
categorization driven 'recommender' system on popular Web sites such as
Netflix for movies, or Amazon for books. These sites use genres and
commercial taxonomies of products, in addition to autonomous or
identified user profile and comment linking. Given a Business
Architecture that describes a desired community of interest, a
recommender system for composite applications would return existing
service provider and consumer contracts from the Service Registry. Using
continuous observation and Business Activity Monitoring (BAM), the
successful fulfillment of service responsibilities generates a service
reputation. This reputation can be used in a feedback loop with the
Service Registry, such that a service recommendation will be ranked by
rating.

#### Stateful Process Services

One obvious gap that will soon be filled in the Web Service
orchestration standards and implementations like Web Service Business
Process Execution Language (WS-BPEL) is the overall choreography view as
presented by the emerging W3C standard Web Services Choreography
Description Language (WS-CDL). Where BPEL describes 'my (enterprise)
role' as a white box, and 'my (other enterprise) partner' role as a
black box (which may also be a BPEL orchestration), CDL describes the
choreography across the collaborative role interactions in their
entirety. This forms an interesting basis for BAM and thus FAM mediation
services, and the implementation of CDL might include the ability for a
service provider or consumer to register their (BPEL or Web Service
implementation) with a 'choreographer' service, so that other FAM
related value added observation and alerting services might be made
available to their interactive context.

#### Semantic Mediation Services

The Federal Enterprise Architecture Reference Model Ontology (FEA-RMO)
is a domain specific ontology of the Federal Enterprise Architecture
(FEA) reference models. FEA-RMO directly translates the Performance,
Business, Service Component, and Technical reference models into their
executable representation in OWL-DL. FEA-RMO\'s design was driven by
principles of parsimony, simplicity, and utility. To ensure parsimony in
the ontology, the OSERA project included only terms and concepts defined
in the reference models. FEA-RMO has been used with an axiomatic bridge
demonstrating how shared concepts, their symbols, and mappings support
standardizing linkages between DoD and FEA architecture frameworks,
demonstrating a Semantic Application Inferencing Layer (SAIL)
application, which is a more sophisticated example of semantic mediation
service opportunities.

#### Autonomic Configuration Services

Any of the Enterprise QoS and End to End transaction services are viable
mediation service opportunities. A Service Registry and Repository are
also viable fee for service based mediation services. One of the most
compelling areas of service mediation is in the role of Policy
mediation. Policies can be business, technical, or citizen-centric. The
OSERA Policy Engine work uses Semantic Web ontologies building on
FEA-RMO to analyze WS-Policy security and reliability requirements upon
service provider/consumer interaction request. SOAP headers are then
populated with required WS-Security and WS-Reliability statements for
mutual policy compliant interactions. The OSERA Policy Engine
architecture proposes an interaction model for service providers and
consumers that serves as a foundation for the collection, use,
maintenance, and dissemination of private information based on defined
policies and preferences. The US Privacy Act ontology provides for
inferencing allowed disclosures based on disclosure target,
authorization, and intent. The privacy ontology also provides for
inferencing on denied requests and disclosure accounting.

## Federal Lines of Business and eGov Initiatives

OMB requires Agencies to specify plans to become a provider (shared
service provider center of excellence) or a consumer of eGov and Federal
Line of Business Initiatives. GSA needs to develop an integrated
business and logical systems view of all federal LOB initiatives and of
GSA\'s relationship to those initiatives as a shared services provider
or consumer. This expression is a required Enterprise Architecture
deliverable as part of the Federal Transition Framework.

Examples of established eGov and Federal LOB initiatives are HR,
eTravel, ePayroll, Financial Management, Records Management, and
Budgeting; examples of new federal LOB initiatives (which will require
development of strategic, tactical, and transition service provider
consumer plans) include Infrastructure and at some point will likely
include Acquisition. GSA must analyze the confluence of market
opportunities for shared services and GSA\'s position and readiness to
provide or consume those services, paying close attention to
organizational design and policy alignment to optimize executive
decisions. With integrated business and logical architectural views, GSA
will be better able to manage these enterprise-wide initiatives and make
more effective and efficient use of the GSA IT portfolio to support the
SSOs in accomplishing GSA\'s modernization strategy and either providing
LoB services to the Federal community or outsourcing them from the
community.

There is a 'network effect' in the pursuit of Federal Lines of Business.
If GSA was to pursue becoming and Infrastructure LoB, then the
Application Hosting capability would be used to provide FMLoB, an
AcquisitionLoB, and any other service provider mission area that comes
along. It gets easier to deploy LoB services because existing
Infrastructure provided services are leveraged. The total cost of
ownership and return on investment to provide for uptime,
fault-tolerance and redundancy requirements for operating these lines of
business becomes the same operational consideration for Continuity of
Operations (COOP). Having COOP as part of Infrastructure applications
hosting provider service level agreement (SLA), or a hosted FMLoB
service SLA is either a consumer requirement or differentiates it from
other provider competitors. In this way, GSA customers pay for COOP and
the applications hosting infrastructure that GSA needs to provide them
services they also pay for.

### Financial Management

GSA has been designated a shared service provider for the federal
government's Financial Management Line of Business (FMLOB)---one of five
LOBs defined in the Federal Enterprise Architecture (FEA). GSA\'s FMLOB
initiative is an ongoing implementation of a full financial management
EA suite of services, which will enable GSA to deliver an efficient and
effective government-wide financial management solution---a solution
that will improve business performance and ensure integrity in the
accountability, financial controls, and mission effectiveness of GSA's
client agencies.

This EA initiative will focus on the development of specifications for
integrating GSA and client feeder systems with the OCFO FMLOB target
architecture. The initiative will include analysis of client-owned and
-operated FMLOB feeder systems and of deployed or planned GOTS/COTS
solutions to identify integration points commensurate with FMLOB
requirements and client modernization strategies. The outcome of this
effort will enable GSA executive steering bodies like the BSC and the
Information Technology Council (ITC) to make informed decisions
affecting enterprise resource rationalization and IT infrastructure
portfolio management. These bodies will direct resources based on their
prioritization of FMLOB feeder system interoperability requirements, in
accordance with GSA enterprise-wide program planning. Continuation of
this FMLOB architecture effort will enable GSA to optimize the quality
of its FMLOB services to its current and potential customers while
advancing GSA\'s position as a leading provider in the FMLOB community.

Through this initiative, GSA will provide technical consulting and
support to assist new customers with achieving integration and
interoperability with GSA\'s FMLOB solution. This effort requires
analysis of customers' feeder systems and their deployed or planned
GOTS/COTS solutions. This analysis will enable EAPMO to identify
integration points commensurate with the service composition
requirements and modernization strategies of the consumer organizations
that own and operate GSA FMLOB feeder systems. Once it has identified
those integration points, GSA can provide software tools and integration
services through its partners, in keeping with the GSA channel enabler
business value proposition. In addition, GSA will continue to refine the
FMLOB target and its integration with other LOB models, which will guide
GSA enterprise-wide program planning.

## Model Based Acquisition

The Federal Chief Information Officers Council (CIOC) Architecture and
Infrastructure Committee (AIC) has issues guidance in the 'Service and
Components Architecture' (SCBA) whitepaper for Federal Agencies to
pursue a 'service based procurement' procurement strategy. This is a
direct outgrowth of SOA, and reifies the understanding of an
'application' as a composition of services, usually composed in support
of a business process. The capabilities given by the Executable
Architecture methodology as briefly described in this document enable
this pursuit. By combining design concepts of SOA and M2I capabilities
that target SOI, the result is consistent with the BPM ideas of
continuous business process improvement, and agility in composition of
services that support those processes across changing partners.

Understanding the functional responsibility of the service that
participates in the business process enables the build or buy of that
service to be decoupled from the monolithic application suites that
currently dominate the IT infrastructures in Government Agencies. The
existing practice is proven to result in brittle integration and
interoperability that doesn't live up to the demands of Enterprise QoS
in eGov or Federal LoB interoperability.

## Dynamic Supply Chain Assembly and Optimization

The most basic business role for GSA to carry over into the suggested
modernized policy driven IT infrastructure remains consistent with our
heritage. GSA has a tremendous opportunity as a market maker and channel
enabler that brokers provider and consumer relationships inherent in
establishing and running composite applications. With an established FAB
and FAM Infrastructure, and associated Mediation Services as described,
the opportunity for GSA to monetize a role in the dynamic assembly of
interoperable Communities of Interest and Practice collaborations
represents a key strategic focus area.

This type of Semantic Mediation Service capability, when combined with
the Recommender and Ratings Services described as Infrastructure
Services in a SOA Framework and as Mediation Services above, are where
the significant middleman opportunities will be found, given a FAB RTE
infrastructure. They are implementations of 'autonomic computing', which
enables self configuring, healing, optimizing, and policy compliant
interoperability. The use of Mediation Services for value added
functionality in the collaborative role interactions of Dynamic Supply
Chain Brokering will be a growth business in SOI enabled eGov and
Federal LoB.

## Open Source eGov Reference Architecture

The Open Source eGov Reference Architecture (OSERA) is an example of a
cohesive approach to unifying design aspects of SOA and BPM with SOI
runtime environments using open source tools. The fundamental objective
of OSERA in support of the EA practice at GSA is to use and enhance
existing and freely available open source tools, to automate the
generation and deployment of service component choreographies that
implement business models described by OneGSA EA. This idea comes from
the MDA community, and this capability is often referred to as 'model to
integrate' (M2I).

The OSERA has demonstrated the M2I ability to generate IT infrastructure
assets (Web Service and Java code) required to realize integrated
Acquisition and FMLoB services directly from Business Architecture
assets, resulting in service choreographies deployed on free open source
(application server) software and commodity hardware runtime platforms.
COTS environments and platforms are pursuing this strategy in earnest,
and OSERA isn't exclusive to open source tools. Eclipse and JBoss
provide the foundation of OSERA open source tools, and are well
established as a disruptive forces with significant awareness and
penetration in the software industry, challenging existing 'best value'
propositions.

The combined effect of these IT Portfolio Management (ITPM) capabilities
could significantly enhance the efficiency and effectiveness of CPIC
efforts, and collapse the SDLC timelines across GSA business and
supporting IT initiatives, providing trace-ability from existing and
planned IT infrastructures to business requirements and outcomes,
implementing the OMB Federal Enterprise Architecture (FEA) Performance
Reference Model (PRM) 'Line of Sight'. ITPM as briefly described here is
a discipline that is not well understood, coordinated, or achieved
across our decentralized agency.

'Model Based Acquisition' is an important concept advancing Business and
IT alignment and agility, where the objective is to enable better IT
acquisitions planning and implementation through 'model to integrate'
capabilities. OSERA supports this value proposition and the standards
community by providing open source Reference Architectures and Reference
Implementations for communicating with service consumers and providers,
and can be extended to eGov specifications and realizations for the
Federal, State and Local governments at large. Implemented as GSA
managed Program and Platform, OSERA presents the most effective cost
savings and new business opportunities for GSA, consistent with our
existing business model as a market enabler and responsive to the Open
Technology Development goals of DoD. OSERA has generated partnership and
participation interest within DoD and their support contractors, as well
as GSA support contractors and systems integration partners, and can be
employed to enhance the GSA-DoD customer relationship management
strategies and tactics. The result is better resource rationalization of
existing and planned IT infrastructures can be traced to business
requirements and outcomes. This approach is a fundamental enabler of
test-driven services based procurement strategy guidelines issued by the
Federal CIO Council's Architecture and Infrastructure Committee
(CIOC-AIC) in version 3.5 of the Service Component Based Architecture
(SCBA).

GSA's augmentation of the basic tools and capabilities that make up the
OSERA platform is based on evolving OMB, FEA, and GSA requirements.
Those tools and capabilities include an Integrated Modeling Environment
(IME), a Meta Data Management (MDM) facility, a Business Process
Platform (BPP), and an Enterprise Service Bus (ESB). Implementation of
such tools and capabilities to consolidate individual One GSA EA models
will enable test-driven service based procurement. This environment---to
be established within the GSA OCIO Office of Enterprise Solutions,
Division of Enterprise Wide and Government Wide Applications---will
support existing and emerging federal LOB concerns from the perspectives
of both the customer and the solution provider. In addition, technical
service-level agreements and business policies will be enabled by OSERA
MDM and ESB capabilities to autonomically configure web services
security and privacy policies at run time. Those capabilities support
the Privacy Act of 1974 and the eAuthentication risk assurance levels
for human-to-machine and machine-to-machine G2B, G2C, and G2G eGov
interactions.

The larger Federal community goal of the Open Source eGov Reference
Architecture (OSERA) project is to serve as a catalyst to advance the
public/private partnership in the pursuit of enhanced G2G/G2B/G2C
interoperability, by enabling test driven service based procurement to
achieve large scale resource rationalization through Open Technology
Development. Based on the Executable Architecture (EA) methodology and
principles described herein, OSERA unifies the capabilities and
characteristics of Business Process Management (BPM) and Service
Oriented Architecture (SOA) using Model Driven Architecture (MDA) and
Semantic Web (RDF and OWL) technologies. OSERA is part of the GSA
architecture practice modernization to enable resource rationalization,
and as a strategic sourcing business opportunity that is a response to
market dynamics and capabilities desired by GSA's customers, notably
DoD.

GSA should sponsor the community evolution of the business principles
and technological foundations of the 3P\'s of OSERA; a managed Program,
a managed Platform, and managed Projects. OSERA Projects contribute to
OSERA Platform capabilities. Model to Integrate (M2I) Projects
demonstrate how service providers and consumers are composed into
multiparty collaborations, using open source and open standards based
design tools. Using these business service interaction models, Web
Services specifications are automatically generated and deployed to open
source and open standards based runtime platforms, using commodity
hardware and software. Semantic Interoperability Projects focus on
design and runtime knowledge management and information integration. The
OSERA Platform aggregates and enhances existing Integrated Modeling
Environment (IME), Metadata Management (MDM), Service Oriented
Infrastructure (SOI), and Business Process Platform (BPP) functionality
and provides cohesion across these open standards based and open source
tools.

# People and Process

## Reportable Conditions, Material Weakness, and Management Challenges

### Reportable Conditions:

Development, implementation, and change controls over GSA's financial
applications continue to need improvement. Since 1999, GSA has had a
reportable condition regarding the need to improve development,
implementation, and change controls over its financial applications.
During FY 2005, GSA made progress in addressing the issues raised in
prior years. Specifically, individual service lines had implemented a
number of corrective actions including the implementation of a new
configuration management tool that will assist in the tracking and
documentation of all application change requests from initiation to
completion.

Auditor testing has noted the following issues: System developers have
access to the production environment for Pegasys. Change control
policies, procedures and practices are not being followed for Pegasys.
System software change procedures for GSAP are not being followed. Seven
of the system software changes did not have the test plans and results
documented.

GSA needs to strengthen security controls. In prior years auditors
reported security weaknesses associated with FSS\' FMS and FSS-19
applications. FSS was able to fully or partially resolve some of the
issues by implementing corrective actions. However, based on current
year testing, auditors continued to note a number of security-related
weaknesses in several GSA systems that when taken together, constitute a
reportable condition for GSA. Specifically, weaknesses in the following
areas were identified: Completeness of security plan and certification
and accreditation. Password and security controls configuration,
separation of user and administrator duties, documentation, approval,
and recertification of user access, and application audit trails and
monitoring.

PBS Controls over transferring substantially complete construction in
process projects continue to need improvement. Since fiscal year 2001,
auditors have identified a reportable condition related to PBS not
performing timely transfer of construction, and major and minor repair
and alteration projects out of the construction in process (CIP) general
ledger accounts to the appropriate asset general ledger accounts upon
substantial completion, as well as not expensing items from CIP when a
project is abandoned, cancelled, or when the item does not meet the
definition of a capital asset*.* The classification of projects as CIP
or Property, Plant and Equipment (PP&E), is difficult and subjective,
especially for multi-phased projects which, in some cases, may require
the knowledge of an experienced Project Manager or specialist to make
the determination. Furthermore, the terms \"substantial completion\" and
\"multi-phased projects\" are not clearly defined, resulting in
different interpretations for similar projects amongst regions.

When a new CIP project is established, regional associates are expected
to enter all necessary information, including the expected date of
completion, into IRIS. This information allows PBS central office
personnel to monitor the status of construction projects. Once a project
is substantially complete, the project manager should enter the actual
substantial completion date in IRIS to allow for the transferring of the
project into the Real Property Accounting Depreciation System (RPADS),
which serves as the Federal Buildings Funds (FBF\'s) property subsidiary
ledger. If a project is abandoned or cancelled, the project manager
should transfer abandoned or cancelled project to expenses in a timely
manner. The transfer from the CIP account to the appropriate asset or
expense account is necessary for proper classification of the assets or
expenses in the financial statement as well as accurate and complete
reporting of depreciation expenses. Depreciation on substantially
complete CIP projects are not calculated and recorded until the asset is
transferred from CIP to the appropriate *asset* account.

PBS should implement effective preventative controls which detect and
correct errors in individual transactions and balances. Maintaining
accurate data in IRIS for CIP projects is necessary for PBS to generate
accurate financial information on a routine basis.

Contracting practices at the FTS continue to need improvement. In fiscal
year 2003, the GSA Office of Inspector General (OIG) performed an audit
of the procurement processes of FTS Client Support Centers (CSCs) to
determine if procurements were made in accordance with the Federal
Acquisition Regulations (FAR) and with the terms and conditions of the
contract utilized. The audit focused on the eleven CSCs, and identified
numerous instances of inappropriate contracting practices and two
violations of the Anti-Deficiency Act. PwC identified a reportable
condition in their fiscal year 2004 internal control report based on the
results of the OIG audit.

In a letter dated October 27, 2005, the GSA OIG communicated to GSA
management three matters involving possible infractions on the part of
GSA related to the Anti-deficiency Act (ADA) and Purpose Statute. In one
instance, CSC officials processed procurement transactions for real
property services through the ITF and the GSF that were well outside the
funds\' legislative authorized purposes, which are potentially in
non-compliance with the Purpose Statute. In another instance, GSA
contracted for services using client funds which may have been expired
and unavailable for obligation, which may result in an ADA violation. An
overarching issue was also identified pertaining to the inappropriate
accounting for and misapplication of customer funds over the course of
many prior financial reporting periods. The OIG further reported that
these potential ADA issues could be attributed to prior period
weaknesses in internal control, and that their most recent audit results
disclosed that FTS has made significant progress in the implementation
of new controls governing procurement activities through programs such
as the \"Get it Right\" plan. In PwC's fiscal year 2005 audit, auditors
did not find any instances where new acquisitions did not comply with
the new controls instituted by management.

Reconciliation of intergovernmental balances need improvement. In fiscal
year 2004, auditors reported that GSA did not reconcile its
non-fiduciary intra-governmental activities and balances because they
were unable to fully perform reconciliations of intra-governmental
activity and balances with their trading partners, for reasons such as:
(1) trading partners not providing needed data; (2) limitations and
incompatibility of agency and trading partner information systems; and
(3) lack of human resources. Interim testing related to the fiscal year
2005 audit, auditors noted the following: formal documented policies
regarding the preparation and review of the intra-governmental
reconciliation and IRAS reporting process had not been developed.

GSA did not report all required USSGL intra-governmental accounts during
quarterly IRAS reporting. GSA relies on the use of vendor codes and
vendor code attributes to compile information relating to
intra-governmental activity by trading partner. Extensive manual
workarounds and estimates are used to determine the breakout of revenue
and receivables for the Department of Defense.

Reconciling and confirming activity and balances quarterly with trading
partners will help GSA to resolve unidentified transactions and ensure
balances have been accurately and appropriately recorded. Additionally,
this reconciliation process will identify material out-of-balance
conditions between Federal entities, help to support an accurate
consolidation of GSA with the government-wide financial statements, and
ensure that intragovernmental balances properly eliminate in the
government-wide consolidated financial statements.

#### System Non-Conformance:

The FY 2005 management assurance process and financial statement audit
identified system-related issues regarding budgetary controls and
reporting processes reported in the Statement of Budgetary Resources and
Statement of Financing. These issues involved an inability on the part
of FTS, FSS, and PBS financial systems to adequately record and report
detailed budgetary transactions throughout the year in accordance with
Federal accounting standards and a continuing need to rely upon
time-consuming manual procedures to compensate for these financial
system deficiencies.

A number of actions will need to be carefully planned, coordinated, and
implemented to correct this system non-conformance, including the need
to improve the recording of detailed budgetary transactions and develop
and implement more effective and timely budgetary account
reconciliations between service financial systems and GSA\'s core
accounting system.

PwC test results also disclosed this situation and led PwC to note that
GSA's financial systems did not substantially comply with the Federal
financial management systems requirements of FFMIA.

### Material Weakness

PricewaterhouseCoopers (PwC) auditors identified a material weakness
concerning inadequate controls over monitoring, accounting, and
reporting of agency budgetary transactions. During their testing of
internal controls, PwC noted insufficient ongoing compliance with
control procedures instituted by management for specific GSA budgetary
accounts. Additionally, PwC noted that as a result of insufficient
monitoring controls over budgetary accounting, GSA did not return
spending authority to customer agencies for expired obligations and for
those instances in which bona fide need for unfilled customer orders
ceased to exist. Furthermore, PwC found that GSA did not adequately
record budgetary transactions throughout the year, and the core
financial system did not capture detailed transaction level information
for certain material budgetary account balances. In order to correct the
weakness, PwC is recommending that GSA:

Eliminate dependency on obtaining, analyzing and adjusting financial
information only at or near fiscal year end when staff resources are
strained.

Develop and document policies and procedures to prepare and monitor
budgetary accounting and reporting, which include supervisory reviews,
analytical procedures, and data validation, and ensure that activities
are in compliance with the applicable guidance.

Fully implement the budgetary functionality of the current financial
accounting system to ensure activity is recorded completely and
accurately.

lmprove its internal quality reviews and maintain evidence of monitoring
controls, specifically supervisory reviews on a quarterly basis, to
ensure compliance with laws and regulations and to validate the
presentation of the statement of budgetary resources and the financial
statements.

Use the opportunity of implementing OMB Circular A-123 during fiscal
year 2006 to identify root causes of budgetary reporting control
weaknesses across the breadth and depth of the financial reporting
process.

### Management Challenges

#### ACQUISITION PROGRAMS

Merging GSA's procurement organizations will yield a single acquisition
service awarding and administering government wide contracts worth \$40
to \$50 billion. With growing programs and shrinking numbers of
qualified acquisition personnel, attention to important fundamentals,
such as ensuring competition and meaningful price analysis, has
diminished.

#### CONTRACT MANAGEMENT 

GSA's multibillion dollar acquisition programs have expanded rapidly in
terms of sales, variety, and complexity of the procurements performed. A
growing list of warning signs throughout the acquisition process
suggests that the technical and management skills needed by the
procurement workforce to operate in this more sophisticated arena are
not keeping pace with these new demands.

#### INFORMATION TECHNOLOGY 

Technology applications have increased exponentially as "E-Gov" is used
to better manage operations and interface with the public, but complex
integration and security issues exist.

#### AGING FEDERAL BUILDINGS 

GSA is being challenged to provide quality space to Federal agencies
using an aging, deteriorating inventory of buildings and facing critical
budgetary limitations in its modernization program.

#### INTERNAL CONTROLS 

Internal controls have been streamlined, resulting in fewer and broader
controls, making it essential that the remaining controls be emphasized
and consistently followed. The need for strong internal controls
underlies several of the other management challenges.

#### PROTECTION OF FEDERAL FACILITIES AND PERSONNEL 

GSA is responsible for protecting the life and safety of employees and
public visitors in Federal buildings. The increased risks from terrorism
have greatly expanded the range of vulnerabilities. A broadly integrated
security program is required.

#### HUMAN CAPITAL 

GSA has an aging workforce and is facing significant loss of
institutional knowledge due to retirements, including a loss of key
management staff over the past year. Better recruitment and training
programs are needed to develop the 21st century workforce.

### Federal Acquisition Service, Public Building Service, and GM&A

### The 80/20 O&M/DM&E Problem

GSA's IT infrastructure has grown over the years without a common vision
of computing, and therefore quite naturally has evolved as independent
silos, or technology and information islands. One definition of the so
called '80-20' rule at GSA is that GSA spends 80% of its IT resources on
O&M, and 20% on DM&E. The problem is that our infrastructure has evolved
in a way that no longer effectively or efficiently supports integrated
business operations because of the complexity and cost of silo
integration. Evidence of this can be found in our shrinking market
segments, which is happening along side of increased competition and
product commoditization in the marketplace.

### Disintermediation

General areas of computing are often outsourcing targets within an
enterprise, such as financial management, human resources, order
management, etc. The interesting opportunity for GSA is that all of
these normally non mission critical or non differentiating services
become business opportunities for GSA, by the very nature of our
mission.

#### [[]{#__RefHeading___Toc148944441 .anchor}http://www.gcn.com/print/25_20/41341-1.html](http://www.gcn.com/print/25_20/41341-1.html)

Treasury Communications Enterprise contract---a 10-year, \$1 billion
telecommunications contract. \[Administrator Doan\] said Treasury should
seriously consider ending that procurement and taking telecom services
through GSA's massive Networx vehicle. NASA's Scientific and Engineering
Workstation Procurement and various Defense Department acquisitions such
as the Navy's Seaport-e and the Army's IT Enterprise Services-2.

# Tactical Recommendations

## Service Oriented Enterprise (SOE)

A Service Oriented Enterprise (SOE) is one that leverages SOA and the
supporting SOI for enterprise wide resource rationalization through
strategic planning operations and tactical program initiatives. GSA is
already service oriented from the perspective of our internal lines of
business *within* the Agency. GSA needs to become a SOE from the SOA and
SOI perspective *across* the Agency, embracing the 'software as a
service' paradigm that will enable growth as the entire Federal
Enterprise transitions to SOA, SOI, and SOE.

A SOE uniformly uses a consensus around best practice approach to SOA
and existing SOI infrastructure to develop a shared services management
strategy, where the organization on the whole follows design and runtime
principles and executes an enterprise wide sequence plan that drives
capital planning efforts and program initiatives to support existing and
planned business operations that rationalizes enterprise wide resources
by reallocating costs to create new top-line revenue or better profit
margins. This is a significant organizational culture and change
management challenge, in addition to requiring collaboration on the
design of service orientation and use of enterprise middleware plumbing
in our IT infrastructure to support composite applications.

SOE requires GSA to modernize our planning and budgeting operations and
management procedures in addition to our acquisition and procurement
policies and operations. The SOE is consistent with the guidance given
by the Federal CIO Council's Architecture and Infrastructure committee
in the Services and Component Based Architectures (SCBA, pronounced
'scuba') whitepaper and its call for 'service based procurement'. The
SOE is also consistent with what GSA's customers (notably DoD) are
calling for in their own procurement and engineering modernization
plans, such as those described in the Open Technology Development
Roadmap (OTD), in order to achieve Netcentric Enterprise Services (NCES)
and Information Sharing Environment initiatives.

### SOE Operational Model

GSA needs to establish policies that elaborate the roles and realigns
the responsibilities of SSO, GM&A, and intra-organizational groups (such
as BSC, EAPMO, ITC, ITAPC, ICB) that makes clear who is responsible for
depicting, directing, managing and maintaining a variety of aspects
related to overall IT governance and resource rationalization. We
believe that architecture layers (BA/RA/SA/RI) are reasonable ways to
divide and conquer these requirements.

#### BSC and EAPMO for BA

The Business Architecture, as described herein, provides a unified,
cohesive view of the Enterprise Mission, and how it will be realized
tactically by Business organizations. We believe that this can coincide
with a tight interaction of an EAPMO as directed by the BSC, which is
responsible for the overall efficiency and effectiveness of GSA's IT
Portfolio. The EAPMO provides the BSC the TCO and ROI analysis to enable
optimization decisions, and the BSC is responsible for strategic and
funding agreements across the Agency. Since the BA describes the
business process as a composition of services used by people and
supported by software components implemented on various technology
platforms, the focus is core operational standardization, SSO
specialization of those standard operations, and on the metrics that
make business outcomes measurable. The BSC owns service context,
boundary (business service interface) specifications, and service
orchestrations. The BSC enforces these metrics as linkages across the
other architecture layers as part of the responsibilities of other GSA
organizations, in order to maintain a metrics 'line of sight' from a
bottom to top (RI to SA to RA to BA). All of this should be enabled by
EAPMO work product.

The BSC must continue being sourced by (Deputy/Assistant) Service
Commissioners and GM&A IT Executives. The EAPMO must be sourced by
Business Line and Architecture SME. This is not the case today for the
EAPMO, at least not in any continuous or consistent fashion.

#### ITC, ITAPC and EAPMO for RA/SA

The ITC and ITAPC must be enhanced to include the stewardship of RA and
SA, with support from EAPMO. They must strive to create parity in IT
implementations across GSA and consolidate technology platforms wherever
possible, maintaining a decoupling (separation of concerns) and trace
ability across the RA and SA layers they steward. These two groups take
generic (WSDL) interface specifications that are platform and language
neutral, and maintain traceability to principles and patterns on any
target platform implementation realized by Reference Implementations
created by the SSO PMO's initiatives as authorized by the BSC.

#### SSO PMO for RI

The result of executing this proposed SOE operational model will be that
different technology profiles can exist across different organizational
profiles, but each will still contribute to the maturation of the
Enterprise, not just their respective Business Line. SSO PMO should be
unable to design or implement solutions outside the realm of BA
established Enterprise context and RA/SA/RI established best practices.

### Industry Standards

Given adoption of the Java Enterprise Platform as the enterprise
middleware standard at GSA, the industry standardization and
consolidation towards making heterogeneous product implementation of
these platforms more compatible and their assets more portable, and the
standardization of how to realize ESB functionality, GSA business
service infrastructure needs to shift to understanding SCA and JBI, and
focus more on principles and patterns of 'End to End' transactions and
other enterprise Quality of Service (QoS) concerns. End to end QoS
refers to the ability to move from external partner Web services through
internal service host container nodes on the ESB, while maintaining the
integrity of secure, reliable, asynchronous message transaction
choreographies across enterprise and geographic boundaries required by
disparate infrastructures supporting interacting value chain partners.

#### SCA

Enterprise middleware standards and platforms, including those adopted
through GSA's ITAPC 'Bricks' such as the J2EE (now JEE5) have
significant industry coalitions supporting SOA design for SOI
deployment. The Service Component Architecture (SCA) specification (see
osoa.org) is a partnership to enable existing Java application server
vendors to facilitate service interoperability and portability across
their proprietary implementations of the Java platform standards,
including IBM's WebSphere, Oracle's Fusion, BEA's Weblogic, Sun's Java
Enterprise System, Iona, Tibco, Progress, Redhat, SAP, Sybase, and many
others.

#### JBI

The principle trends in the Java platform are simplification of the
'Enterprise Java Bean' (EJB) component model, the ability to annotate
code for advanced service host container management, and the
standardization of Java Business Integration (JBI). Plain Old Java
Objects (POJO's) can now have declarative properties for container
managed transactions, security, persistence, and exposure as Web
services through a service container. JBI is perhaps the most important
Java Enterprise Platform standard, which describes the structure and
functionality of how a Java applications server becomes a service host
container, by defining how Service Engines, Service Assemblies, and
Binding Components interact with a Normalized Message Router to provide
ESB functionality. These innovations in the Java Enterprise Platform
standards significantly simplify the development and management of
enterprise services, and the meaning of ESB functionality. JBI enables a
service host container to be considered a computing node on the ESB,
which is made up of as many nodes as required for the IT infrastructure
to support the business operations.