Version1.1

From PGFSOA Wiki

Architecture and Infrastructure Committee, Federal Chief Information Officers Council

In collaboration with the

The American Council for Technology / Industry Advisory Council’s Enterprise Architecture Shared Interest Group (EA-SIG)

Presents:

A Practical Guide to Federal Service Oriented Architecture Version 1.1 Final: June 2008

---

Intended Audience

This document is intended for chief architects, chief information officers (CIOs), program executives, and other individuals in federal agencies who are responsible for leveraging information technology (IT) assets to assist in achieving maximum mission performance in pursuit of agency business objectives. The purpose of this document is to aid in understanding service oriented architecture (SOA) in its three major dimensions (enterprise, architecture, and infrastructure) and how these new service oriented best practices can be used to extend Enterprise Architecture, not replace it. This Guide provides specific guidance for adopting and exploiting this new paradigm for transforming business through agile, reusable, software development in conjunction with effective use of its supporting technology infrastructure.

Based on the information in this document, chief architects and CIOs can become leaders capable of developing and effectively explaining the SOA business case for business stakeholders to inform and guide them in understanding and supporting the investment philosophy they are being asked to champion. Leaders should be able to develop plans for implementing and exploiting a successful roadmap for SOA adoption, and leverage and shape ongoing development, modernization, and enhancement (DME) activities within their agency. In addition, individuals should be able to leverage, support, and use cross-boundary initiatives working with their peers in other agencies, in local, state, and tribal governments, as well as private sector partners.

Some of the guidance in this document is best described as a call to action for the Federal CIO community because it identifies specific areas where additional work or new cross-Government initiatives may be needed to further develop voluntary consensus standards or best practices. In keeping with a basic theme of this document -- that agencies and other stakeholders will come together via federated governance to act based on their common requirements and needs -- we expect this call to action and practical guidance to be the basis of informed decision-making, allowing Federal enterprise participants to have viable knowledge to support effective execution of investment strategies. As agencies evolve and mature their Service Orientation competencies and augment their EAs, the CIO Council will evaluate and facilitate SOA-enhanced EA based on the shared assessment of the requirements and needs.

Contents 1 Executive Summary 1.1 Rationale for SOA 1.2 Vision: Improving Services from Federal Agencies 1.3 Keys to Federal SOA Implementation 1.4 Roadmap for Federal SOA Implementation 2 Introduction [Document Section 1] 2.1 SOA Concepts 2.2 SOA Challenges 2.3 SOA and Enterprise Architecture 2.4 Organization of the Document 3 The Rationale for Federal SOA [Document Section 2] 3.1 Enhancing Mission Effectiveness 3.2 Continuous Innovative IT Asset Re-capitalization 3.3 Cross-Domain/Cross-Agency Trust, Data Access, and Semantic Interoperability 3.4 Leveraging IT Investments across Federal Agencies and Sharing Best Practices 4 Service Oriented Vision - The Target Architecture [Document Section 3] 4.1 Service-Oriented Enterprise (SOE) 4.1.1 Management, IT and Business are All Service Focused 4.1.2 Sustaining SOE through Federated Governance 4.1.3 Model Based Acquisition Processes 4.2 Service Oriented Architecture (SOA) 4.2.1 Federal SDLC and EA are Integrated and Support SOA 4.2.2 SOA and Interoperability Will be Well Established 4.2.3 Standard Federal Government Services Will Emerge 4.2.4 Model Driven Architecture Will Be Embraced 4.3 Service-Oriented Infrastructure 4.3.1 Service Management is Coordinated Throughout the Federal Government 4.3.2 Increased Collaboration with 3rd Parties 4.3.3 Tool sets to Manage the SOI 5 Keys to Federal SOA Implementation [Document Section 4] 5.1 Keys to Implementing the Service-Oriented Enterprise 5.1.1 Treat SOA Adoption as an Organizational Change Initiative 5.1.2 Obtain Executive Support 5.1.3 Establish a Program Plan for SOA and Measure Results 5.1.4 Establish an SOA Center of Excellence (COE) to Oversee Adoption 5.1.5 Appropriately Plan and Fund the Change Initiative 5.1.6 Build Community Processes and Collaborative Platforms 5.1.7 Establish Federated Governance 5.1.8 Provide Communities of Interest (COI) with Sufficient Funding 5.1.9 Create a Services Development, Test, and Evaluation (DT&E) Laboratory 5.1.10 Establish Service Funding and Charging Mechanisms 5.1.11 Use a Service-Based SDLC with Incremental Development Practices 5.1.12 Practice Service-Based Procurement 5.2 Keys to Implementing a Service-Oriented Architecture 5.2.1 Use EA and SOA to Align with Business Objectives 5.2.2 Introduce Services as a First-Order Concept in your EA 5.2.3 Establish a Service-Based Target Architecture 5.2.4 Adopt Model-Based Architecture and Pattern-Based Design 5.2.5 Enable Automated Compliance and Alignment 5.2.6 Leverage Legacy Assets to Enable Evolutionary Progress 5.3 Keys to Implementing the Service-Oriented Infrastructure 5.3.1 Focus on Enterprise Security, Scalability, and Interoperability 5.3.2 Establish Discovery and Trust Mechanisms 5.3.3 Establish an Adaptive and Collaborative Testing and Certification Environment 6 A Roadmap for SOA Adoption [Document Section 5] 6.1 SOA Maturity Stages 6.2 Establishing a Core SOA Team 6.3 SOA Roadmap Model 7 References

Executive Summary

The world is changing at an accelerating rate and the federal government needs to keep pace. Broad-based change is always difficult, but the federal government is plagued by a variety of inhibitors to change, including enterprise vs mission organizational orientation; bureaucratic culture; program aligned funding processes; budgetary cycles and processes that do not facilitate agility or reuse; and a very large and diverse embedded technology base. Service Oriented Architecture (SOA) promises to help agencies rapidly reconfigure their business and more easily position IT resources to serve it. Improved business agility – through the sharing and reuse of infrastructure, services, information, and solutions - is a key component of any Federal Enterprise Architecture whose need will become increasingly critical in the future.

These benefits have been promised in past waves of IT innovation. This time they are enabled by the concurrent maturation of Internet-based IT standards and best practices and the adoption of those interoperable standards as a common fabric by stakeholders – Citizens, Government, Industry. This document is focused on packaging and presenting those techniques, standards and practices in a manner which fits within the norms and processes of the Federal IT community; allowing for consistent and evolutionary adoption and use, and eventually shared realization of its benefits.

SOA encompasses multiple dimensions which must work in concert for it to be successful. Adopting service-based technologies alone will not enable agencies to achieve the benefits associated with SOA. For the purposes of this document we accept the definition of a service as defined by OASIS as:

“The means by which the needs of a consumer are brought together with the capabilities of a provider.”

Appropriately, this definition is fairly broad and includes more than technical services. As the name suggests, SOA involves architecture. This Practical Guide employs an industry standard definition of SOA (OASIS):

“Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”

The conventional concept of SOA does not include Event Driven Architecture (EDA), which is an essential component to a fully functional SOA environment. However, for the purposes of this document, the definition of SOA includes all of the functionality normally associated with EDA.

As described in this Guide, SOA has organizational, governance, business process, structural, and technical dimensions that must be managed and synchronized. This Practical Guide has been written to support Federal chief architects and CIOs in their efforts to adopt SOA best practices to further their organization’s mission, meet increasingly demanding compliance requirements, introduce more agility into their architecture, and optimize their IT architectures.

Rationale for SOA

The net results of broad-based adoption and advancement of SOA capability throughout the federal government will enable:

• Improved government responsiveness: By employing services to establish a flexible architecture centered on business and technology capabilities, the impact of change can be isolated and business processes can be more easily and rapidly modified to meet business and mission performance requirements.

• Simplified delivery of enhanced government services: SOA and the “service” business model enable collaboration by simplifying access to services and streamlined value chains across organizational boundaries.

• More efficient government: SOA facilitates mutually leveraged public and private sector investment; reuse of capability; elimination of undesirable redundancies; and a more focused model for on-going IT recapitalization.

• Information sharing: SOA provides an effective and efficient approach to implementing reusable data exchanges - taking logical interoperability coming from multiple data modeling activities and rapidly evolving it into physical interoperability.

• Transparency, security, and resilience: SOA is predicated on a shared, standards-based infrastructure. This will enable consolidation, simplification, and optimization of IT Infrastructure, which in turn will enable greater transparency and audit-ability, as well as improved continuity of operations.

The primary risk of SOA is when its application is not effectively governed with purposeful intent -- in other words, the business agility SOA promises cannot be achieved through ad-hoc application of SOA technologies. Business agility must be purposefully designed into each organization’s Enterprise Architecture, IT Governance, and IT Policy framework and implemented incrementally with each step tied to delivered business value. Agency CIO’s and government-wide policy must insure that this formalized, structured approach is incorporated into agency SOA implementations and evaluated through Assessment Frameworks.

Vision: Improving Services from Federal Agencies

This practical guide is organized around three perspectives of service orientation that together enable the effective adoption of SOA into a federal organization. For each of these perspectives, we characterize the objectives of a mature SOA capability. These are the objectives that each federal organization adopting SOA should strive to achieve in order to achieve its maximum benefits.

• Service Oriented Enterprise (SOE) consists of the organizational and managerial practices needed to enable and govern SOA. SOE establishes trust and includes the incentive model that drives mutually profitable collaboration among service providers and consumers.

• Service Oriented Architecture (SOA) is the body of standard design and engineering processes, tools, and best practices that leverage the modularity and composability of services to support business objectives. SOA deepens and extends the Enterprise Architecture and defines the implementation of the architecture in terms of its technical approach.

• Service Oriented Infrastructure (SOI) is a collection of functioning capability, including technology, standards, and collaborative processes that enable safe (i.e., secure and private) and efficient collaboration through the development and deployment of shared operational IT services. SOI decreases the risk of security and privacy breaches by implementing standardized infrastructure components and services.

Keys to Federal SOA Implementation

There are critical strategies and tactics that have been demonstrated to be effective at facilitating SOA adoption. In general, the intention is to de-couple the business objectives from the complexity of the IT infrastructure by developing a target service-based business model. Then a services architecture needs to be developed with the specific objective of aligning program (i.e., as described in the exhibit 300) and project based DME (development, modernization, enhancement) funding to incrementally re-capitalize IT assets against the most critical business drivers, as well as encourage planned or immediate reuse of emerging or existing services rather than making duplicative investments. Early on, the challenge has been to balance the incremental demands on program and project teams – delivering for their immediate customers as well as the requirements of the broader enterprise. Later on, the objective is to balance the inter-twined dependencies - requirements, service levels, and funding models to name a few - in a way that results in increased organizational agility and improved mission performance. Both require strong leadership and effective governance.

Keys to Implementing the Service Oriented Enterprise
* Ensure IT planning and acquisition processes capture service reuse and funding requirements and target architecture technology constraints. Build alignment into the SDLC so it is automatic.
* Identify enterprise requirements and organize around target services, standards, and information sharing that support key mission performance objectives; then fund accordingly.
* Develop incrementally. Employ an incremental “lifecycle recapitalization” approach and modify the SDLC to support a twin-track development process with separation between service provisioners and solution assemblers.
* Federate governance, engineering, and procurement. Leverage existing agency and cross-agency governance processes to support the Federal E-Government initiatives, LOB initiatives, and other initiatives such as NIEM to enhance SOA implementations.

Keys to Implementing the Service Oriented Architecture
* Identify critical business objectives. Perform business process analysis and reengineering and sustain accurate service-based business models for business automation requirements.
* Identify and define the target service architecture. Establish a layered service architecture that directly supports the business performance objectives. Introduce “service” as a first order concept in your enterprise architecture. Integrate existing and emerging cross Government and cross agency services, ideally driven out of agency segment architecture activities.
* Enable and empower autonomous compliance and alignment. Define and publicize the enterprise service portfolio plan and phased transition strategy. Note that this works best where you have the most detailed roadmaps, thus start with the core mission or business activities, or cross cutting services, where you have developed segment architectures.
* Adopt model-driven architecture and pattern based design. Establish model-based reference architectures and reference implementations. Start by bridging from segment to specific solution architectures.

Keys to Implementing the Service Oriented Infrastructure
* Establish a service oriented infrastructure that addresses security/privacy, scalability, and interoperability. In particular, leverage secure virtualization approaches to cleanly separate the shared security, transport, storage, and compute capabilities from individual services and solutions.
* Study critical transactions to develop a trust and semantic model. Invest to develop standard government security services; test and certify adaptively and continuously. In particular, look to align with and adopt existing and emerging cross Government solutions, and improve them as needed via established governance models. Isolated agency-based solutions, no matter how good, run the risk of impeding downstream cross Government interoperability.
* Introduce run time service monitoring tools. This includes monitoring and management across all relevant targeted attributes – security, privacy, reliability, serviceability, and availability. This is another area where it is important to align with and adopt existing and emerging cross Government approaches to ensure that creation of artificial boundaries for sharing, reuse, and interoperability are avoided.
* Establish performance-based service levels and service level management processes and cost and performance accounting processes to facilitate the effective sharing of services. Look to express these service level agreements in shared, Government-wide structured IT policy frameworks.

Roadmap for Federal SOA Implementation

The purpose of a roadmap is to establish direction, identify the contributing factors (or work areas), and determine the specific steps to undertake within each of these areas. The first step in any roadmap is to perform an assessment – an evaluation of how SOA can be an enabler to help an organization to achieve its goals or implement its strategies. The assessment should examine organizational strengths, weaknesses, and actuators in context with the opportunities associated with SOA.

• Apply a relatively generic SOA Maturity Model that outlines the stages of maturity through which organizations go to implement and operate a Service Oriented Architecture.

• Conduct a sound Maturity Assessment to determine the organization’s level of maturity in relation to each SOA contributing factor. Consider governance, service orientation, technology environment, management commitment and perspective, technical skills, and capabilities.

• Evaluate existing agency governance processes and agency participation in Government wide and other external governance processes, in light of the results of the Maturity Assessment and determine adjustments that are necessary to encourage and support Service Orientation.

• Begin or advance SOA implementation to identify priority areas based on the SOA maturity assessment and balance achievements in each of the work areas.

• Define an incremental, sequenced approach to agency implementation to deliver frequent, small, but visible successes and to capture and exploit best practices.

Implementing the recommendations contained in this Practical Guide will initiate a “journey” within the Federal government towards greater effectiveness and efficiency for both IT and the business/mission. The result of this journey will be an enhanced degree of responsiveness to the citizens and an improved ability to respond quickly to new requirements and situations.

Introduction [Document Section 1]

The world is changing at an accelerating rate and the federal government needs to keep pace. Broad-based change is always difficult, but the federal government is plagued by a variety of inhibitors to change, including vertical vs. mission organizational orientation; bureaucratic culture; budgetary cycles and processes that do not facilitate agility or reuse; and a large and diverse current technology base. Service Oriented Architecture (SOA) promises to help agencies rapidly reconfigure their business and more easily position IT resources to serve it. Improved business agility – through sharing and reuse of infrastructure, services, information, and solutions - is a growing requirement in the federal government today and will be increasingly critical in the future.

The purpose of this document is to describe a target federal service oriented architecture vision and to provide guidance in the management and governance of enterprise-wide services. Many federal organizations are considering or planning for a broad based adoption of SOA. In order to effectively move to an SOA environment, an organization must conduct careful planning and assessments for a variety of organizational, architectural, and technological challenges.

With recent advances in federal enterprise architecture, federal chief architects and chief information officers have a deeper insight into their current IT architectures at all levels of government. In most organizations, this visibility has exposed many inefficiencies and undesirable redundancies, as well as disconnect between the promise and the reality of technology for improving business outcomes. In turn, this has led to a variety of consolidation initiatives and reengineering efforts at all levels of the federal government. The most widely publicized and recognizable are those government-wide initiatives compiled into the annually published Federal Transformation Framework (FTF) from the Office of Management and Budget (OMB) [OMB, 2006].

While the FTF is concerned with cross-agency initiatives which leverage reuse efficiencies and improved organizational performance, agencies themselves are faced with similar internal challenges. Recognizing this concern, as well as others, OMB published the Federal Enterprise Architecture (FEA) Practice Guidance [OMB, 2007b] that introduces Segment and Solution Architectures and their relationships with Enterprise Architecture (EA) through a notional framework (see Figure 1-3 of the FEA Practice Guidance document). The Solution Architecture is equivalent to an IT system that is reconciled to the Segment Architecture. The FEA Practice Guidance strongly indicates that Segment and Solution Architectures inherit their structure, policies and standards and re-usable and sharable solutions from the Enterprise Architecture. This is directly aligned with the direction of Service Oriented Architecture.

Just as industry has adopted SOA best practices, it stands to reason that federal organizations will turn to SOA best practices to optimize their IT and business architectures. SOA is not just a technology to be leveraged; it is a true paradigm shift and requires substantial organizational, cultural and management changes to be effective.

This Practical Guide to Federal Service Oriented Architecture has been written to help federal chief architects and chief information officers in their efforts to adopt SOA best practices to further their organizations’ mission outcomes, meet increasingly demanding compliance requirements, and optimize their IT architectures. There are other drivers for federal government adoption of SOA. To fully appreciate the potential of SOA for furthering federal government agencies’ missions, some understanding of SOA’s origin and subsequent evolution is helpful.

SOA Concepts

Like most technological advances, SOA leverages the technologies and standards that preceded it. Chief among the technology events that led to SOA are the rise of the Internet and the emergence of effective distributed computing platforms, such as Java 2 Enterprise Edition (J2EE), Microsoft .NET, and XML. For a discussion of the evolution of technologies leading to SOA, see the Federal CIO Council publication, Services and Components Based Architecture (SCBA) [CIOC, 2006].

The term “Service Oriented Architecture” was widely adopted when the World Wide Web Consortium (W3C) established standards for integrating business systems over the Internet through the standardized use of web technologies and protocols. The standards developed were designed to enable heterogeneous distributed systems to interoperate through standard web-based conventions modeled to support distributed component architectures. Many standards have been adopted by standards bodies in support of SOA. Some of the early standards included Web Service Definition Language (WSDL) and Simple Object Access Protocol (SOAP). These Web Service standards enabled businesses to automate collaboration over web-based technologies in a standard way. This in turn has facilitated the movement toward a focus on services and their ability to transform the delivery of business capabilities.

As commercial organizations and IT product vendors embraced these web service standards, the meaning of SOA evolved. Vendors in the IT space, using creative marketing to differentiate their offerings, adopted different perspectives and terminology to promote their strategies and products. At the time of this publication, federal government CIOs and chief architects are inundated by differing perspectives and definitions of SOA.

Some of the technology disciplines and products currently accepted as falling under the SOA umbrella include: Business Process Management, Enterprise Service Buses, Repositories and Registries, Composite Applications, and Component-Based Architectures. One of the purposes of this document is to clarify many of the concepts that fall under the SOA umbrella.

It is also widely accepted that service-based principles can be applied more broadly, even outside the scope of IT, to business architectures in general. It is important then for federal executives to come together around a common definition for SOA. For the purposes of this Practical Guide, we will adopt the Organization for the Advancement of Structured Information Standards (OASIS) definition for SOA presented in Exhibit 1-1.

The OASIS definition does not relegate SOA to IT architectures, but allows the broader interpretation that SOA can be applied to business architectures as well. This is particularly useful in understanding why SOA is the best available paradigm for achieving many federal Enterprise Architecture goals and objectives. In this Guide, we accept the broader interpretation of SOA as a business transformation paradigm. In order to achieve this broader promise of SOA, the organizational, architectural, and technical dimensions must be managed carefully, synchronized across boundaries, and focused on key business outcomes.

This broader view of SOA establishes the importance of a common definition for service. Therefore, for purposes of this Practical Guide, we use the OASIS standard definition of service:

“The means by which the needs of a consumer are brought together with the capabilities of a provider.”

For a moment, ignore technology and consider that the majority of the US gross domestic product (GDP) is based on a “service model.” A service model is an approach to doing business that allows a task to be defined so that it can be accomplished by others. The details of the service provided should be transparent to the consumer; hence, a consumer finds a provider, chooses among service options, requests the service, and the desired service is provided within the terms of some agreement. Consider how many services a business operates. A marketing method introduces customers to service offerings and a supply chain composes an arrangement among various interoperating service providers (inventory management, transportation, legal, fiscal, artisan, etc.) to deliver the offering.

It is useful to view government organizations from the service perspective. The “government service unit” depicted in Exhibit 1-2 could represent an organization at any level (i.e., department, agency, bureau, program, division) or could represent a collaboration initiative that includes multiple government organizations. For the purpose of this document, we define a Government Service Unit as:

A useful organization of government resources (staff, facilities, automated systems, etc.) viewed in a service perspective.

Exhibit 1-3 depicts two government service units in this consumer provider relationship. The service model applies to the services the federal government offers to its constituencies. The service model is apparent within the Federal Enterprise Architecture (FEA) Business Reference Model and the Service Component Reference Model that the Office of Management and Budget (OMB) has established as the overarching framework for understanding the business of the US federal government [OMB, 2007a]. In particular, the relationship between the Business Reference Model and the Service Component Reference Model helps agencies begin to define their specific service model as a combination of business and technology services. The service model is the core vehicle to drive SOA adoption and implementation. This guide will navigate chief information officers and chief architects through the development and implementation of their “service model” by providing guidance for identifying, classifying, and organizing their services. This guide also prepares an organization’s IT leadership for transitioning to the service model.

The potential benefits that SOA can deliver to the federal government are far reaching and substantial, but they require significant change within federal government organizations and carry with them some inherent risks. The primary challenges for SOA arise when its application is not effectively governed with purposeful intent. The business agility that SOA promises is not achieved through ad hoc application of SOA technologies. Rather, business agility must be purposefully designed into each organization’s Enterprise Architecture, carefully governed and managed to ensure its incremental realization.

SOA Challenges

The process of reconciling the Enterprise Architecture’s IT services portfolio, both intra-agency and cross-agency, frequently results in conflict when two or more programs have an interest in a given service type. Conflict is, in part, due to a lack of an enterprise-wide SOA framework and may be grouped into at least four major challenge categories (politics aside):

1. Lack of an operational or target model for federal enterprise-wide SOA environment;
2. Lack of understanding and experience in implementing SOA at the agency/department-level;
3. Lack of procedures/guidance for consuming enterprise services in lieu of local services; and
4. Lack of operational services management; particularly for cross-agency services once implemented.

A key characteristic of SOA is modularity that facilitates/enables service reuse across processes and organizational boundaries. A service that is designated for reuse or as an enterprise service, such as authentication, must reside in an environment that is discoverable, reliable, maintainable, and can be monitored. An overarching architecture is needed to contain these services as they are developed and implemented. Further complicating this is the need to support service reuse at multiple levels – between programs, between bureaus, between departments, and so on. This challenge is addressed in Section 3.

The discipline of enterprise-wide SOA is immature in the federal government. For example, for any large federal organization, reuse of services across processes and between contractors is rare. While organizations may have a “repository” that is used (like a library) to check services in and out, it often fails to support a true SOA model. As a result, training and mentoring are needed to fully leverage the benefits of SOA within and across the enterprises.

The third challenge that creates conflict has two dimensions. The first dimension concerns the consequences of promoting a locally developed service up to an enterprise-wide or cross-agency level. Often, there are no procedures and/or compensation for the development of the service that is to be used by two or more entities. Related to this are the issues of quality of service (QoS) obligations of the original developer as consumption of the service increases (for example, as the service designed to support 100 transactions per second now needs to support 10,000 transactions per second) and the functional responsibility for the service (i.e., who is responsible for implementing changes to critical business rules of the service). The second dimension concerns the reality “after the fact” that stand-alone SOA-based systems have been implemented and are in development. Should these systems be required to adopt the declared enterprise-wide services as an outcome of the organization’s Enterprise Architecture, even though the services may not meet 100% of the requirements? This challenge is addressed in Sections 4 and 5.

The fourth challenge is associated with business management of services, including QoS standards and Service Level Agreements (SLAs). This challenge can be illustrated by analogy. Networks are closely monitored in “War Rooms” with banks of screens to monitor network performance. As the network experiences performance problems, engineers can quickly respond and in most cases resolve the issue before the problem cascades throughout the network. Returning to services, which are implemented within and across enterprises, the performance of each service and the interaction between services also needs to be monitored to ensure the business output and outcomes are achieved.

SOA and Enterprise Architecture

SOA does not replace EA. As depicted in Exhibit 1-4, Enterprise Architecture encompasses SOA. This diagram builds on the lifecycle diagram from the Practical Guide to Federal Enterprise Architecture [CIOC, 2001]. At each stage in the EA lifecycle, a set of activities is conducted to service-orient the EA. While the activities noted on the inner circle of the diagram are not intended to be exhaustive, they do indicate the types of activities organizations must undertake to implement SOA. These activities are discussed throughout this document with explanations and examples of how to accomplish the tasks.

The first stage of the EA lifecycle is “Obtain Executive Buy-In and Support.” For SOA, this aspect is extremely important. Adopting SOA should be considered a major change management initiative and requires executive support for transitioning an agency to a service-based organization. As we discuss in the document, this requires changes at three levels: enterprise (organizational management), architecture and infrastructure. If executive buy-in is not obtained, it will be nearly impossible to successfully adopt SOA.

Exhibit 1-4: SOA Best Practices Extend EA

In the second EA stage - “Establish Management Structure and Control”, the management structure and processes must be modified to enable a “Federated, Collaborative Governance” model. In order to achieve the benefits from SOA, services will be provided and consumed across organizational (internal and external) boundaries. As a result, the governance model must be capable of guiding and adjudicating issues across organizations, thus requiring the need for a federated, collaborative governance model.

Under the third stage of EA - “Define an Architectural Process and Approach”, the EA methodology is updated to incorporate services by conducting an SOA Maturity Assessment and developing a roadmap plan. In addition, the architectural artifacts are augmented with a Services Portfolio Plan which lays out the approach for identifying and grouping services within the EA.

The fourth stage of EA - “Develop Baseline Enterprise Architecture” is modified to begin to identify services in the current systems environment and to determine whether the current infrastructure platform is capable of supporting SOA. During this stage, the EA team begins to develop the Legacy Portfolio Plan which analyzes legacy applications for services/capabilities provided so that the best sources for services can be identified.

In the fifth stage - “Develop Target Enterprise Architecture”, a major shift occurs. In this shift, services instead of applications are used as the unit for portfolio management. While conceptually simple, this shift has profound implications. Only by managing a portfolio of services, is the enterprise architect able to identify the opportunities for sharing and reuse, or alternatively, to identify redundancy of capabilities.

The sixth stage - “Develop the Sequencing Plan” is updated to incorporate the provisioning of services from internal development, outsourcing, or commercial sources, as well as the development of composite solutions, assembled from services. The sequencing or transition plan now indicates the sequence of developing or procuring of services so that they are available to be consumed in the applications as they are rolled out.

The next stage - “Use the Enterprise Architecture” is expanded to include managing the repository or registry of services so that they can be located, assessed and reused. In addition, Quality of Service (QoS) standards are implemented and maintained. The service oriented EA is used to improve the business and meet mission objectives.

Finally, during the “Maintain the EA” stage, the agility provided by the service oriented EA allows capabilities to be replaced with modern, more effective and efficient capabilities. In this way, the SOA is used to enable the incremental recapitalization of IT and business assets. Each of these enhancements to the EA is discussed in the following sections reinforcing the notion that SOA does not replace EA, it extends it.

Organization of the Document

The sections of this document present a synthesis of best practices drawn from industry and government communities. Section 2 - The Rationale for Federal SOA, makes the case for adopting SOA. Section 3 - The Service Oriented Vision: the Target Architecture, describes a target state or vision for a SOA enabled government. Section 4 - Keys to Federal SOA Implementation, presents some of the major factors that must be addressed and offers possible approaches and best practices that can be applied. The final section, Section 5 - A Roadmap for SOA Adoption, outlines a general SOA maturity model that can be used to assist agencies in organizing their implementation strategies and includes some activities that can be undertaken to advance SOA.

The Rationale for Federal SOA [Document Section 2]

As a result of significant increases in the need for government services that are effectively delivered, the growing threats to the country posed by terrorist organizations, requirements for increased information sharing and collaboration, and constrained agency budgets, agencies are under tremendous pressure to deliver higher levels of program performance through their information technology investments within tighter cost constraints. In particular, federal CIOs and chief architects who are responsible for a broad set of goals defined by the Federal Enterprise Architecture Program can realize the following spectrum of benefits for pursuing service orientation in their business, data sharing, and technology infrastructure transformations.

Improve Government Responsiveness

SOA can enable agencies to better respond to the challenges they face. By employing services to isolate business functionality within architectures, the impact of changes can be mitigated, parallelism can be introduced to allow more change initiatives to proceed concurrently with shorter lifecycles, and IT investments can be better managed and measured to more effectively deliver mission/business value. Additional benefits include:

• Increasing the speed at which critical mission capabilities are added
• Improving agencies’ ability to rapidly respond to changing demands
• Implementing more effective service and information discovery and reuse capabilities
• Offering new functionality for end users/citizens and produce better communication between citizenry and government

Simplify Delivery of Enhanced Government Services

• Enable broader and more consistent access to data and information;
• Enhance the ability of agencies to more rapidly and effectively modernize their business processes and systems;
• Implement more effective models for the specification, procurement, and operating effectiveness of services; and
• Manage shared value streams across government organizational boundaries to facilitate the delivery of common services to citizens.

Contribute to a More Efficient Government

• Find ways to collaborativelyleverage public and private sector investments to innovate IT architecture and drive business and mission improvement.
• More effectively use the agency IT budget through the reuse of existing capabilities. More effective staff utilization through common training and modernization of skill sets.
• Foster consistency, discipline, and control through cross-domain governance of IT Infrastructure development, and bridge the gap between business and IT stakeholders.
• Create cross-domain/cross-agency trust, data access, and semantic interoperability to enable an increased use of shared services.

Promote Information Sharing

• Provide an effective, efficient and repeatableapproach to implementing reusable data exchanges.
• Take logical interoperability coming from collaborative data modeling and architecture activities and turn it into physical, on-the-wire interoperability.

Increased Transparency and Resilience

• Provide a shared, standards-based infrastructure.
• Enable consolidation, simplification, and optimization of IT Infrastructure for audit ability and continuity of operations, while maintaining appropriate levels of security.
• Support an effective integration approach to deal with the rationalization of the enterprise applications and diverse technology infrastructures.

To meet today’s challenges, federal CIOs and chief architects must find new and more effective ways to develop, deploy and apply their IT assets. Implementation of SOA can provide federal CIOs and chief architects the environment and tools to more effectively deploy IT resources. There are many reasons federal organizations should embrace SOA today. Some of the reasons are technological and others are driven by recent changes in the federal IT environment, but the primary reason is that SOA has the potential to substantially improve the ability of federal organizations to execute their mission. The discussion below highlights the rationale for implementing SOA to achieve dramatic improvements in business outcomes.

Enhancing Mission Effectiveness

A variety of emergency situations in recent years has demonstrated the tragic consequences that can result from information overload or the inability or unwillingness of organizations to share information. Terrorist attacks, natural disasters, and large-scale and organized criminal incidents too often serve as case studies that reveal weaknesses in our nation’s information sharing capabilities.

As a result, agencies are under tremendous pressure to collaborate across agencies, and levels of government, and share information to deliver higher levels of program performance. In addition to the program imperative to leverage existing process and technology capabilities, OMB is putting substantial pressure on agencies to reduce the costs of their IT portfolio and the redundancy in applications and infrastructure. With multiple competing demands for budget funds, it is critical that agencies make more effective use of IT dollars. Budget pressures are increasingly forcing agencies to improve their processes and technology to deliver higher value to their missions.

The ability to reuse capabilities and leverage infrastructure to support multiple application delivery initiatives is the most salient values of SOA and the one with the most potential for substantial gain. SOA can improve agency and overall federal mission performance by improving business agility and enhancing the ability to share capabilities effectively and securely. The objective is better mission outcomes.

CIOs and chief architects should validate the rationale that SOA helps achieve this objective by monitoring measures of effectiveness such as the following:

• Service level objectives (SLO) and associated service level agreements (SLA) built around performance factors like latency, availability, response timeand accuracy.
• Objectively quantified productivity metrics and associated mission level agreements (MLA) around performance factors like:
  • Decreasing time required to complete planning cycles
  • Decreasing inventory “at rest” in a supply chain
  • Increasing number of, quality of, and/or cost of “widgets” out the door.

Continuous Innovative IT Asset Re-capitalization

Two related and critical tasks of federal CIOs and IT architects are to operate and continuously evolve the organization’s IT assets. In government, this has traditionally meant sustaining a given type and level of capability over many years. The best practitioners of e-business utilize their resources more effectively by regularly refreshing their IT architecture. They use a combination of capital investment and operations and maintenance (O&M) funds to innovate, reconfigure and add new capabilities -- thus re-capitalizing the IT architecture to enhance enterprise capabilities. In traditional system-focused architecture, this technical refresh is an expensive big bangprocess where extensive and costly hardware and software upgrades are carefully designed and implemented across the enterprise over the course of multiple years.

SOA offers flexibility at several levels; ranging from a reduction in dependence on proprietary technologies, to a streamlining of the development process, to reusing both business and IT assets. Many commercial enterprises have adopted SOA as a means of breaking up inflexible IT infrastructures, which are usually characterized by monolithic customized applications. SOA enables an evolutionary, structured transition from monolithic applications to composite applications (i.e., applications that are composed from services) by allowing new capabilities to access legacy transactions that have been exposed as services. The composite applications exhibit greater agility and when requirements for the “exposed” service change, the service can be replaced by a newly developed or acquired service, also without major change to the underlying supporting infrastructure.

When a service oriented architecture is in place, incremental improvements to business and IT services (i.e., IT-enabled business process enhancements) can be deployed rapidly and as part of independent, parallel efforts across the enterprise. Trial enhancements can be evaluated and adopted or passed over in the course of months or weeks. This approach enables agile business process innovation by drastically reducing the time and cost it takes to experiment with and deploy better solutions. In addition, SOA enables the “pre-testing” of services and business processes which contributes to reduced implementation time.

Hence, from a business perspective, the overarching Federal Enterprise Architecture guidance to exploit SOA should result in an increase in the relative percentage of the IT budget that can be applied to improving critical business processes by reducing the cost and scope of the changes, as well as to decrease the cycle time to implement improvements.

Note that for a given enterprise requirement, it does not generally cost less to deploy the infrastructure to support SOA than it costs to deploy a system-focused infrastructure. However, once deployed, the service oriented architecture lends itself to more agile and adaptive updating, as well as reuse by multiple service components. This can drive down the long-term cost of the IT architecture; releasing funds for either higher priority mission/business needs or to enhance the IT asset base. This also allows a gradual migration to service orientation at a relatively low investment cost per year (recognizing that governance, culture, roles, portfolio, and other issues must also be addressed). It should be noted that during the migration process (which will most likely be years) it will be necessary to support the existing and the SOA environments. Additionally, it can take a long time to migrate COTS products to the SOA environment. In many cases it will be necessary to wait for the product owner to incorporate the necessary functionality. The organization must be prepared to fund both environments for a considerable length of time.

The rationale described above has been successfully applied by many commercial businesses, including Internet portals like Google, as well as “back end” applications of businesses in many domains (financial, health, manufacturing, logistics, etc.). Top down “model based” methods of architecting applications have contributed to this success [Juneja, 2007]. This model-based approach allows enterprises to analyze the business transactions that are critical to their desired business outcomes in a way that is separate from the IT infrastructure. Enterprises can then compose their required IT capability improvements from the best of breed off the shelf technology and/or identify critical technology gaps to address.

Any organization today that relies on software will find SOA capabilities and features embedded in the software products they use. For example, a purchase of the latest release of any commercial enterprise resource planning (ERP) product will include an enterprise service bus (ESB) designed to enable SOA. The leading integrated development environments (IDEs) include features that simplify and automate the design, development andpublication of services. Java and XML are ubiquitous on the Internet and in shrink wrapped software. Whether or not an organization chooses to adopt SOA, the number of services in place will nonetheless increase each time an agency purchases or installs the latest version of a software product. The critical question is whether it will expand haphazardly, or expand in a planned manner as a key enabler of the enterprise strategy defined within the Enterprise Architecture. Some measures of effectiveness (MOE) to support this rationale are:

• Increase in the percentage of the IT budget available for expanded business capabilities.
• Decrease in the cycle time from the management approval to the implementation of an IT-enabled business process improvement.
• Increase the availability of reusable services deployed by one program or project and used by others.
• Increase in the ratio of funds spent on shared services to developing unique IT capabilities within individual programs or projects.

Cross-Domain/Cross-Agency Trust, Data Access, and Semantic Interoperability

The ability to provide the right information and service, in the right context, securely, and at the right time is the overarching objective of any IT architecture. Achieving this objective requires increased collaboration across domains. Differences in perspective, priorities, semantics (i.e., the “language” of a particular domain) as well as concerns over security make collaboration across domains inherently difficult. Programming machines to collaborate in view of these issues is just as difficult.

SOA offers significant improvements in this collaborative model across both an agency’s IT architecture as well as between disparate architectures. SOA makes it feasible to implement reusable services for security, discovery, and business contexts that can be shared collaboratively within and across communities of interest. On the one hand, these collaborative services can allow information providers to deliver information from the authoritative source to all potential consumers of the information. On the other hand, proper security controls can permit or deny consumers access to data and services based on multi-level security and risk factors.

Federal CIOs and chief architects can apply this SOA rationale specifically to the enterprise concerns of their agency or to specific architectural segments to deliver IT capabilities that add collaborative value. Federal CIOs and IT architects should carefully devise and track measures of effectiveness, such as the following, to validate the collaborative value of SOA:

• The percentage of data and services discoverable in context.
• Presence of risk/reward models governing access to data and service.
• Volume of cross-domain data exchange.
• Percentage of exchanged data to total data accessed/managed (by type and volume-weighted).
• Number of unintended disclosures of sensitive information.
• Amount of downtime due to “denial of service” attacks.

Leveraging IT Investments across Federal Agencies and Sharing Best Practices

Agencies are increasingly pressured to increase the effectiveness of their IT spending and to drive efficiencies in the use of their IT assets. In order to more effectively leverage IT assets, the federal government should take better advantage of the scope and cumulative nature of its IT expenditures to achieve commodity pricing and improved quality of service. Individual agencies, and in many cases, sub-components of Cabinet-level agencies procure software, hardware and IT support services separately.

The Office of Management and Budget (OMB), through the Federal Enterprise Architecture (FEA), the GSA SmartBuy Initiative and the Line of Business Initiatives, intends to identify and share the “best pricing” obtained across departments and in some cases across governments.

SOA can enable an agile, modular IT environment where business process delivery is separated from the technology, and where security and semantic models allow enhanced collaboration. It follows then that SOA can enhance cross-agency acquisition efficiency through the re-use of capabilities and best practices that are easily identified, shared and adopted in such an environment. Multiple agencies can pool their resources and spread the costs and risks to address common requirements.

Note that this secure, modular, interoperable, collaborative IT environment, i.e., federal service-oriented enterprise, does not yet exist. Therefore CIOs and IT architects may validate this “re-use” rationale for SOA by monitoring measures of effectiveness or maturity such as the following:

• Increase in the percentage of dollars leveraged across federal lines of business for common IT capabilities can help validate that reuse is occurring. One would expect to see this measure increase year over year.
• Increase in the number of processes, incentives, and resources for collaborative IT architecture that exist across the federal IT professional community.

Service Oriented Vision - The Target Architecture [Document Section 3]

This section presents a vision of the future when the benefits described in the previous section have been achieved. The vision presented here presumes that the IT-enabled business improvement required to embrace SOA has already been largely achieved throughout the Federal Government. As such, this Service Oriented Vision presents an idealistic future that has been extrapolated from an understanding of today’s promising technologies, standards, and best practices and an assumption that they will mature and converge -- ultimately enabled by automated tool sets.

The service oriented vision described here sets the stage for the subsequent sections by describing the objectives, behaviors, and outcomes that federal architects should strive for. The Target Architecture we ultimately seek to achieve provides the necessary context for understanding the subsequent sections. The SOA Adoption Roadmap presented in Section 5 is a roadmap to achieve this vision. The Keys to Implementation presented in Section 4 identify critical success factors and challenges that organizations need to address to realize this vision.

While “target architecture” notionally represents the end point in the evolution (that is, time independent), in reality the target will need to evolve to keep pace with the rampant technological innovation of our time. So take heed, this section of the document, this vision, will become stale over time. Chief architects and CIOs should keep abreast of both enterprise objectives and technology trends and then work together to periodically revise their organizations' target architectures. On the bright side, because SOA enables agility and innovation, as agencies mature their SOA capability, they will find they can more rapidly progress toward their target architecture.

The Federal SOA Vision

The SOA vision is that federal agencies become more agile from a management, operational and acquisition perspective by employing a “service model” with continuously improved automation support. For example, an agency that has achieved the Target Architecture would exhibit the following characteristics:

• IT responds more rapidly to meet the demands of changing business and mission needs.
• Government organizations routinely organize into ad hoc partnerships to automate collaboration models.
• Government can more easily and effectively recapitalize IT components to leverage the latest commercial technology capabilities and reuse standard government and industry solutions and services.
• Government services are easier to access, deliver higher value, and extend across organizational boundaries.

As the Target Architecture is adopted throughout the federal government and these characteristics are manifested within bureaus, agencies, and departments, we can expect to see streamlined lines of business, more robust and useful end-to-end services, and new government capabilities converge to deliver more effective mission fulfillment. But the vision extends far beyond an isolated federal government. These same characteristics will be leveraged to adopt industry domain standards and will engender more extensive collaboration with business, state and local government, and international partners.

The next section provides a top-level overview of the Target Architecture.

Overview of the Target Architecture

Because there are many interdependent aspects to the target agile enterprise, we will divide the discussion into three major parts (see Exhibit 3-1):

• Service Oriented Enterprise (SOE): The business, management, and operational processes, procedures, and policies that support a services model. In essence this is an organizational behavior model aligned with the service model and designed to facilitate and govern its effective maturation.
• Service Oriented Architecture (SOA): Enhanced architecture practices that leverage robust models to capture and facilitate service architecture engineering best practices. SOA is the application of the service model from EA through segment architectures to solution architectures.
• Service Oriented Infrastructure (SOI): The service-enabling environment, itself delivered as a collection of robust enterprise services that enable runtime connectivity and interoperability. SOI represents the operational environment that supports the service model.

Exhibit 3-1: A Service Oriented Framework

SOE enables the service model by facilitating shared acquisition models, incorporating architectural alternatives in the decision process, and enabling effective collaboration across boundaries. SOE also governs the SOA and SOI activities ensuring that justifiable business drivers support IT investments and deliver intended results. SOA is an architectural style that uses modularity to decouple technical complexity from the business drivers. The run time service-oriented environment that constitutes SOI supports the implementation, deployment, and manageability of delivered service oriented solutions. These three major parts are integrated and mutually supportive.

Because the Target Architecture is forward looking, it has been derived by envisioning today’s emerging SOA related best practices and technologies in a more mature state; then imagining an organization that has fully embraced and adopted the service oriented model. This section presents the best practices and technologies that are projected to advance and enable the SOA vision presented here. These best practices and technologies have been organized in a table (Exhibit 3-2) that includes a brief description of each, a statement of how it supports the vision, at least one reference for more information, and examples of specific related standards or initiatives.

'Exhibit 3-2: Target Architecture Best Practices and Technologies'Can we put this piece in the appendix??

Best Practice or Technology	Description	Relevance to SOA Vision	Reference	Example Standards and Initiatives
Business Process Management (BPM)	An approach to improving business performance.	Enables agile business process orchestration and service choreography.	bmi.omg.org [1]	BPMN, BPXML, BPEL
Model Driven Architecture (MDA)	OMG best practice for architecting solutions.	Enables complex IT architectures and solutions to be precisely represented in simplified forms. Many of today’s integrated development environments products today incorporate MDA capabilities.	www.omg.org/mda/ [2]	UML, XMI
Composite Applications	Unified solutions assembled from services.	Enables collaboration and extended value chains	Open Service Oriented Architecture: www.osoa.org [3]	BPEL4WS,WSCI
Enterprise Service Bus (ESB)	Leverages industry standards to provide a robust integration and operational infrastructure that supports the integration, operation, and management of heterogeneous, distributed computing systems	Provides a service oriented infrastructure that enables SOA infrastructure.	-	Sonic, BEA, IBM, Oracle, SAP, TIBCO, and many other vendors offer an ESB.
Semantic Interoperability Standards	Models, frameworks, and standards for cross Community of Interest semantic interoperability	Enables shared semantics to the extent needed for cross boundary information sharing and services	www.niem.gov [4], W3C	XML Schemas, OWL, NIEM
Enterprise Architecture	Governance and IT planning and management framework	SOE concepts exist at the enterprise and segment architecture levels; SOA. SOI concepts come into play at the segment and solution architecture levels	www.egov.gov [5] www.cio.gov [6]	Federal Enterprise Architecture and related CIO Council guidance

The following subsections provide additional insight into the Target Architecture Vision by examining SOE, SOA, and SOI in more detail.

Service-Oriented Enterprise (SOE)

SOE is perhaps the most challenging of the major parts of the Target Architecture because it requires the greatest change to entrenched business practices. Enterprise architecture, as a discipline, is designed to achieve efficiencies and mission enablement by standardization, optimization and collaboration across organizational boundaries. Service orientation is an approach to architecture that is particularly well-suited to achieve these objectives. SOE, discussed in this section, builds upon the foundation laid in the 2006 Federal CIO Council report, “Services and Components Based Architecture” [CIOC, 2006]. In particular, Section 3 of that report addresses the strategic, policy and organizational changes required for success with SOA. This document takes the discussion a step further by defining what the target environment will look like when the change has taken place. The primary objectives for SOE are described below:

1. Enhance Mission Focus: The envisioned SOE will reduce redundancy and allow greater resources to be directed to achieving intended mission outcomes. Government transformation initiatives will result in more agile, policy-enabled, service-oriented organizations.
2. Increase Agility: The envisioned SOE has established aclear line of sight for impact of IT investments on business outcomes. This enables informed executive decisions to be made more rapidly and with more confidence. The business of managing change has been formalized and is continuously exercised and improved. Portfolio management addresses both service-components and enablingbusiness solutions. More parallel change initiatives can be carried out simultaneously without increased risk. Architectural considerations are prominent in investment decisions. Performance-based contracting has been enabled by a well-defined SOA. Standard enterprise SLAs, security models, and capabilities are leveraged across lines of business.
3. Increase Collaboration and Interdependency: The envisioned SOE has enabled program funding to be pooled to support effective enterprise services that can be shared at lower cost and delivered at higher quality. The agency has met its responsibility to share data and is actively participating in appropriate Communities of Interest (CoI). Improved federated governance models reward initiatives that share resources and disallow undesired redundant investments. Dependable service delivery, and standard trust models enable organizations to inter-operate with confidence. Consensus policies are established to manage the service life-cycle.

The National Information Exchange Model (NIEM) provides a glimpse of this future vision today. Driven by national security concerns in the wake of the terrorist activities of 2001, NIEM became a national priority, received requisite funding, and required the effective collaboration of many independent organizations. Today, NIEM serves as a leading example of a Service Oriented Enterprise. See Exhibit 3-3 for more information on NIEM.

To achieve these objectives federal government organizations need to behave differently. The desired organizational behavior is described below.

Management, IT and Business are All Service Focused

Enterprise architecture has provided a broad-based movement throughout the federal government to bring strategic planning, portfolio management, budgeting and capital planning, business process management, and IT management together to achieve the vision of “architect, invest, implement”. Exhibit 3-4 below shows a notional value chain for how these processes fit together.

Exhibit 3 4: Overview of Management Processes

Given the rapid maturation of federal organizations EA capabilities it is not difficult to imagine a time when federal organization EAs produce well-represented target architectures that define the strategic direction for the organization in terms of service capabilities supported by transition plans for migrating to the target architecture.

As these service-based target architectures, and plans improve and visibility into these plans increases, opportunities for efficiencies and sharing will manifest more clearly. As a resultFederal agencies will exhibit the following characteristics:

• Software-as-a-service (SaaS) will become a well established federal business model. Many services will be hosted under software-as-a-service contracts with vendors or other agencies.
• Portfolio management will become more focused and agile. Portfolio assessment will focus more on performance outcomes,service levels, integration with other services, and support for planned transformation initiatives.
• Performance measurement (PRM) will be enabled because the service architecture and will provide a clear line of sight from business value chains through the business capabilities, technology capabilities, and operational capabilities that support them. This will simplify the development of more accurate business cases.

Sustaining SOE through Federated Governance

It should be apparent that the federal SOA environment is quite complex, dynamic, and large in scale, involving many actors (for example, business process stakeholders, IT consumers and producers, vendors, programs, bureaus, offices, agencies, communities of interest, other departments and multiple levels of government) residing at a variety of intra, inter, and extra organizational levels. They must all interface with a host of management processes (see Exhibit 3-4), while providing sustained business output and outcomes. SOA decreases the barriers to distributed and federated collaboration and the relative ease required to engineer links among disparate vertical service oriented domains, i.e., ‘federation”, enables less onerous approaches to governance.

Because today’s government-wide policies increasingly require federal agencies to share services, it follows that a federated governance model is most appropriate to ensure that service consumer and provider needs are met across disparateorganizational boundaries.

In the Introduction above, we identified several major challenges:

• Absent or ill-defined target federal SOA environment that is consistent with enterprise architecture activities;
• Lack of guidance to promote, demote, and retire services through multiple tiers of actors;
• Inadequate enterprise-wide and cross-enterprise management and monitoring of web services; and
• A governance mechanism that facilities the interaction and commitment of actors;
• Funding processes that inhibit cross-domain, cross government collaboration.

These broad challenges reveal an underlying theme - interaction and essential, if not mandatory, participation of vested actors within and across multiple levels for common enterprise services as notionally illustrated in a SOA-centric view in Exhibit 3-5. Adding additional complexity is the relationship of business units and process “owners” such as the Communities of Interest (COI) with regards to direction andoversight of a particular service. As such, traditional IT governance archetypes tend to focus on one organization (there are of course exceptions) or while supporting complex organizations are themselves rudimentary. In any case, the relationships at each level for enterprise-services illustrated in Exhibit 3-5, will rapidly extend beyond the direct authority boundaries of the concerned organizations. In effect, the interactions at each layer are similar to a commercialalliance and taken altogether resemble a networked hierarchy or federation.

As we envision our target SOE, we expect to see standardized and proven bilateral and multi-lateral governance models become available. These will mature to include:

• Standardized contract language to assist agencies to procure business and IT capabilities;
• Standardized service level metrics andagreements;
• Effective funding models to support shared services and shared infrastructure;
• Procedures for holding service providers accountable for SLA terms;
• Portfolio Management models that focus on collaboration around common business and IT services.

Additional information on federated governance can be found in Section 4 - Keys to Implementation.

Model Based Acquisition Processes

Model based acquisition processes will leverage modeling standards and best practices to provide more accurate descriptions of organizational requirements in solicitations. In conjunction with service based target architectures, organizations will be able to substantially reduce the effort required to define their requirements and, because the requirements will be more precise and understandable, perhaps even testable, they will mitigate downstream risks of selecting vendors and contractors that do not sufficiently meet their needs. Model-based acquisition processes will also remove much of the guesswork for vendors and contractors, because the government’s needs will be more clearly understood. Model based acquisition processes directly support the business agility and agile recapitalization benefits of SOA, and as a result, will yield improved mission performance.

Model based acquisition processes leverage precise models developed in accordance with open modeling standards (e.g., UML, BPMN, and IDEF). Precise models reduce ambiguity, provide a more structured way to convey information, and lay the foundation for standardizedpatterns to evolve and be exploited. For a graphical depiction, see Exhibit 3-6: Modeling Service Orientations Example.

Exhibit 3 6: Modeling Service Orientations Example

Exhibit 3-6 Modeling Service Orientation example needs to be clearer; specifically inside the boxes, the components are not clear. It is hard for the reader to understand the relationship among different components under discussion.

Service Oriented Architecture (SOA)

The Service Oriented Architecture (SOA) is at the center of the Service Oriented Framework presented in Exhibit 3-1. The Service Oriented Infrastructure (SOI) is required to enable its operation and the Service Oriented Enterprise (SOE) is required to manage and govern it. The SOA is also the area in which federal chief architects and federal CIOs have the greatest ability to control the Target Architecture.

The three primary objectives for SOA are described below:

1. Provide line of sight traceability from mission to implementation. The envisioned SOA is driven by accurate, vetted business models. The business models are supported by a layered service architecture designed to automate and support the modeled business. Traceability is provided by tracking service dependencies.
2. Deliver agile, executable architectures. The layered service architecture is policy driven. Business policy is governed by the business, IT policy is governed by OCIO. The service portfolio is managed to increase andenable effective business and technology capability reuse. Architecture policy facilitates introduction of new technology capabilities, the use of 3rd party services, and the publication of services for external consumption. Recapitalization can and shouldoccur for individual service components.
3. Ensure semantic interoperability. Semantic interoperability is achieved by employing standard schema (or ontologies). These standard schemas are developed through data modeling methodologies to ensure that the data are complete and consistent. Schemas are published to the collaborating community by an authoritative source (e.g., government authority, standards body, or COI). Modifications to the schema must also be vetted through the governance processes established by the authoritative source. Self service, on-demand interoperability test environments are available for the collaborators. Automated test scenarios must be passed to deploy to operational environments.

To achieve these objectives, federal government organizations will need to embrace SOA and change the processes they employ to manage and develop systems. The desired behavior is described in subsequent subsections, but before further discussion ensues, we should establish a reference framework.

An SOA Reference Framework

According to the Organization for the Advancement of Structured Information Standards (OASIS) Reference Model for Service Oriented Architecture, “Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. In SOA, services are the mechanism by which needs and capabilities are brought together.”

Let’s examine an example enterprise from the service perspective. Exhibit 3-7 shows a sample model of the US Patent and Trademark Office (USPTO). The exhibit shows that USPTO delivers Intellectual Property Protection services by delegating to either Trademark Services or Patent Services. Furthermore, it can be seen that both the patent and trademark service units consume financial services. While this example is an oversimplification, it highlights some useful characteristics of the service model. In this perspective, the USPTO responsibilities are clear. It delivers Intellectual Property Protection services by providing an effective environment for the three depicted government service units to collaborate. It also demonstrates the recursive nature of the service model. The service model applies at many different levels of granularity, from the largest federal government departments down to individual subsystems.

If we look inside a service oriented government service unit, we’d expect to see a service oriented architecture. By definition, that is an organized collection of distributed capabilities marshalled to effectively deliver higher order services.

Exhibit 3-8 presents a straightforward reference framework for a service oriented architecture. The top layer, Business Operations, and the bottom layer, Systems Operations are the only two operating aspects of the business. The other layers reflect a service oriented approach to organizing (architecting and designing) capabilities to support the business. The Composite Application Architecture assembles and orchestrates services to fulfill business operations while the service architecture presents useful services for assembly. The component architecture employs resources to deliver the business services.

Federal SDLC and EA are Integrated and Support SOA

Federal System Development Life Cycles (SDLCs) will be expanded to support both the solution development life cycle and the service life cycle. This will enable the agile recapitalization model by supporting solution delivery and service provisioning teams to work concurrently and more independently than conventional systems project teams. The Target SOA and supporting transition plans, as defined within the EA, will guide integration activities throughout the SDLC. Teams will stay synchronized by aligning to configuration management controlled service specifications. Project release plans will demonstrate how individual teams are executing the transition plans to converge on the target architecture. As projects progress through the SDLC, architecturally significant changes will be reflected in impacted EA work products.

With these changes in place, and once the operational service inventory grows, solution project teams will be able to rapidly deliver composite applications that better meet business needs, simplify business procedures, and enhance mission effectiveness because much of the technical complexity will now be the responsibility of the service provisioning teams. Solution delivery teams will be focused on providing intuitive user interfaces, stable business process orchestrations, and service choreographies; all developed in adherence to approved business semantic models.

Service provisioning teams will be responsible for delivering the services called for by the target architecture. They will provide the necessary services by incorporating legacy system capabilities, introducing 3rd party products and services, and through custom development where necessary. Furthermore, the service provisioning teams will ensure the consistency of data in disparate data stores and provide data aggregation services to the solution delivery teams.

SOA and Interoperability Will be Well Established

Communities of Interest (COIs) and Communities of Practice (CoPs) will use data modeling methodologies to develop standard semantic models (schema or ontologies) and approved choreographies. These semantic models will be established and changed only through a strong governance process. Each collaborator will have developed compliant services that map their business concepts to the community standards and fulfill their responsibilities in the collaboration. (See sidebar). These communities will comply with applicable Federal Reference Architectures (FRA). Proven reference implementations will be available for FRAs.

Standard Federal Government Services Will Emerge

As collaboration spreads through the federal government, best of breed common infrastructure services will emerge. Adoption of some common services across the federal government will start with infrastructure services (e.g., authentication, auditing) but quickly expand to business utility services (e.g., federal employee lookup, simple approval process, calendar services, scheduling).

In particular, the security services required to enable basic collaboration and information sharing are already in demand. Fully compliant security best practices will be formalized and integrated into management processes, governance, and the SDLC, so that a formal definition of security requirements based on enterprise policy is specified in accordance with a standard federal model. Service registration discovery and delivery protocols that include requirements for Single-Sign-On (SSO) authentication, authorization, audit, confidentiality and integrity will be integrated into a standard federal government security service that can be delivered over a network.

Today, the IT Infrastructure Line of Business (ITI LoB) serves as the umbrella, a cross-agency initiative driving agencies toward a unified federal SOI.

Model Driven Architecture Will Be Embraced

As SOA, Business Process Management (BPM), and model driven architecture (MDA) converge, federal EA best practices will evolve to exploit them. MDA provides a set of guidelines for structuring specifications as standard models. Transformation techniques are then employed to enable automated generation of systems and services compliant with specified reference architectures.

As the convergence of MDA and BPM continues, it will enable the development of platform-independent models (PIM) expressed in domain specific languages to create executable business process models. BPM capabilities already provide the capability to design, simulate and test business services in business context before they are deployed.

Service-Oriented Infrastructure

The natural result of a Service Oriented Enterprise applying Service Oriented Architecture to enable its objectives is a functioning collection of services resting on a service-based platform. The platform is the Service Oriented Infrastructure (SOI) which provides more than just the communications environment that enables service-based integration. It also provides the capability to register, locate, and deploy services as well as monitor and manage the service architecture.

The objectives for the envisioned SOI are described below:

1. Provide a secure, reliable, resilient infrastructure: The envisioned SOI provides a reliable, flexible, policy driven platform to enable the target SOA. SOI services are centrally managed and used consistently in support of cross domain integration. A standards-based security/trust and semantic model enables trusted delivery of valuable information between organizations. Resilience capabilities are designed into the infrastructure (e.g., COOP, IOI, COG).
2. Operate to Quality of Service (QoS) needs: The envisioned SOI will provide one or more inter-operating environments that support the full range of enterprise QoS needs within a reasonable budget.
3. Automate service development, deployment, and operations management: Service lifecycle runtime tools and platforms are mature and established in federal agencies.

To achieve these objectives, federal organizations will need to change their current development and operations practices. The desired behavior is described below:

Service Management is Coordinated Throughout the Federal Government

Service registries (and/or repositories) will be organized and coordinated so that service consumers can identify and locate candidate reusable services. Service registry/repository management will have to mature as an important aspect of the configuration management and operations disciplines. Processes will be developed to allow useful services to be promoted so that they are available across a broader scope. Either central management or sophisticated protocols will be established to enable the varied collaborative environments to be coordinated. The registries will provide sufficient information for consumers to determine whether a service will fulfill their requirements.

Adaptive embedded testing and certification will enable agencies to deploy and consume service based capability with confidence and federated registries will enable registered services to be identified across the entire federal government.

Increased Collaboration with 3rd Parties

Federal IT infrastructure will comply with SOA standards to enable federal government business partners and collaborators to interact with agencies in real time. As service best practices are adopted, the government will be able to extend their value chains to their partners including State, Local and International governments, business partners, associations, and citizens themselves. One example of this currently under development is the Nationwide Health Information Network, which defines a set of common services to be used by both public and private sector organizations to exchange electronic health record data with trusted partners. [i]

The envisioned SOIs will be inter-operable, efficient, secure, robust, modular, composable platforms for service execution. When broadly adopted and mature the envisioned SOI will support the following:

• Standard, composable middleware adapters (e.g., JBI, SCA and their successors) as the primary means of automated integration across organizations;
• Infrastructure services and adapters to dynamically enforce policy for security, interoperability, and quality of service;
• A set of fully compliant security-based services will intrinsically support solutions. For example the SOI will provide solution architectures with standard services that provide: single sign-on, access control, identity management, and consolidated user profiles; and
• Scalable Federal IT infrastructure.

Tool sets to Manage the SOI

The envisioned SOI will be supported with robust development, deployment, and operations management tools including:

• Service Registries and/or repositories to manage the service lifecycle and service meta data;
• Service management tools to monitor SLA compliance and security breaches and anomalies;
• Message translation accelerators (e.g., for XML);
• Application, service, and business monitoring tools;
• Modeling tools;
• Testing tools;
• Activity logs that log each invocation of a service; and
• Tools to implement policy enforcement.

Keys to Federal SOA Implementation [Document Section 4]

As previously discussed, the primary objectives of a federal SOA are to:

• Improve Federal agility – the ability of agencies and the federal government as a whole to rapidly respond to new and unforeseen circumstances as a consistent and inter-operable enterprise;
• Simplify the delivery of government services; and
• Improve the efficiency of government.

This section highlights some keys to implementing SOA within a federal government organization. Each key highlights an area that warrants consideration by a chief architect. The chief architect should assess each of the “Keys to Implementation” presented to determine its applicability to their organization. For those that are applicable, the architect should ensure that their agency’s SOA strategy effectively addresses the identified issues.

We recommend that an agency develop a service oriented architecture by first determining its business objectives. Once these are determined, the agency should map them to enable business and technological components to be organized in a layered service architecture keeping in mind the following principles:

• Define mission critical business objectives and design the business processes to achieve those objectives. From there, determine what services best support those processes;
• Establish these services as a primary aspect of your enterprise target architecture; and
• Leverage change management best practices and proactive governance techniques to reorganize IT delivery around these services.

The full benefits of SOA are enabled when the organization is positioned to incrementally replace its IT assets in line with its most critical business objectives. In effect, the organization through its SOA, creates the agility necessary to rapidly re-focus its IT investments as business objectives change.

The keys to implementation presented here are organized along the same perspectives defined in the Target Architecture section: SOE, SOA, and SOI.

Keys to Implementing the Service-Oriented Enterprise

Establishing the service-oriented enterprise is perhaps the most difficult aspect of SOA because it challenges many of the conventional business practices employed today. This section highlights key enterprise changes necessary to enable the benefits from SOA.

Treat SOA Adoption as an Organizational Change Initiative

The experience of the past few decades has shown that organizational change is difficult. For it to succeed, several things must be in place:

• There must be a compelling reason to adopt the change. That reason must be effectively articulated within the organization;
• The executive leadership of the organization must be solidly behind the change initiative;
• It must be treated seriously – create a program to oversee and manage its rollout, stakeholder objections must be addressed, etc.;
• For a cross-cutting initiative such as SOA, often a central coordinating group, or center of excellence (COE) is required; and
• Adequate resources to support the initiative must be allocated to sustain the change.

Obtain Executive Support

Significant change initiatives require strong support from executive leadership. This typically only happens when there is a compelling need to make the change and the senior management of the organization understands the need and drives the change.

Many federal agencies are already at this point. Executive management understands the need for greater responsiveness – as delivered through increased agility – and is frustrated by the reliance on outdated, rigid software applications. SOA offers the opportunity to incrementally reengineer the agency to achieve the desired flexibility.

Change initiatives succeed when organizational passions are re-channeled to achieve well articulated goals consistent with those passions. Our advice is to downplay the SOA hype and buzzwords, and concentrate on the targeted business outcomes. Therefore, the task for senior management is to carefully define and articulate the goals and establish associated progress metrics that the rest of the organization can rally around.

More importantly, senior management must sustain this level of support for the time necessary to make the change happen. The chief architect is responsible for demonstrating how to apply architectural best practices to achieve the desired business outcomes. Having a service oriented Target Architecture enables the chief architect to define and articulate individual business solutions that clearly address today’s business challenges and business goals, while also incrementally enabling a strategic architectural vision.

Critical Success Factors:

• Understand today’s business challenges.
• Conceive a service-oriented Target Architecture Vision for the enterprise.
• Effectively, but rapidly, model business objectives, processes and information that support the Target Architecture.
• Architect and articulate solutions that solve today’s business challenges, while at the same time advancing the Target Architecture vision.

Establish a Program Plan for SOA and Measure Results

Meaningful change requires a well thought out approach. Our recommendation is to treat SOA as a “program” – not in the sense of another stovepipe, but rather as a serious cross-organizational initiative – with a plan, a champion or manager, and defined results that can be measured. Specifically, the natural place for executive sponsorship is shared between the CIO and the mission or business owner associated with a specific high(est) priority initiative with enterprise scope. The program manager or champion should be the chief architect or chief technology officer, depending on specifics of the individuals, the organization of the IT function, and the ongoing IT planning and architecture activities and functions that are to be leveraged. This last point is key; we are not recommending an additional freestanding planning and architecture activity, we are recommending leveraging existing activities – enhance and extend - and focusing them within the guidance of this document.

The establishment of a “program” entity does not reduce the power of collaboration at the individual organizational level that SOA facilitates, but it does help to provide strategic direction and focus to the SOA effort. We feel that the establishment of a program structure from the top, as described above, must be combined with the bottom-up efforts that are naturally occurring within the organization to insure an effective implementation. The focus of the program should be on enterprise and segment architecture, identifying and prioritizing services, and supporting governance activities that channel demand to reusable services.

The program should leverage and align existing activities such as enterprise architecture or technology test and evaluation laboratories. More importantly, the program should work with existing DME (development, modernization, enhancement) programs (i.e., Exhibit 300 identified services) and projects for solution architecture and implementation activities.

A measurement strategy is an important component of any change management initiative, but is particularly important to the SOA implementation. We recommend that agencies use a goal-based measurement process that focuses on finding meaningful measures for monitoring the progress of SOA initiatives.

Generally, there are three tiers of performance analysis: project, program, and enterprise. The project objectives are to develop, integrate, and deploy useful services that solve real business problems. While developing these tiers, keep in mind the following guidance:

• Project performance outcomes are the inputs to program performance analysis.
• The program objectives are to enhance productivity and efficiency by evaluating, procuring, and managing services shared across projects.
• The program performance outcomes are the enterprise performance analysis inputs.
• The enterprise objectives are to enhance productivity and efficiency by evaluating, selecting, and controlling services shared across programs.

Agencies are constantly required to make IT investments to field new and better operational capabilities. Accordingly, they need meaningful metrics and benchmarks that allow them to monitor progress and make adjustments to ensure desired outcomes are achieved. A dashboard is a useful mechanism for presenting stakeholders a number of key indicators chosen to link SOA-enabled business and technology initiatives with business/mission performance targets.

Establish an SOA Center of Excellence (COE) to Oversee Adoption

For cross-organizational initiatives, a best practice is to establish a coordinating committee, or center of excellence (COE) of knowledgeable individuals from across the organization and augmented with experienced SOA practitioners. The purpose of the COE, which may be established within an agency’s existing EA program/governance structure (see Federated Governance discussion, below), is to set direction, draft policies, develop/adopt methods, and oversee the development/execution of the service portfolio plan. An additional purpose is to elicit participation and buy-in from the organizational and stakeholder components.

Across the Federal space, maturity with EA implies organizations have architecture review boards and subordinate architecture working groups. The recommendation is to use that framework where it exists and extend it explicitly to SOA and the related concepts in this document. Further, agencies should be looking to participate in the AIC Services subcommittee, other like cross Federal organizations and entities, and external standards bodies to insure Government-wide alignment and adoption of external best practices.

While the creation of a COE is not a mandatory activity, it is strongly suggested because without a COE, or some other like mechanism that is responsible for implementing SOA Governance on a day to day basis, the SOA implementation has a greater likelihood of failure. The responsibilities of the COE can be added to the responsibilities of an existing governance board or mechanism. Here are the responsibilities of the COE:

Governance

• Define and implement SOA governance and management processes

• Disseminate governance information throughout the organization

• Maintain vitality of SOA governance processes

• Maintain SOA Principles and Standards

• Enforce compliance with SOA processes, principles and standards

Thought Leadership/Visioning

• Act as thought leadership center for SOA governance and management process

• Create new governance and management processes

• Investigate new technology

• Provide direction and vision for SOA

• Deliver education and training and provide mentoring

Expert SOA skills and resources

• Provide SOA leadership and experienced resources to project teams

• Champion best practice approaches

• Mentor project team members

Knowledge management and harvesting of assets

• Define documentation standards

• Identify and generalize project level artifacts

• Identify new and update existing best practices

• Maintain repository of sample project artifacts

Appropriately Plan and Fund the Change Initiative

In order to initiate and sustain any change initiative, sufficient on-going planning, funding and resource allocation must occur. Another challenge for an SOA-based implementation is funding the necessary infrastructure, which can represent a large expense that is not easily associated with a specific program. Organizations need to identify a means to align continuing enterprise infrastructure funding with the needs of the SOA implementation. Given the scope and importance of the targeted initiative, it is reasonable to build these incremental costs into its business case. The amount of funding necessary depends on the maturity of the organization, its strategy for implementing SOA and its overall objectives. In addition, while highlighting the full cost via an integrated business case, it is important to capture the benefits as outlined elsewhere in this document.

For more mature organizations, SOA reuse and agility result in cost savings. Organizations need to plan proactively to identify and harvest the savings – for reinvestment in additional SOA capabilities, to enable additional mission or business performance improvements, or to reallocate resources outside IT. A significant integration of SOA into an agency environment can take a long time. It may be years before the point of cost savings through reusable services can be reached. Once it is reached, savings can grow exponentially.

Our recommendation is to highlight the full scope of costs and benefits by leveraging the agency EA through segment architectures. This approach will highlight overall opportunities for reuse, information sharing, reduced duplication, and overall cost effectiveness as well as clearly delineate the full spectrum of investments required and how they interrelate. It will produce a full and proactive picture of the federated governance structures required, and how they relate to existing governance bodies and processes. Perhaps most importantly, by leveraging natural partitions evident via the architecture, the implementation challenges can be decomposed into a smaller number of lower risk steps that form a natural roadmap to the target outcomes.

Build Community Processes and Collaborative Platforms

Many of the benefits of SOA are derived from sharing – sharing information, sharing business processes, sharing reference architectures, and sharing services. As a result, a mechanism must be put into place to enable the collaboration that is necessary to establish standards for sharing. One potentially effective mechanism for collaboration in the federal government is the Community of Interest (COI) model where participants from a particular domain (horizontal or vertical) come together with sufficient resources to establish the basis for sharing. The typical issues dealt with include semantics, standards for exchange, platforms, etc. To be successful, a COI must have a governance mechanism, sufficient funding, and portfolio management oversight, and must provide a collaborative environment for authorized users. The COI should also have defined operating processes, including a process for resolving conflicts and arriving at collaborative decisions. This process may include agreements based on consensus, a majority vote of the members, or other procedures that are agreed to by the members.

Establish Federated Governance

Effective governance recognizes that it is not just about control, policing, and enforcement functions – it is also about providing essential services. Likewise, governance has jurisdictional boundaries, both within programs, at the enterprise level, and beyond. For this document, we adopt the following definition of (IT) governance: “Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.” [Weill, 2004] Agencies must clearly establish governance charters, statements of scope, and areas of responsibility for specific organizational elements within the governance structure. In Section 3, the need for SOA governance was established and specifically the need for federated SOA governance. What does a federated governance model look like and how is it different from a non-federated model?

Weill and Ross [Weill, 2004, p.61] define federated IT governance as “…coordinated decision making involving both the center [central authority] and the business units,” suggesting a two tiered vertical model that shares power in some manner. However, this concise definition does not accurately convey the principles of federalism based on a multi-tiered environment (see Exhibit 3-5). Within the context of the federal government, federated governance deals with semi-autonomous, but interconnected, organizations (at multiple levels) coordinating their efforts through a centralized mechanism.

To be effective, the central authority should have the capabilities to effectively carry out the responsibilities delegated to it by the federation. This includes overseeing the establishment of standards and resolving conflicts, and providing the necessary resources, including funding and staff, to effectively operate. While the members of the federation retain their individual program authorities, they give up some control to the centralized authority to create the shared value that each seeks through the federation.

At this point, the discussion has focused on actor