4.1.12: Procurement
Practice Service-Based Procurement Other Information:
Service-based procurement is the logical successor to the concept of incremental development and a service-oriented SDLC.
While the current acquisition environment (based on the Federal Acquisition Regulations (FAR)) does not explicitly describe
a service-based approach to procuring IT assets, we believe that all of the necessary acquisition steps required can be undertaken
within the FAR framework. For example, the FAR does encourage procuring managed services in general when it is in the government’s
best interest. As discussed above, agencies should adopt policies that encourage vendor competition around service models.
Accordingly, contract incentives and penalties should revolve around SLAs that address both the frequency of software capability
refresh and associated target business outcomes. Service-based procurement has the following elements: Procurement strategy:
Services form the basic building blocks for solutions and should be procured separately from the integration of the services
into solutions. From the service portfolio plan, which identifies all of the required services within a particular domain
or segment, services with a common purpose should be bundled into defined solutions that can be described within procurement
packages. Because the IT industry is in the midst of a natural progression of increasing commoditization, this should be factored
into the procurement strategy. For commoditized capabilities, service procurement should be largely focused on Commercial-Off-The-Shelf
(COTS) products or third party services. Agencies should only invest to develop a specialized capability when commercial solutions
are unable to meet current government requirements. Requirements statement: Agencies should develop specifications for services
based on use cases, desired outcomes, performance criteria, etc. Where applicable, agencies should reuse specifications and
performance outcomes from industry, other programs, and other agencies. Requirements should be factored to reflect service
types that already exist in industry or government. Specifications should not be over-engineered. Agencies should use test
driven approaches to specification – define the tests that the successful service must pass and require vendors to demonstrate
that their services pass the tests. Let the potential service providers innovate and compete around your use cases. Requirements
should also address critical service management criteria such as quality of service adjustment over time, managing granularity,
SLA auditing and transaction control with events, warnings and alert notification capabilities, policy enforcement, advanced
security and authentication management capabilities. Government Furnished Equipment (GFE): License agreements for acquired
services should be defined to allow appropriate consumption of services across the federal government or the transfer of the
underlying software component to other agencies acting as service providers. In this manner, services can be made available
to programs/contracts as government furnished equipment. Reference architectures and implementations for domains/segments
should be made publicly available to industry and incorporated into RFPs. SOA, within the context of FEA, can help the federal
government identify the intended scope of use for products and services. Integration services: Contract with a service-oriented
systems integrator to integrate the services into business processes and composite applications. The integrator must possess
the necessary skills to work within the agency’s technical environment, including any middleware products, such as an enterprise
service bus (ESB). Certification of services: Establish a capability to test and certify services procured against the specifications
and requirements of your technical environment and desired business outcomes. Write these objective certification requirements
into your RFPs, contract SLAs, and task orders. This can be accomplished through the Services Development, Test and Evaluation
Laboratory discussed above. Services source selection board: Include operational customers and representatives from independent
industry expert bodies in addition to the representatives from the COI. This representation should be agreed upon by the COI
members. Wrap legacy application transactions: Agencies should contract with operations and maintenance contractors when they
have determined requirements for the service and the legacy application is best able to meet the requirement for the relevant
timeframe. Services management: Agencies should consider contracting to provide services management, including configuration
management, over the growing portfolio of services. Service execution management should include a real time monitoring capability
(e.g., dashboard) similar to those used by network operation centers. Advance institutional knowledge and capture best practices:
While the draw of SOA as a software paradigm is undeniable, each agency will travel this path at a different speed. Some agencies
will embrace the approach and move quickly down the path – encountering challenges and overcoming obstacles earlier than others
will. The spirit of SOA is sharing – not just sharing services: agencies should devote the effort to document their lessons
learned, abstract from implementations to reference architectures, document discoveries and patterns, and capture best practices
(or at least practices that have worked). Best practices are a set of actions that solve a problem critical to business success
most often found within organizations that excel against business and mission objectives. The capture of a “best practice”
is traditionally coupled with measuring via benchmarking. Benchmarking gauges performance against leaders and seeks to find
and describe practices that most heavily contribute. Christopher Alexander, who originated the notion of patterns in the field
of building (i.e., brick and mortar) architecture described patterns as a recurring solution to a common problem in a given
context and system of forces [Alexander 1979]. By advocating and supporting the collection and dissemination of best practices
and patterns, federal executives, architects, and developers can reduce the uncertainty and risk in determining when, where,
and how to apply SOA. The Federal CIO Council and GSA have already created a vehicle for sharing best practices, services,
architectures, templates and many other artifacts that can be used to give organizations a “jump start” in SOA. The Core.gov
website is a collaboration environment designed to facilitate sharing and communication. Agencies should look to leverage
this resource and in the spirit of sharing should contribute to it as well.
Indicator(s):
|
