Introduction
From PGFSOA Wiki
Contents |
[edit] 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.
[edit] 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 (see for example [Chappell, 2004]), Repositories and Registries, Composite Applications, and Component-Based Architectures [Sprott, 1999]. One of the purposes of this document is to clarify the many related concepts and technologies 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.
[edit] 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):
- Lack of an operational or target model for federal enterprise-wide SOA environment;
- Lack of understanding and experience in implementing SOA at the agency/department-level;
- Lack of procedures/guidance for consuming enterprise services in lieu of local services; and
- 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.
[edit] 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.
[edit] 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.
