Executive Summary
From PGFSOA Wiki
Contents |
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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. |
[edit] 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.
