SOLICITATION NOTICE
70 -- Request for Information Service Oriented Architecture (SOA) Software
- Notice Date
- 10/5/2004
- Notice Type
- Solicitation Notice
- NAICS
- 519190
— All Other Information Services
- Contracting Office
- Defense Information Systems Agency, Procurement and Logistics, DITCO-Scott, P.O. Box 25857, Scott AFB, IL, 62225-5406
- ZIP Code
- 62225-5406
- Solicitation Number
- Reference-Number-RFIGovernanceSW
- Response Due
- 11/5/2004
- Archive Date
- 11/20/2004
- Description
- 1. Introduction. The Defense Information Systems Agency (DISA) is considering the introduction of state of the art Service Oriented Architecture (SOA) Governance Software products to support the publication of Net-Centric Enterprise Services (NCES) and Core Enterprise Services (CES) including but not limited to: application, collaboration, messaging, discovery, storage, content staging, enterprise service management, and security on the Global Information Grid (GIG) infrastructure. DISA is seeking information from industry on state of the art SOA Governance Software products capable of supporting the publication of all NCES and CES, which include but are not limited to application, collaboration, messaging, discovery, storage, content staging, enterprise service management, and security to ensure that DISA has considered all available commercial-off-the-shelf (COTS) products that provide this capability. This Request for Information (RFI) includes but is not limited to: SOA Governance Software products which include but are not limited to: Simple Object Access Protocol (SOAP) and Web Service Description Language (WSDL), etc? analysis and compliance checking, policies, best practices, management tools, metrics, etc. All software manufacturers and suppliers of SOA Governance software are offered this opportunity to provide their product information to DISA for review, analysis and consideration as an SOA Governance tool for the GIG NCES and CES architecture. In order to ensure continued operations, reduce integration costs and complexities, limit liability and security exposure, and effectively complete all missions DISA requires a software mechanism to help govern the design, development, deployment, and operations of all services for the GIG NCES and CES architecture. 2. Background. SOA Governance is the ability to ensure that all design, development, deployment, and operation of services meet enterprise SOA Governance capabilities. Several elements must be in place in order to achieve SOA Governance: 2.1. SOA Enterprise Policies: SOA policies are the cornerstone of SOA Governance. Without policies there is no Governance. Policies are the set of goals, which direct and measure success. Policy Makers including CTO?s, CIO?s, Managers, Architects, Project Leaders, and Enterprise Application development leaders are struggling to define, configure, and assign enterprise polices in a way which allows development teams to easily and transparently adhere to new policies. In addition, policies need to be addressed based on the business impact to the operations, and also the reliability required of the services created. SOA Governance policies are an evolving entity. As infrastructures change with new technologies, standards, services, business processes, and clients new policies will need to be created and old policies will need to be changed or retired. 2.2. Auditing and Conformance: Developers, Architects, and Project Teams need the ability to conform to enterprise policies through an automated system that provides them with easy methods to capture requirements, recommendations, and best practices in their language. A set of software components that enables them to detect, analyze, and audit compliance with enterprise policies transparently by integrating with the Service Development Life-Cycle (SDLC) as well as with other operational processes. 2.3. Integration: When policies are defined and conformance processes are in place SOA Governance is realized. Decision makers shall govern implementation, encourage reusability, manage collaboration processes, and improve business metrics. These are the value added aspects of integration. The integration of SOA Governance has two aspects: 2.3.1. Process Integration ? has to be integrated with the current flow of enterprise development and with the tools and systems available in order to keep service implementations in conformance with enterprise policies through the design, development, testing, implementation, deployment, and maintenance phases. 2.3.2. System Integration ? needs to be integration capable with Enterprise Application Integration (EAI), development tools, and other enterprise applications that are producing services in a transparent manner. Conformance should be transparent and simple for the teams in the field. 3. Requirements/Capabilities: SOA Governance software represents a change in the way services shall be developed and deployed on the GIG NCES and CES architecture. DISA shall change from ?Develop now, Integrate later? to a ?Develop for Integration? paradigm. The new paradigm, combined with the technologies and standards created to support the paradigm shift shall help DISA implement SOA Governance efficiently and effectively. 3.1. SOA Governance software products will be categorized using the following classification (these are listed in preferred order of priority): 3.1.1. Current state of the art SOA Governance software in use today. As used here, current refers to software that is installed and operational for at least one customer. 3.1.2. Imminent release SOA Governance software available today, but not necessarily fielded in an operational network to date. 3.1.3. Announced SOA Governance software products and other forward-looking statements or documents. 3.2. The SOA Governance Software shall have, but not be limited to, the following: 3.2.1. An existing database of current policies and best practices from which to choose. 3.2.2. The capability to add, modify, delete policies and best practices. 3.2.3. Extensible Markup Language (XML) schema, Simple Object Access Protocol (SOAP) and Web Service Description Language (WSDL), etc? analysis, compliance checking and error correction feedback. 3.2.4. A management tool with the capability to display performance metrics. 3.2.5. Enforce conformance to the policies selected. 3.2.6. Conform to accepted application program interfaces (API). 3.2.7. Scalable, Portable, Adaptable, etc? 3.2.8. The capability to govern a single Universal Description, Discovery and Integration (UDDI) register and multiple distributed UDDI registries. 3.2.9. Be easy to use, fully automated and transparent to the users. 3.2.10. Not be system resource intensive or intrusive. 3.2.11. The capability to grant policy control to individuals, groups, domains, etc? and be overridden automatically. 3.2.12. Identify policies and best practices for development guidance for the enterprise. 3.2.13. Identify interfaces that are not compliant. 3.2.14. Identify services in use or those that exist within the enterprise. 3.2.15. Identify reusable services and interface components. 3.2.16. Identify changed and new policies. 3.2.17. Collect information on each UDDI registry independently and combine the data creating an enterprise view. 3.2.18. Display a global view of the enterprise by organization and function. 3.2.19. Generate and grant exceptions to policies. 4. Definitions. The following definitions are provided: A. Service Oriented Architecture (SOA): A system for linking resources on demand. In an SOA, resources are made available to other participants in the network as independent services that are accessed in a standardized way. This provides for more flexible loose coupling of resources than in traditional systems architectures. B. Governance: Governance of services is the institutional framework in which the integrity of a service interaction or set of related service interactions is decided. The term therefore refers to the set of laws, procedures and common practices that determine the ability of exchange partners to take decisions with respect to their exchange relationship. The system and structure for defining policy, providing leadership, and managing and coordinating the procedures and resources that ensure the quality of all software application services in a service oriented architecture enterprise. C. Auditing: A service that reliably and securely records security-related events producing an audit trail enabling the reconstruction and examination of a sequence of events. Security events could include authentication events, policy enforcement decisions, and others. The resulting audit trail may be used to detect attacks, confirm compliance with policy, deter abuse, or other purposes. D. Conformance: An affirmative indication or judgment that a product or service has met the requirements of the relevant specifications, contract or regulation; also the state of meeting the requirements. [ANSI-ASQC Standard A3-1987] E. Integration: The ability of applications to share information or to process independently by requesting services and satisfying service requests. In a well-integrated system, all of the parts have a purpose, and the parts combine effectively to achieve the purpose of the overall system. F. Enterprise: In the computer industry, an enterprise is an organization that uses computers. A word was needed that would encompass corporations, small businesses, non-profit institutions, government bodies, and possibly other kinds of organizations. In practice, the term is applied much more often to larger organizations than smaller ones. A large-scale, organization wide computer network that may include web-based, client-server, and mainframe computing technologies. An enterprise is an organization that uses computers, but usually implies a larger organization. 'Enterprise Testing and Performance' involves testing the entire Web infrastructure of an organization to ensure optimal performance of Web-based applications. 5. Questions. The following questions are provided: 5.1. General: 5.1.1. Can policies be tailored and/or modified in the software? 5.1.2. Can policies be extended and/or added to the software? 5.1.3. Can the software enforce conformance to policies? 5.1.4. Can the software identify policies and best practices for development guidance? 5.1.5. Is the software easy to use (ease of use) and function in accordance with accepted application program interface (API) standards and specifications? 5.1.6. Is the software fully automated? 5.1.7. How many personnel are require to integrate, manage and operate the software? 5.1.8. Is the software system architecture intrusive? 5.1.9. Is the software scalable (scalability)? 5.1.10. Is the software system resource intensive (performance)? 5.1.11. Is the software portable (adaptability)? 5.1.12. Is integration of the software difficult? 5.1.13. What are the software dependencies and interdependencies? 5.2. Enterprise SOA Policies: 5.2.1. How does the software set SOA development policies for the enterprise? 5.2.2. Can SOA common issues and best practices be implement in the software? 5.2.3. Can software policy control be given to separate groups? 5.2.4. Can the software policies be set and then overridden automatically? 5.2.5. How many policies are there in the software? 5.2.6. Where are policies implemented in the software? 5.2.7. Can software policy control be given to an individual? 5.2.8. Can software policy control be given to a domain? 5.3. Auditing and Conformance: 5.3.1. Can the software ensure that services being published adhere to development policies? How is this checked? 5.3.2. Does the implementation of SOA Governance cause a change in development practices? 5.3.3. Do developer?s have flexibility to publish products? 5.3.4. Are conformance levels of security policies identified in the software? 5.3.5. Are interfaces that are not compliant identified? 5.3.6. Does the software collect and display auditing and conformance statistics and metrics? 5.3.7. Does the software impact noncompliant services? If so, in what way? 5.4. Management: Track, Review and Improve policies and services: 5.4.1. Does the software identify services currently in use or those that exist within the enterprise? 5.4.2. Does the software identify services that developer?s can reuse and services that are being published? 5.4.3. Does the software identify reuse opportunities? 5.4.4. Does the software identify reusable services and interface components? 5.4.5. Does the software identify changed policies and newly introduced policies? 5.4.6. Does the software collect information on each UDDI registry independently and then combine the data for an enterprise view? 5.4.7. Does the software collect and display metrics indicating adherence to policies and improving the enterprise. How is this displayed? 5.4.8. Does the software have the capability to display a global view of the enterprise by organization and function? 5.4.9. Can the software grant exceptions to policies? 5.4.10. What impacts do exceptions have on services? 5.5. Integration: 5.5.1. Can the software be used to govern a distributed set of UDDI registries? 5.5.2. How does the software fit into the system architecture (Web Service Management integration, Development tools, etc.)? 5.5.3. Are there integration points that can be taken advantage of (i.e. LDAP, Project Management, Application Inventory, etc?)? 6. DISCLAIMER. THE GOVERNMENT DOES NOT INTEND TO AWARD A CONTRACT ON THE BASIS OF THIS RFI OR TO OTHERWISE PAY FOR INFORMATION RECEIVED IN RESPONSE TO THIS RFI. However, this RFI will be the basis for collecting information on products available and as a result of information received, the government may enter into Product Loan Agreements for trial and testing of products identified. This RFI is issued for information and planning purposes only and does not constitute a solicitation. All information received in response to this RFI that is marked Proprietary will be handled accordingly. The Government shall not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Responses to the RFI will not be returned. Whatever information is provided in response to this RFI will be used to assess tradeoffs and alternatives available for determining how to proceed in the acquisition process for the SOA Governance products. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract. 7. CONTACT INFORMATION. 7.1. The Technical Point of Contact (POC) for this RFI is: Mr. Robert DeVenny, Phone: (703) 882-1118. 7.2. Please submit one soft copy (preferably on compact disk (CD)) in MS Word format to, DISA, Code NE221, 5275 Leesburg Pike, Falls Church, VA 22041-3801. 7.3. The Government may request additional information or discuss information received in responses to this RFI with individual responders.
- Place of Performance
- Address: Falls Church VA
- Zip Code: 22041
- Country: USA
- Zip Code: 22041
- Record
- SN00688998-W 20041007/041005211535 (fbodaily.com)
- Source
-
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |