What is your e-mail address?

My e-mail address is:

Do you have a password?

Forgot your password? Click here
close

SPECIAL REPORT: Service Oriented Architecture

SOA Improves Services [Online bonus material]  
*Architecture: A 12 Letter Word For Having A Plan
*Establishing Common Ground
*SOA: Health Care Enabler
*SOA: Evolving Challenges
*Governing Principles
*SOA Improves Services [Online bonus material]

*SOA: Service-Oriented Architecture [PDF]
Below are excerpts from the Practical Guide to Federal Service Oriented Architecture (PGFSOA), published in June 2008 by the CIO Council in collaboration with the American Council of Technology and the Industry Advisory Council.

 

SOA and Enterprise Architecture

 

SOA does not replace Enterprise Architecture (EA). 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.

 

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.

 

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.

 

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 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 Architecture

Establish a service oriented infrastructure that addresses security/privacy, scalability, and interoperability. In particular, leverage secure virtualization approaches to clearly 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.

Source: Excerpts from A Practical Guide to Federal Service Oriented Architecture, June 30, 2006