Rationale

From PGFSOA Wiki

Contents 1 The Rationale for Federal SOA [Document Section 2] 1.1 Enhancing Mission Effectiveness 1.2 Continuous Innovative IT Asset Re-capitalization 1.3 Cross-Domain/Cross-Agency Trust, Data Access, and Semantic Interoperability 1.4 Leveraging IT Investments across Federal Agencies and Sharing Best Practices

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.