MINISTRY OF INFORMATION AND COMMUNICATION TECHNOLOGY (MOICT) REQUEST FOR PROPOSAL (RFP) EDGE ENTERPRISE SERVICE BUS SOLUTION

Transcription

1 MINISTRY OF INFORMATION AND COMMUNICATION TECHNOLOGY (MOICT) REQUEST FOR PROPOSAL (RFP) EDGE ENTERPRISE SERVICE BUS SOLUTION JORDAN E-GOVERNMENT PROGRAM\MOICT P.O.BOX 9903 AMMAN JORDAN DATE: 26/7/2015 PROPOSAL DEADLINE: 12/8/ /ح ك / 2102 NO: RFP 1

2 TABLE OF CONTENTS SECTION 1: INTRODUCTION RFP PURPOSE RFP ORGANIZATION PROJECT DEFINITION AND DESCRIPTION CURRENT SITUATION PROJECT DEFINITION AND DESCRIPTION Definition and description Project Goals Overall Solution Description Expected value resulting from the project High level description of system characteristics Definition of required system and architecture SCOPE OF THE PROJECT COMPONENT 1 SYSTEM INSTALLATION AND CONFIGURATION COMPONENT 2: TRAINING AND KNOWLEDGE TRANSFER COMPONENT 3: OPERATIONS, MAINTENANCE AND SUPPORT COMPONENT 4: PROJECT MANAGEMENT COMPONENT 5 - QUALITY MANAGEMENT ADMINISTRATIVE PROCEDURES AND REQUIREMENTS RESPONSE PROCEDURES RESPONSE FORMAT RESPONSE SUBMISSION RESPONSE EVALUATION FINANCIAL TERMS CONFLICT OF INTEREST SECRECY AND SECURITY DOCUMENTS PROPERTY REMOVAL OR/AND REPLACEMENT OF PERSONNEL OTHER PROJECT-RELATED TERMS ANNEXES PROPOSED EDGE SOLUTION HARDWARE / SOFTWARE LIST CURRENT WEB SERVICES LIST PRIVATE CLOUD SPECIFICATION SERVICE LEVEL AGREEMENT REQUIREMENTS SUPPORT REQUIREMENTS: SEVERITY LEVELS: ESCALATION PROCEDURE AND PENALTIES: PREVENTIVE MAINTENANCE (PM) PENALTIES FOR DEFAULTING ON PM E-GOVERNMENT PROGRAM BACKGROUND AND IMPLEMENTATION FRAMEWORK TECHNICAL PROPOSAL RESPONSE FORMAT FINANCIAL PROPOSAL RESPONSE FORMAT CONFIDENTIALITY UNDERTAKING KEY RFP DATES AND DEADLINES SAMPLE ARABIC CONTRACT AGREEMENT Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 2

3 DISCLAIMER THIS DOCUMENT IS A REQUEST FOR PROPOSAL (RFP), AND SHALL NOT BE CONSTRUED IN WHOLE OR PART AS A DIRECT OR INDIRECT ORDER. IT SHALL NOT BE CONSTRUED AS A REQUEST OR AUTHORIZATION TO PERFORM WORK AT THE EXPENSE OF THE MINISTRY OF INFORMATION AND COMMUNICATION TECHNOLOGY (MOICT). THE INFORMATION IN THIS RFP IS INTENDED TO ENABLE BIDDERS TO FORMULATE A PROPOSAL IN RESPONSE TO THE PROJECT REQUIREMENTS SET FORTH. ALTHOUGH THIS RFP CONTAINS SUCH ENABLING INFORMATION, BIDDERS MUST MAKE THEIR OWN INDEPENDENT ASSESSMENTS AND INVESTIGATIONS REGARDING THE SUBJECT MATTER OF THIS RFP. MOICT DOES NOT GUARANTEE THE ACCURACY, RELIABILITY, CORRECTNESS OR COMPLETENESS OF THE INFORMATION IN THIS RFP. THE BIDDER REMAINS RESPONSIBLE IN RELATION TO IDENTIFYING ANY FURTHER INFORMATION THAT IS REQUIRED TO PREPARE THE PROPOSAL. THIS RFP SHALL CONSTITUTE PART OF THE CONTRACT THAT WILL BE SIGNED BETWEEN MOICT AND THE WINNING BIDDER. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 3

4 Section 1: INTRODUCTION 1.1 RFP Purpose The Ministry of Information and Communication Technology (MOICT) is soliciting proposals from qualified local IBM partners to provide an Edge Enterprise Service Bus (Edge ESB) solution for the e- Government program. The major project objectives are in line with e-government strategy and vision. Specifically, the solution must provide Edge ESB Solution that: 1. Enables the integration between services including Government-to-Government (G2G), Government-to-Business (G2B) delivery models in an architecture that will allow the government entities to exchange data through web services, and will enable the exchange of data between government entities and the non-government entities (non SGN connected businesses). 2. Serves as a fail over to the existing ESB solution. MOICT seeks a qualified local IBM partner bidder capable of providing functional requirements and demonstrating clear and comprehensive implementation framework and together with strong project management and leadership skills. The winning bidder will be responsible for successful delivery of the project within specified timeframe and has to follow agreed tasks and achieve desired goals and requirements so that the project is managed efficiently and effectively. Responses to this Request for Proposal (RFP) must conform to the procedures, format and content requirements outlined in this document. Deviation may be grounds for disqualification. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 4

5 1.2 RFP Organization This RFP provides the information to enable bidders to submit written proposals for the sought solution. The organization of the RFP is as follows: Section 1: Introduction This section outlines the RFP s purpose and its organization. Section 2: Project Definition and Description This section provides general definition of the project scope and a high level description of the solution to be implemented, Section 3: Scope of the Project This section defines scope of work, proposal requirements and deliverables for the Project. Section 4: Administrative Procedures and Requirements This section describes the administrative rules and procedures that guide the proposal and its processes. Section 5: Annexes This section includes all annexes to the RFP. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 5

6 2 PROJECT DEFINITION AND DESCRIPTION 2.1 CURRENT SITUATION One of the main outputs of the e-government is working to provide electronic services to ensure easy access to government services for all beneficiaries and through multiple channels. E-services are categorized into four main types: Vertical Service: Services that are provided through only one single government entity so that the service starts and ends in the same entity. Cross-Governmental Service: Services which involve more than one government entity in which recipient submits the service at a governmental entity and coordination is arranged with other government entities to complete transaction and to provide it to the citizen. Shared Services: Services which is being developed, centrally one time only and serve all government services. Shared services are named by shared for the possibility to share using this service from more than one entity. The e-government program has the responsibility for the development of these services. One of these shared services is the Enterprise Service Bus (ESB). Composite Service: the systems or applications and recurrent joint mechanism between the government and various sectors of the most important government resources planning systems (GRP). Examples include: financial systems, systems and personnel systems, procurement and materials management systems (stores and warehouses), and document archiving systems, etc. E-government is working diligently to utilize the existing shared and composite services, integrate related vertical services and integrate government systems through the proposed edge ESB Solution for the purpose of providing cross governmental services. Currently there are 20 providing web services from different governmental entities that are consumed through the current ESB solution by different governmental entities. A list of these web services and more details is provided in Annex 5.2 In many services provided by the government, the service recipients are required to provide/submit information/ document(s) issued at non-governmental entity(s) that completes government services such as Associations, Unions, and private institutions. To provide end-to-end services, it is essential for non-government entities to exchange such data electronically with government entities. Since nongovernmental entities are not connected to the Secure Governmental Network (SGN), data exchange between non-government and government entities is not supported due to the architecture of the current Enterprise Service Bus (ESB). 2.2 PROJECT DEFINITION AND DESCRIPTION In the following sub-sections the basic modules of the Edge ESB are described briefly. In sub-sequent sections each module will be examined in details Definition and description ESB is a middleware infrastructure that enables Service Oriented Architecture (SOA) by acting as an intermediary layer of middleware through which a set of reusable government services are made widely available. It unifies and connects applicable services, applications and resources within the government of Jordan and provides a framework within which the capabilities of a business' applications are made available for reuse by other applications by using standard web-services. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 6

7 ESB solutions help enterprises obtain the value of SOA by increasing connectivity, adding flexibility that speeds change, and providing greater control over use of the important resources it binds. The ESB pattern enables the connection of software running in parallel on different platforms, written in different programming languages and using different programming models. Service consumers connect to the bus and not the service provider that actually implements the service. This type of connection further decouples the consumer from the provider and allows for loosely coupled integration as advocated by SOA. ESB Solutions implements other value-add capabilities such as delivery assurance and security. It is preferable to implement such capabilities centrally using the ESB rather than within the applications that are distributed over the connected entities. However, the primary driver for an ESB is that it encourages decoupling between service consumers and providers. The proposed Edge ESB shall allow government entities to exchange information through web services using the SGN (G2G), and it shall allow government entities connected to the SGN to exchange information through web services with Non-SGN entities at the internet side (G2B). Non- SGN entities shall have the facility to publish information through the proposed Edge Solution to be consumed by SGN entities. It should as well be designed to enable integration with existing shared services systems (i.e. SGN, NCC System, SMS Portal, and National Portal etc.) that are used as consumers to the existing web services Project Goals The project has the following goals: 1. To increase the efficiency and effectiveness of the e-government program in delivering the concept of interconnected government for future and existing service on current ESB. 2. Govern the reusability of web-services and apply policies. 3. Having one out-of-the-box solution from a single manufacturer to cover the main functionalities (security, ESB, and governance) 4. Simplified configuration, maintenance and operational procedures in the least cost and efforts. 5. Migration of the existed web services configurations from the current ESB to the proposed edge ESB. 2.3 Overall Solution Description Expected value resulting from the project The expected value from the proposed Edge ESB Solution is to provide the following functionalities: Supply a communication layer to support service interactions through SOAP /HTTP(S) and Microsoft Windows Communication Foundation (WCF) that complies with technology standards as SOAP /HTTP(S) protocols are considered the main transportation protocols for the E-GAF, more details about the E-GAF can be found in Annex Supply content based routing. The proposed Edge ESB Solution must be able to route webservice messages based on the content. The web-service consumer shall always target the proposed Edge ESB Solution as its technical destination yet it shall include a logical destination ID within each message to enable the proposed Edge ESB Solution to invoke the target web-service. The proposed Edge ESB Solution then will validate (Identify, authenticate and encrypt/decrypt) the call and then rout the web-service request to the concerned service provider. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 7

8 This solution must also provide an intelligent routing mechanism where alternate routes are dynamically identified in addition to the traditional one. The implication is that any part of the proposed Edge ESB Solution network may shut down and become temporarily unavailable without affecting the integration network as a whole. Support the latest specification. WS-Addressing provides a uniform addressing method for SOAP messages traveling over synchronous and/or asynchronous transports. Support for following messaging styles: o Synchronous messaging: Where the proposed Edge ESB Solution will be responsible for routing synchronous Web service messages between the services consumers and service provider(s). The proposed Edge ESB Solution should maintain the synchronous conversational session between the consumer and provider(s) and should support and should provide configurable timeout. o Asynchronous messaging: Where the proposed Edge ESB Solution will be responsible for routing asynchronous Web service messages between the services consumers and service provider(s). The proposed Edge ESB Solution should maintain the asynchronous conversational session between the consumer and provider(s) and should support and should provide configurable timeout. o Publish/Subscribe: The proposed Edge ESB Solution should support this messaging style where it acts as a broker between the Publisher and the Subscribers. The Edge ESB must support the latest WS-Notification specifications. Support guaranteed delivery for the publish subscribe type of messages. The Edge ESB should provide guaranteed delivery functionality to web services consumers and providers without having the additional MQ component. The winning bidder should propose a solution to achieve this functionality. By this solution the Edge ESB will forward the pending messages to the destination once it is alive and functioning. In case the messages have a timeout period set then the Edge ESB should be configurable to choose not to forward pending messages that are expired. The Edge ESB should support the latest WS-Reliable Messaging specifications in order to allow messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures The Edge ESB must be capable to disallow duplicate messages. The Edge ESB should be able to verify the request and response conformance with the IIF standards. The Edge ESB should be able to support composition of messages and to transform message\data before routing them according to pre-defined criteria High level description of system characteristics The proposed Edge ESB Solution must include the following characteristics: Supports web-services standards Provide Web services registry Provide intelligent content-based & publish-subscribe routing functionality Support logging & monitoring Support access and identity management Support transaction management Support different messaging models (Synchronous, Asynchronous, Publish Subscribe models) Provide standardized security model to authorize, authenticate and audit use of the Edge ESB Provide data format transformation between the format of the sending application and the receiving application Provide validation against schemas for sending and receiving messages Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 8

9 Able to apply business rules, enriching messages from other sources, the splitting and combining of multiple messages and the handling of exceptions (that supports Messageoriented exception handling and Application publish exception messages) persisting message data when faults occur. Provides message propriety services that enable it to respond appropriately to higher and lower priority users or services Scalability, High performance and Incremental deployment Guaranteed messaging with multiple qualities of service Connectivity with a wide variety of enterprise applications and data sources through Web services and Adaptors. Interoperability across platforms and vendors in term of web services standards built on Java and.net technology that complies with technology standards. Composite applications, data synchronization, federated data queries, business activity monitoring, etc Definition of required system and architecture. The following diagram illustrates the proposed high level architecture design: Figure 2.1: Edge ESB Proposed High Level Architecture Design As shown in the above diagram, there are two (2) main components of the architecture of the proposed Edge ESB Solution: The Edge environment: representing the G2B zone that enables transactional messaging between entities outside the Secured Government Network (SGN) and governmental entities inside the SGN. This layer could be utilized to enable mobile applications to get data from published web services through a secured gateway. The SGN environment: representing G2G zone and through which messages are exchanged between governmental entities inside the SGN. The failover mechanism of the current ESB lies within this zone. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 9

10 Note that the winning bidder should utilize the Private Cloud in case there is a need to install additional Software on physical servers namely: SmartCloud monitoring, WSRR, and related components required for the successful implementation of the project. The winning bidder should provide a detailed architecture for the proposed Edge Solution based on this high level design showing all components/ Hardware and Software components needed. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 10

11 3 SCOPE OF THE PROJECT Important notes: There are certain activities to be performed and deliverables to be provided by the winning bidder during execution of the Project. More detailed information on each of them is given in the next paragraphs. The bidder shall provide the solution, in addition to knowledge transfer, training, support, maintenance and warranty, including any requirements or activities needed for the proper functioning of the system beside those outlined in the following listing and the cost of these requirements or activities should be included in the fixed lump sum price submitted by the bidder. Note that the bidders should detail in their proposals all recommended mechanisms and methodologies through which its services and deliverables will be accomplished. All the final documentation deliverables of the project are required to be prepared in English unless otherwise agreed upon with MoICT. The sign off and approval will be given on both Arabic and English language deliverables for the deliverables that are required bilingual. In case the documents differed due to translation, the Arabic documents shall prevail and will be considered as the official ones. Final deliverables submitted by the winning bidder should be attached to an original official letters properly bounded, stamped and signed by the winning bidder as shall be defined and approved by MOICT. Proposals submitted by bidders that do not properly describe an acceptable solution for the development of e-services delivery shall be rejected for being not responsive to the RFP requirements The required solution shall be deployed and configured at E-Government Operation Center at National Information Technology Center (NITC) The duration time for this project is (120) calendar days in addition to the 24 months for maintenance and support time. 3.1 Component 1 System Installation and Configuration Winning bidder activities Procure, install, configure and test proposed hardware/software components on the three proposed environments (G2G, G2B and Testing ESB) to be capable of supporting the business needs and requirements mentioned in section 2 above, please refer to Annex 5.1 for hardware components list Ensure the compliancy of the provided Edge ESB Solution with the proposed detailed solution architecture provided by the winning bidder after gaining required approval from MoICT Ensure high level of security for both production environments layers while giving more security measurement to the DMZ exposed layer (G2B) by activating the fully fledged security solution of the Edge ESB and through configuration techniques. Configure the existing 20 web services which are currently published on the existing production environment at the e-government Ops Center to the newly proposed Edge ESB solution. All current web services are built based on.net Technology, refer to Annex 5.2 for Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 11

12 more details about the list of web services required to be configured on the new proposed solution. Install, configure and test the proposed monitoring tools (Smart Cloud) on the e-government Private Cloud. Kindly refer to Annex 5.3 for more information about the e-government Private Cloud Ensure that the installation for the whole environment shall include the WSRR and SmartCloud on servers provided by MoICT Install WebSphere Transformation Extender Design Studio on two PCs provided by MoICT and configure the application and ensure that it is functioning as expected. Conduct system health check through IBM before go live (Manufacturer vendor) to ensure the proper installations, configuration and activation Fix all reported issues that might appear through the health check Implement the project roll out plan for the 20 web services, after gaining the required approval from MoICT and ensure successful activation and launching for project scope Prepare all needed documentation that shall enable MoICT to take over the operational part for the proposed solution smoothly, this shall include the Operation manual for the managing the major functionalities of the proposed solution, in addition to System administration manual Conduct Load and stress testing for the proposed Edge ESB solution to ensure that the system is complaint with the pre-defined quality metrics set by the manufacturing company. Note: The proposed solution must be tested against known security vulnerabilities before initial acceptance. It is the responsibility of the winning bidder to assure that an independent third party has reviewed the proposed solution to the utmost level of security specification, by which, third-party certification is required to ensure that the system is tested according to security best practices. i.e Vulnerability assessment and penetration test are required. In the same manner, MoICT reserves the right to perform its own security vulnerability assessment against the proposed solution Upon receiving the latter test results, it is the responsibility of the winning bidder to apply appropriate measures and actions (based on the initial submitted recommendations and required directions from MoICT) to eliminate reported vulnerabilities and ensure system security, such results are required to be plugged into hardening the portal solution on their respected levels An additional security vulnerability test should be conducted to ensure that all vulnerabilities were handled and eliminated Technical proposal requirements Comply with the required hardware/software requirements described in the RFP Propose detailed solution architecture covering the design for the three required environments that ensure high performance, flexibility, scalability,reliability and high level of security for both production environments layers while giving more security measurement to Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 12

13 the DMZ exposed layer (G2B) and taking into consideration the high level architecture provided in section above Define the Approach of conducting system health checks and fixing the reported issues to ensure the proper installation and configuration of the system Describe pre-requisites for the proposed solution in terms of: connectivity, location space, hardware specifications for Smart Cloud and WSRR and other components. Provide a list of deliverables for system installation and configuration Describe bidder s qualifications in ESB system installation and configuration for projects of similar size and nature. Provide a plan for the system deployment and roll-out, this plan must be presented to business owners and top management in involved entities. The plan also should highlight different scenarios (if possible) and the risks associated with each plan, for the management to decide on best approach. Describe approach for roll out plan. Financial Proposal Requirements List all cost associated with the hardware equipment s and software licenses included in the proposed technical solution List all costs associate with the activities mentioned above Deliverables The winning bidder is required to provide the deliverables mentioned below, and any other related deliverables needed for the proper system installation and configuration and its cost shall be included in the fixed lump sum price submitted by the bidder: Installed Edge e-government Service Bus (ESB) that is used to exchange data between entities both inside the SGN and outside it (G2G and G2B) that is complaint with the proposed high level solution architecture and that includes all add-ons described. Installed Monitoring tools Configured and fully functional web services that are tested from end-to-end Health check report prior to go live. Pre-requisites Report for the proposed solution in terms of connectivity, location space, hardware specifications for Smart Cloud and WSRR and other components. Rollout Plan for the 20 web services Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 13

14 3.2 Component 2: Training and Knowledge Transfer Winning bidder activities In order to provide Knowledge Transfer, and Training, the winning bidder is required to perform the activities mentioned below noting that the winning bidder should suggest the background and technical profile of the nominated trainees, Prepare, present and execute plan of tailored training and knowledge transfer for identified team (4 to 5 team members nominated by MOICT\NITC) centrally at NITC premise. Knowledge transfer shall be arranged at various phases of the project taking into consideration the following: Tailored training: Train e-government Ops Center team on the major components of the installed solution, this shall include the following knowledge areas beside any tailored training that is related to the solution components: 1. System Administration 2. System Monitoring ( SmartCloud ) 3. WSRR (WebSphere Service Registry and Repository) 4. Web-services registration and configuration. 5. WebSphere Transformation Extender Design Studio Knowledge Transfer: Transferring knowledge to e-government Ops Center team for the following subjects: 1. System Installation 2. System Operation and Troubleshooting 3. System Backup and Restore 4. System Failure and Recovery Procedures Technical proposal requirements Describe approach, including tools for knowledge transfer and training Describe and list the proposed training sessions, session length, and number of attendees per session Provide training handout material. Provide a high level training schedule showing the training activities by phase Provide a list of deliverables for the Knowledge Transfer, and Training Describe bidder s qualifications in training including references and resumes of trainers. Financial Proposal Requirements List all cost associated with the above activities under the Training and Knowledge Transfer Component Deliverables Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 14

15 The winning bidder is required to provide the deliverables mentioned below, and any other related deliverables needed for the proper Knowledge Transfer, and training and its cost shall be included in the fixed lump sum price submitted by the bidder: Training needs assessment report and knowledge transfer plan Knowledge transfer, and training sessions schedule and curricula Executed Knowledge Transfer and training sessions for all nominated trainees Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 15

16 3.3 Component 3: Operations, Maintenance and Support Winning bidder activities In order to provide operations support and maintenance, the winning bidder is required to perform the activities mentioned below for a duration of 24 months after installing system as of the date of handing over and preliminary acceptance by MoICT, noting that any other related activities needed for the proper functioning of the system shall be provided by the winning bidder and its cost shall be included in the fixed lump sum price submitted by the bidder: Provide Support and maintenance services on a 12X7 (8 A.M to 8 P.M) basis to perform operations and maintenance as well as support for users, performed by offsite team assigned by the winning bidder locally based in Jordan noting that remote access support is not allowed. Provide MoICT with the mother company (IBM) software support and subscription for software components and licenses Provide warranty for three years for all provided Appliances hardware Provide first line support for the migrated web services configuration Issue a service report after each and every site visit registering the reported incident, its root cause and the followed procedures for issue(s) successful resolution including the taken and/or suggested recommendations and measures that shall prevent such incidents / issues from reoccurring in the future Comply with the service level requirements defined by the OPS Centre and as shown in Annex 5.4 of this document Provide communication channels to enable MoICT to report incidents that should be tracked and monitored till final resolution by the winning bidder, and keeping MoICT informed about the status for these incidents Assign a hot line number to be used for reporting Severity 1 (Urgent) incidents Technical proposal requirements The bidder is required to provide the following information in the technical proposal in relation to the Operations Support: Describe approach including: For Hardware: preventive maintenance, site visits, guaranteed minimum response time, guaranteed availability of hardware spare parts stock, replacement of faulty spare parts or equipment, guaranteed minimum resolution time for the critical missions equipment, escalation mechanism, locations of the technical support centres. For Software: software patches and fixes management, major upgrades - even though a major upgrade may include licensing fees as applicable, such fees shall be borne by the winning bidder. Note: All cost incurred by the winning bidder for Hardware and Software defined under the above bullets should be included in the bidder s prices submitted in the financial proposal Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 16

17 Provide the number of people that will be dedicated for the support and maintenance along with their CVs and qualifications Provide a list of deliverables for the Operations Support. Provide escalation procedure for the trouble ticket. Describe bidder s qualifications in operations management including references Describe bidder s qualifications in operations support Updating and creating all required documentation Warranty The winning bidder will provide complete documentation that covers all aspects of the project as part of the handover of this project and in consistence with MoICT Release Management Document; the documentation involves updating the current available documentation and developing additional documentation for the areas that are not covered in the current documentation. (Please attach samples in the appendix section of your proposal). The winning bidder will provide warranty for all systems and technology provided under this project as indicated in this RFP for duration of 36 months as of the date of handing over and preliminary acceptance by MoICT. Financial Proposal Requirements The bidder is required to provide the following information in the financial proposal in relation to the Operations Support, Maintenance and Warranty Deliverables Operations Support and Maintenance o Warranty o List all costs associated with operations support and maintenance List all costs associated with warranty The winning bidder is required to provide the deliverables mentioned below, and any other related deliverables needed for the proper functioning of the system and its cost shall be included in the fixed lump sum price submitted by the bidder: Operations and maintenance policies and procedures Support organization structure with assigned people, their roles, responsibilities, skills, etc. Implemented Operations Support organization. List of service reports. Provide 36 months warranty Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 17

18 3.4 Component 4: Project Management Winning bidder activities The Ministry of Information and Communications Technology is following the PMI standards for managing projects and as per the PMI best practices. In order to provide project management services, the winning bidder is required to perform the project management processes in addition to the activities mentioned below, noting that any other related activities and processes needed for the proper functioning of the project implementation should be provided by the winning bidder and its cost should be included in the fixed lump sum price submitted by the bidder: Appoint a designated Project Manager (full-time for the contract duration) to oversee the project execution together with project teams to execute all designated tasks and activities Develop a Project Plan, including project objectives and success criteria, deliverables, role/responsibilities, communication protocols, document control methodology, cost management, schedule management, and any needed project plan Develop and maintain the overall project schedule, and review and verify the integration of the project team s activities & deliverables Develop project implementation strategy based on the needs and priorities of the business owner that will create the needed impact at the different stages of the project Develop a project plan that will determine and ensure the attainment of all project objectives through the proper prioritization and dependency consideration of different project activities. Ensure close cooperation with MoICT Project team as well as the service provider and dependencies representatives Schedule and conduct on-site bi-weekly progress meetings involving the project team. Meeting Minutes will be recorded and distributed, including an outstanding action Item Log, detailing the status of key decisions, responsibility and required timing. Conduct Weekly progress meetings with MoICT team. Conduct periodic progress (steering committee) meetings with MoICT at least once a month. Provide and maintain a full and comprehensive plan that covers all project management knowledge areas (i.e., time, scope, quality, HR, communication, risk, etc.) Develop project organization structure to underline all possible resources needed from engaged parties including their roles and responsibilities as well as their involvement at different stages of the Project Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 18

19 Establish and execute a process for reporting project progress including deadlines; delays, issues and critical paths to ensuring deliverables are met within resource constraints Report on current or future restrictions that shall have potential negative impact on the progress of the portal project (delays, deviations, show stoppers etc.) and suggesting proper mechanisms to deal and resolve such restrictions in an effective and efficient manner Establish and execute a process for project risks and issues management and mitigation Implement submission, key performance indicators and acceptance procedures for approving project deliverables Close the project and document lessons learnt. Note: MoICT will be providing the winning bidder with a project management kit that is mandatory to comply with. Technical proposal requirements The bidder is required to provide the following information in the technical proposal in relation to the Project Management: The project s implementation methodology and approach. And the description of the different phases of the project Elaborate further on the bidder s methodology in implementing the project on phased approach basis and associating it with the project s tangible milestones to increase the probability of success, overcome the resistance to change (if any) and create an opportunity to incorporate lessons learned into the design of project management cycle on upcoming milestones Describe ideas how the overall project coordination should be tackled in order to assure proper time and effective use of resources and information Describe proposed implementation strategy that will ensure project success. Provide Project management organization structure describing roles and responsibilities Describe approach for communication on the project Describe approach to report on project progress Describe approach to risks and issues management and mitigation Provide a list of deliverables for the Project Management. Describe methodology for the overall Project Management and bidder s professional qualifications (like PM certificates) in project management field Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 19

20 Financial proposal requirements The bidder is required to provide the following information in the financial proposal in relation to the Project Management: List all costs associated with the Project Management. Deliverables The winning bidder is required to provide the deliverables mentioned below, noting that any other related deliverables needed for the proper functioning of the project implementation should be provided by the winning bidder and its cost should be included in the fixed lump sum price submitted by the bidder: Project kick-off presentation (in English and Arabic) Project implementation strategy that shows the rationale behind the chosen phase implementation approach A project milestone schedule during the project preparation phase Project management documentation that will cover the different knowledge areas, listed below but not limited to: Project Charter Project management plan Project organization structure and roles and responsibilities Communications management plan Risk management plan Procurement management plan Detailed project schedule and WBS Detailed work breakdown structure outlining all tasks, milestones and resource needs Scheduled project status and progress reports Requirements tractability matrix Deliverables acceptance Plan Change Management plan Issues and risk logs Weekly and monthly status and progress reports Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 20

21 Project closing presentation (in English and Arabic) Project conclusion document outlining work completed, lessons learned and recommendations for next steps Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 21

22 3.5 Component 5 - Quality Management Winning bidder activities The winning bidder is required to perform the activities mentioned below, noting that any additional related activities needed for the proper functioning of the system should be provided by the winning bidder and its cost should be included in the fixed lump sum price submitted by the bidder: Assign a dedicated Quality team to ensure quality of project deliverables or software through the related set of (Verification and Validation) activities. Prepare a high level Quality plan that covers all project phases and activities. Prepare a detailed Quality plan scope that should include all project phases and deliverables,. The quality plan shall ensure the proper implementation and launching of project elements including the verification of the deliverable outcome. The winning bidder Quality team shall be responsible for performing all quality activities defined within the quality plan that includes planning, control, and assurance. In additional to functional, non-functional testing to ensure conformance to requirements and fitness for use, in compliance with best practices and best business standards. Develop a detailed documentation of Quality Management activities, including, Planning, Assurance, and Control, outlining various types of functional and non-functional tests and test results. This includes but is not limited to: full functional testing (Unit testing, Integration testing, System testing, and User Acceptance Testing), in addition to nonfunctional testing such as (Load, stress, performance, availability, reliability, security, backup, recovery testing, etc.). Provide all Quality deliverables which ensure that all related activities are done successfully. This includes but not limited to Test Plans, Test Case Scenarios including acceptance test scenarios, Testing results/reports, Testing Summary report, Defect (Bug) report and other required/proposed artefacts. Ensure proper deployment from staging environment to the ultimate Production environment after getting the approval from MoICT. Ensure successful data exchange between entities through the proposed Edge ESB solution for the migrated web services listed in Annex 5.2. The winning bidder must perform full cycle testing from producer to consumer for all web services covered in the project scope given that MoICT has the required sign-offs for all web services from the related government entities. Ensure tracing of the allocated requirements through the project life cycle to confirm that each requirement is implemented in the product and that each requirement is thoroughly tested. Verify the documentation used to operate and maintain the project against the baseline and any applicable agreed requirements before the project is submitted for acceptance. Ensure that deliverables comply with the standards and requirements stipulated in RFP and provided in the winning bidder proposal, and as agreed during the scoping phase. Provide samples of plans and procedures for testing the deliverables. Reference testing standards and practices, including which test phases and test readiness checkpoints are planned. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 22

23 Implement submission and acceptance procedures for approving project deliverables. Develop and implement a Non-functional testing management process that involves monitoring and measuring the performance of the solution against the pre-defined quality metrics and performance measures (KPIs) that will be provided by IBM, noting that the winning bidder has to measure in order to guarantee solution compliance by providing required system performance reports. Technical proposal requirements The bidder is required to provide the following information in the technical proposal in relation to the Quality Management, and demonstrate the approach and components through which the quality management activities shall be implemented. The proposal should provide adequate explanation regarding the proposed Quality management, including but not limited to: Describe bidder s professional qualifications (like Quality certificates/accreditation) in quality management. Describe the proposed quality management organizational structure including roles and responsibilities, in terms of estimate number of needed resources to complete the quality activities and their qualifications. Describe methodology for the overall Quality Management that guarantees the assurance and conformance of project deliverables and work products to established contractual agreements, processes, plans, policies, standards and procedures and e- Government requirements, this including but not limited to:- o Process of identification of defects and corrective action as early in the project as possible, thereby facilitating product reliability. o Methodology for performing checkpoints and set of reviews for the requirements, design, security, code walkthroughs, and results to be completed and recorded. o Process for reviewing the test plans, test cases, and test results; identify the defect tracking processes, test environments, test roles and responsibilities, and test phase entrance/exit criteria. o Process for determining whether deliverables are ready to deploy to the ultimate production environment and production readiness criteria. o Process for documenting change and configuration management practices within the project. o Process for capturing and tracking resolutions to problems found during the reviews include product, project and process issues and defects. o Standards and KPIs to be used to measure project deliverable quality. o Quality metrics to be used to measure project deliverable quality. o Process of documenting the links between the requirements and the products developed to implement and verify those requirements. It should be referenced throughout the entire software development life cycle. o Describe testing strategy, testing techniques and approach to setting up the test environment. o Describe the testing tools to be used by the bidder to perform all required testing types to measure quality of project deliverables and final product. Provide a list of deliverables for the Quality Management, as mentioned in the deliverable section below, and as per the bidder proposed approach. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 23

24 Financial proposal requirements The bidder is required to provide all costs associated with the Quality Management in the financial proposal. Deliverables The winning bidder is required to provide the deliverables mentioned below, noting that any other related deliverables needed for the proper functioning of the system should be provided by the winning bidder and its cost should be included in the fixed lump sum price submitted by the bidder. Quality management documentation that will cover the different knowledge areas, including but not limited to: o o o o o o o Quality Management plan (Quality and Test Plan documents) Complete Quality Assurance and Control documentation including functional and non-functional reports and health check reports against the pre-defined performance measures (KPIs) that will be provided by the manufacturer IBM. Test Case Scenarios documents Test Results documents User and System Acceptance Criteria documents including recommendations for acceptance criteria to be signed by concerned parties. Quality Traceability matrix and Key Performance Indicators documents. Quality Monthly status and progress reports. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 24

25 4 ADMINISTRATIVE PROCEDURES AND REQUIREMENTS 4.1 Response procedures All inquiries with respect to this RFP are to be addressed to the Ministry of information and Communications Technology s Tendering Department project manager in writing by mail, or fax with the subject EDGE ENTERPRISE SERVICE BUS SOLUTION". Inquiries can only be addressed to [EDGEESB@moict.gov.jo] by [Sunday August 2 nd, 2015] or by Fax. Responses will be sent in writing no later than [Wednesday August 5 th, 2015]. Questions and answers will be shared with all Bidders primary contacts. 4.2 Response format Bidders responding to this RFP should demonstrate up-to-date capabilities and experience in providing similar services and similar engagements of the same scope, size and nature especially in the public sector. These services and engagements must be performed by the bidder during the last 5 years. Bidders should demonstrate the following specific capabilities: Experience in implementing of Enterprise Service Bus showing previous implementation of projects of same size and/or nature Knowledge in installing, configuring and testing Hardware components IT experience in both hardware and software and other IT related areas specified in section 3 Experience in knowledge transfer and training Experience in operations support and maintenance Experience in web services development and standards General knowledge in Jordanian governmental laws and by-laws Note: Where some skills are not available, the bidder is expected to sub-contract with a reputable consulting firm to cover for this specific skill. In case of subcontracting, the subcontractor has to be approved by MoICT and the contractor will be liable for all works performed by the sub-contractor. Bidders written response to the RFP must include: Part I: Technical Proposal A. Corporate capability statement : Corporate capability statement must include all the following: Corporate technical capabilities and experience in implementing web solutions together with detailed description and reference to each component underlined in Section 3: Scope of the project. Detailed proposed Team Resumes (each resume will be subjected to the approval of Ministry of information and Communications Technology, in case of replacements the winning bidder has to abide by the Ministry of information and Communications Technology requirements for replacements and approvals. In the implementation phase Ministry of information and Communications Technology reserves the right to request replacement of any resource that cannot fulfill the job) Description and references to similar projects performed Reference to appropriate work samples Current client list, highlighting potential conflict of interest Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 25

26 Submit work plan resource allocation with their percentage of involvement Project Organization Structure B. Technical proposal: The technical proposal shall include the approach to achieving the scope of work defined in this RFP and delivering each of the major components as specified in the Deliverables section. In order for the evaluation to progress quickly and effectively, bidders are requested to provide Part I of their proposal as per the format described in Annex 5.6. C. Bidders should provide Financial solvency from a registered bank with their technical proposals. Part II: Financial Proposal The financial proposal should include a cost summary and a detailed cost analysis section. The cost summary must provide a fixed lump sum price in Jordan Dinars for the overall scope of work and deliverables including all fees, taxes including sales tax. The supporting detailed cost analysis should provide a breakdown and details of the pricing should be provided. The day rates and expenses for any consultants should be included separately along with the time for which they will be required. The bidder will provide separately all professional fees and expenses (travel, project equipment, accommodation and subsistence, etc) for the duration of the project. The pricing should show the proposed linkage between deliverables and payments. Financial )خالصة and summary of remuneration (عرض المنالصة) proposal should include the Form of Bid filled; duly (ملحق االتفال ة رلم 2 و رلم ) 3 under attached in the Arabic Sample Agreement بدالت األتعاب( signed and stamped by the bidder. The Financial proposal should be submitted in separation of the technical proposal. In order for the evaluation to progress quickly and effectively, bidders are requested to provide their proposal as per the format described in Annex 5.7. Part III: Bid Security This part includes the original Bid Security. 4.3 Response submission Bidders must submit proposals to this RFP to the Ministry of Information and Communications Technology no later than 2:00 PM on Wednesday August 12 th, 2015 (Jordan Local Time). Tendering Department 3 rd floor Ministry of Information and Communications Technology 8 th Circle P.O. Box 9903 Amman Jordan 2] /ح ك / 2102 [ No. Tender Tel: Fax: tenderssecretary@moict.gov.jo Proposals should be submitted as 3 separate parts each part in a separate well-sealed and wrapped envelope clearly marked, respectively, as follows: Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 26

27 Part I EDGE ENTERPRISE SERVICE BUS SOLUTION- Technical and Corporate Capabilities Proposal. This part (envelop) should contain 3 hard copies (1 original and 2 copies) and 1 softcopy (CD) [in Microsoft Office 2010 or Office 2010 compatible formats]. This part should not contain any reference to cost or price. Inclusion of any cost or price information in the technical proposal will result in the bidder s proposal being disqualified as irresponsive. Part II EDGE ENTERPRISE SERVICE BUS SOLUTION Financial Proposal. This part (envelop) should contain 3 hard copies (1 original and 2 copy) and 1 softcopy (CD) [in Microsoft Office 2010 or Office 2010 compatible formats]. Part III EDGE ENTERPRISE SERVICE BUS SOLUTION Bid Security" This part (envelope) should contain 1 hard copy. This part should not contain any reference to cost or price. Inclusion of any cost or price information in the technical proposal will result in the bidder s proposal being disqualified as irresponsive. Note: Each CD should be enclosed in the relevant envelop. Late submissions will not be accepted nor considered and in case of discrepancy between the original hard copy and other hard copies and/or the soft copy of the proposal, the hard copy marked as original will prevail and will be considered the official copy. Proposals may be withdrawn or modified and resubmitted in writing any time before the submission date. Regardless of method of delivery, the proposals must be received by the Ministry of Information & Communications Technology no later than 2:00 PM [12/8/2015] (Amman Local Time). Ministry of Information & Communications Technology will not be responsible for premature opening of proposals not clearly labeled. 4.4 Response evaluation All responses to the RFP will be evaluated technically and financially and the winning proposal will be selected on the basis of best value in terms of technical superiority as well as cost effectiveness. Technical and financial proposals shall be reviewed by the Special Tendering Committee at the Ministry of Information and Communications Technology and evaluated in accordance with the following procedure: The overall proposal will be evaluated according to the following criteria: Overall Technical Proposal 50% Overall Financial Proposal 50% The overall bidder s mark will be calculated as follows: (50* least value of financial proposal)/bidder financial proposal value + (%50*bidder technical mark) Technical proposal shall be first evaluated according to the following criteria: Past Experience in similar projects and track records (20 marks) Staff Qualifications and Experience (local / international) (30 marks) Proposed Approach and Methodology in correspondence to the RFP requirements including to the following components: (50 marks) System Installation and Configuration Training and Knowledge Transfer Operation Support, Maintenance and warranty Project Management Quality Management Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 27

28 Only those bidders that qualify in the technical proposal will have their financial offers reviewed. The Financial proposal will be evaluated only for companies who qualify, based on a minimum acceptable score that will be defined by the special tenders committee. The financial offer of those who do not qualify will not be opened and will be returned. The Ministry of Information and Communications Technology reserves the right not to select any offer. The Ministry of Information and Communications Technology also assumes no responsibility for costs of bidders in preparing their submissions. 4.5 Financial terms Bidders should take into consideration the following general financial terms when preparing and submitting their proposals: All prices should be quoted in Jordanian Dinars inclusive of all expenses, governmental fees and taxes, including sales tax The type of contract will be a fixed lump sum price contract including costs of all software or/and hardware, licensees, documentation, maintenance, support, knowledge transfer, training, warranty, and professional fees, profits and over heads and all other expenses incurred A clear breakdown (table format) of the price should be provided including price for consulting time, other expenses, etc. The bidder shall bear all costs associated with the preparation and submission of its proposal and the Ministry of Information and Communications Technology will in no case be responsible or liable for these costs, regardless of the conduct or outcome of the proposal process. The bidders shall furnish detailed information listing all commissions and gratuities, if any, paid or to be paid to agents relating to this proposal and to contract execution if the bidder is awarded the contract. The information to be provided shall list the name and address of any agents, the amount and currency paid and the purpose of the commission or gratuity. The Bidder shall submit a (Tender Bond) proposal security on a form similar to the attached format in Jordanian Dinars for a flat sum of 20,000 J.D) Jordanian Dinars (in a separate sealed envelope. The bond will be in the form of bank guarantee from a reputable registered bank, located in Jordan, selected by the bidder. The bidder shall ensure that the (tender bond) proposal security shall remain valid for a period of 90 days after the bid closing date or 30 days beyond any extension subsequently requested by the tendering committee, and agreed to by the bidder. Any proposal not accompanied by an acceptable proposal security (tender bond) shall be rejected by the tendering committee as being non-responsive pursuant to RFP. The proposal security of the unsuccessful bidders will be returned not later than 30 days after the expiration of the proposal validity period. The winning bidder is required to submit a performance bond of 10% of the total value of the contract within 14 days as of the date of award notification letter. The proposal security of the winning bidder will be returned when the bidder has signed the contract and has furnished the required performance security. The proposal security may, in the sole discretion of the tendering committee, be forfeited: If the bidder withdraws its proposal during the period of proposal validity as set out in the RFP; or In the case of winning bidder, if the bidder fails within the specified time limit to sign the contract in front of a notary public in Amman, Jordan; or furnish the required performance security as set out in the contract. The winning bidder has to pay the fees of the RFP advertisement issued in the newspapers. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 28

29 The Ministry of Information and Communications Technology is not bound to accept the lowest bid and will reserve the right to reject any bids without the obligation to give any explanation. Bidders must take into consideration that payments will be as specified in the tender documents and will be distributed upon the winning submission and acceptance of the scope of work and of the deliverables and milestones of the scope of work defined for the project by the first party. The Ministry of Information and Communications Technology takes no responsibility for the costs of preparing any bids and will not reimburse any Bidder for the cost of preparing its bid whether winning or otherwise. 4.6 Legal terms Bidders should take into consideration the following general legal terms when preparing and submitting their proposals: The bidders shall not submit alternative proposal. Alternative proposals will be returned unopened or unread. If the bidder submits more than one proposal and it is not obvious, on the sealed envelope(s), which is the alternative proposal, in lieu of returning the alternative proposal, the entire submission will be returned to the bidder and the bidder will be disqualified. The proposal shall be signed by the bidder or a person or persons duly authorized to bind the bidder to the contract. The latter authorization shall be indicated by duly-legalized power of attorney. All of the pages of the proposal, except un-amended printed literature, shall be initialed by the person or persons signing the proposal. Any interlineations, erasures or overwriting shall only be valid if they are initialed by the signatory(ies) to the proposal. The bid shall contain an acknowledgement of receipt of all Addenda to the RFP, the numbers of which must be filled in on the Form of Bid attached to the Arabic Sample Agreement The Ministry of Information & Communications Technology requires that all parties to the contracting process observe the highest standard of ethics during the procurement and execution process. The Special Tenders Committee will reject a proposal for award if it determines that the Bidder has engaged in corrupt or fraudulent practices in competing for the contract in question. Corrupt Practice means the offering, giving, receiving or soliciting of anything of value to influence the action of a public official in the procurement process or in contract execution Fraudulent Practice means a misrepresentation of facts in order to influence a procurement process or the execution of a contract to the detriment of Government of Jordan, and includes collusive practice among Bidders (prior to or after proposal submission) designed to establish proposal prices at artificial non-competitive levels and to deprive Government of Jordan of the benefits of free and open competition. No bidder shall contact MoICT, its employees or the Special Tenders Committee or the technical committee members on any matter relating to its proposal to the time the contract is awarded. Any effort by a bidder to influence MoICT, its employees, the Special Tenders Committee or the technical committee members in the tendering committee s proposal evaluation, proposal comparison, or contract award decision will result in rejection of the bidder s proposal and forfeiture of the proposal security. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 29

30 The remuneration of the Winning Bidder stated in the Decision of Award of the bid shall constitute the Winning Bidder sole remuneration in connection with this Project and/or the Services, and the Winning Bidder shall not accept for their own benefit any trade commission, discount, or similar payment in connection with activities pursuant to this Contract or to the Services or in the discharge of their obligations under the Contract, and the Winning Bidder shall use their best efforts to ensure that the Personnel, any Subcontractors, and agents of either of them similarly shall not receive any such additional remuneration. A business registration certificate should be provided with the proposal. If the bidder is a joint venture, then the partners need to be identified with the rationale behind the partnership. Corporate capability statement should also be provided for all partners. The laws and regulations of The Hashemite Kingdom of Jordan shall apply to awarded contracts. MoICT takes no responsibility for the costs of preparing any bids and will not reimburse any bidder for the cost of preparing its bid whether winning or otherwise. If the winning bidder is an international company, it must provide a local representative or a local partner in Jordan. Bidders must review the Sample Arabic Contract Agreement provided with this RFP and that will be the Contract to be signed with the winning bidder. Provisions in this Sample Arabic Contract Agreement are not subject to any changes; except as may be amended by MoICT before tender submission; such amendments are to be issued as an addenda. Proposals shall remain valid for period of (90) days from the closing date for the receipt of proposals as established by the Special Tenders Committee. The Special Tenders Committee may solicit the bidders consent to an extension of the proposal validity period. The request and responses thereto shall be made in writing or by fax. If a bidder agrees to prolong the period of validity, the proposal security shall also be suitably extended. A bidder may refuse the request without forfeiting its proposal security; however, in its discretion, the Special Tenders Committee may cease further review and consideration of such bidder s proposal. A bidder granting the request will not be required nor permitted to modify its proposal, except as provided in this RFP. MoICT reserves the right to accept, annul or cancel the bidding process and reject all proposals at any time without any liability to the bidders or any other party and/withdraw this tender without providing reasons for such action and with no legal or financial implications to MoICT. MoICT reserves the right to disregard any bid which is not submitted in writing by the closing date of the tender. An electronic version of the technical proposal will only be accepted if a written version has also been submitted by the closing date. MoICT reserves the right to disregard any bid which does not contain the required number of proposal copies as specified in this RFP. In case of discrepancies between the original hardcopy, the other copies and/or the softcopy of the proposals, the original hardcopy will prevail and will be considered the official copy. MoICT reserves the right to enforce penalties on the winning bidder in case of any delay in delivery defined in accordance with the terms set in the sample Arabic contract. The value of such penalties will be determined in the Sample Arabic contract for each day of unjustifiable delay. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 30

31 Bidders may not object to the technical or financial evaluation criteria set forth for this tender. The winning bidder will be expected to provide a single point of contact to which all issues can be escalated. MoICT will provide a similar point of contact. MoICT is entitled to meet (in person or via telephone) each member of the consulting team prior to any work, taking place. Where project staff is not felt to be suitable, either before starting or during the execution of the contract, MoICT reserves the right to request an alternative staff at no extra cost to MoICT. Each bidder will be responsible for providing his own equipment, office space, secretarial and other resources, insurance, medical provisions, visas and travel arrangements... etc. MoICT will take no responsibility for any non-moict of Jordan resources either within Jordan or during travel to/from Jordan Any source code, licenses, documentation, hardware, and software procured or developed under EDGE ENTERPRISE SERVICE BUS SOLUTION are the property of MoICT upon conclusion of EDGE ENTERPRISE SERVICE BUS SOLUTION. Written consent of MoICT must be obtained before sharing any part of this information as reference or otherwise Bidders are responsible for the accuracy of information submitted in their proposals. MoICT reserves the right to request original copies of any documents submitted for review and authentication prior to awarding the tender. The bidder may modify or withdraw its proposal after submission, provided that written notice of the modification or withdrawal is received by the tendering committee prior to the deadline prescribed for proposal submission. Withdrawal of a proposal after the deadline prescribed for proposal submission or during proposal validity as set in the tender documents will result in the bidder s forfeiture of all of its proposal security (bid bond). A bidder wishing to withdraw its proposal shall notify the Special Tenders Committee in writing prior to the deadline prescribed for proposal submission. A withdrawal notice may also sent by fax, but it must be followed by a signed confirmation copy, postmarked no later than the deadline for submission of proposals. The notice of withdrawal shall be addressed to the Special Tenders Committee at the address in RFP, and bear the contract name EDGE ENTERPRISE SERVICE BUS SOLUTION and the words Withdrawal Notice. Proposal withdrawal notices received after the proposal submission deadline will be ignored, and the submitted proposal will be deemed to be a validly submitted proposal. No proposal may be withdrawn in the interval between the proposal submission deadline and the expiration of the proposal validity period. Withdrawal of a proposal during this interval may result in forfeiture of the bidder s proposal security. The Bidder accepts to comply with all provisions, that are explicitly stated in this RFP and any other provisions stated in the Standard Sample Arabic Contract Agreement attached hereto and Tendering Instruction and attached hereto. The winning bidder shall perform the Services and carry out their obligations with all due diligence, efficiency, and economy, in accordance with the highest generally accepted professional techniques and practices, and shall observe sound management practices, and employ appropriate advanced technology and safe methods. The Winning Bidder shall always act, in respect of any matter relating to this Contract or to the Services, as faithful advisers to The E-Government program, and shall at all times support and Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 31

32 safeguard The E-Government program s legitimate interests in any dealings with Subcontractors or third parties. If there is any inconsistency between the provisions set forth in the Sample Arabic Contract Agreement attached hereto or this RFP and the proposal of Bidder; the Sample Arabic Contract Agreement and /or the RFP shall prevail The E-Government program reserves the right to furnish all materials presented by the winning bidder at any stage of the project, such as reports, analyses or any other materials, in whole or part, to any person. This shall include publishing such materials in the press, for the purposes of informing, promotion, advertisement and/or influencing any third party, including the investment community. The E-Government program shall have a perpetual, irrevocable, non-transferable, paid-up right and license to use and copy such materials mentioned above and prepare derivative works based on them. Bidders are not allowed to submit more than one proposal for this RFP. Similarly subcontractors are not allowed to participate in more than one proposal. If a partner in a subcontractor participate in more than one proposal; such proposals shall not be considered and will be rejected for being none-responsive to this RFP. Amendments or reservations on any of the Tender Documents: Bidders are not allowed to amend or make any reservations on any of the Tender Documents or the Arabic Sample contract agreement attached hereto. In case any bidder does not abide by this statement, his proposal will be rejected for being none-responsive to this RFP. If during the implementation of this project; it is found that the winning bidder has included in his proposal any amendments, reservations on any of the tender documents or the Contract; then such amendments or reservations shall not be considered and the items in the tender documents and the Contact shall prevail and shall be executed without additional cost to MoICT and the winning bidder shall not be entitled to claim for any additional expenses or take any other legal procedures. Nothing contained herein shall be construed as establishing a relation of principal and agent as between MoICT and the Winning Bidder. The Winning Bidder has complete charge of Personnel and Sub-contractors, if any, performing the Services and shall be fully responsible for the Services performed by them or on their behalf hereunder. The Winning Bidder, their Sub-contractors, and the Personnel of either of them shall not, either during the term or after the expiration of the Contract, disclose any proprietary or confidential information relating to the Project, the Services, the Contract, or MoICT s business or operations without the prior written consent of MoICT. The Winning Bidder shall sign a Non-Disclosure Agreement with MoICT as per the standard form adopted by MoICT. A confidentiality undertaking is included in Annex 5.8. Sample Arabic Contract Agreement Approval: Bidders must review the Sample Arabic Contract Agreement version provided with the RFP, which shall be binding and shall be signed with winning bidder. )نموذج عرض المنالصة( Bidders must fill out, stamp and duly sign the Form of Bid attached to the Arabic Sample Agreement under )2( ملحك رلم and enclose it in their financial proposals. )الملحك رلم )3 3 Bidders must fill out the summary payment schedule form sub Annex which is part of the Arabic Sample Contract version provided with the RFP, sign and stamp it, and enclose it with the Financial Proposal. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 32

33 Bidders must also fill out and duly sign the Financial Proposal Response Formats under Annex 5.7of this RFP and enclose it in the financial proposals. Proposals that do not include these signed forms are subject to rejection as being none responsive. PROHIBITION OF CONFLICTING ACTIVITIES Neither the Winning Bidder nor their Sub-contractors nor their personnel shall engage, either directly or indirectly, in any of the following activities: o o During the term of the Contract, any business or professional activities in Jordan or abroad which would conflict with the activities assigned to them under this bid; or After the termination of this Project, such other activities as may be specified in the Contract. INTELLECTUAL PROPERTY RIGHTS PROVISIONS o o Intellectual Property for the purpose of this provision shall mean all copyright and neighboring rights, all rights in relation to inventions (including patent rights), plant varieties, registered and unregistered trademarks (including service marks), registered designs, Confidential Information (including trade secrets and know how) and circuit layouts, and all other rights resulting from intellectual activity in the industrial, scientific, literary or artistic fields. Contract Material for the purpose of this provision shall mean all material (includes documents, equipment, software, goods, information and data stored by any means): o o o o a) Brought into existence for the purpose of performing the Services; b) incorporated in, supplied or required to be supplied along with the Material referred to in paragraph (a); or c) Copied or derived from Material referred to in paragraphs (a) or (b); Intellectual Property in all Contract Material vests or will vest in MoICT. This shall not affect the ownership of Intellectual Property in any material owned by the Winning Bidder, or a Sub-contractor, existing at the effective date of the Contract. However, the Winning Bidder grants to MoICT, or shall procure from a Sub-contractor, on behalf of MoICT, a permanent, irrevocable, royalty-free, worldwide, non-exclusive license (including a right of sub-license) to use, reproduce, adapt and exploit such material as specified in the Contract and all relevant documents. If requested by MoICT to do so, the Winning Bidder shall bring into existence, sign, execute or otherwise deal with any document that may be necessary or desirable to give effect to these provisions. The Winning Bidder shall at all times indemnify and hold harmless MoICT, its officers, employees and agents from and against any loss (including legal costs and expenses on a solicitor/own client basis) or liability incurred from any claim, suit, demand, action or proceeding by any person in respect of any infringement of Intellectual Property by the Winning Bidder, its officers, employees, agents or Sub-contractors in connection with the performance of the Services or the use by MoICT of the Contract Material. This indemnity shall survive the expiration or termination of the Contract. The Winning Bidder not to benefit from commissions discounts, etc. The remuneration of the Winning Bidder stated in the Decision of Award of the bid shall constitute the Winning Bidder sole remuneration in connection with this Project and/or the Services, and the Winning Bidder shall not accept for their own benefit any trade commission, discount, or similar payment in connection with activities pursuant to this Contract or to the Services Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 33

34 or in the discharge of their obligations under the Contract, and the Winning Bidder shall use their best efforts to ensure that the Personnel, any Sub-contractors, and agents of either of them similarly shall not receive any such additional remuneration. THIRD PARTY INDEMNITY Unless specified to the contrary in the Contract, the Winning Bidder will indemnify MoICT, including its officers, employees and agents against a loss or liability that has been reasonably incurred by MoICT as the result of a claim made by a third party: o o Where that loss or liability was caused or contributed to by an unlawful, negligent or willfully wrong act or omission by the Winning Bidder, its Personnel, or sub-contractors; or Where and to the extent that loss or liability relates to personal injury, death or property damage. LIABILITY o The liability of either party for breach of the Contract or for any other statutory cause of action arising out of the operation of the Contract will be determined under the relevant law in Hashemite Kingdom of Jordan as at present in force. This liability will survive the termination or expiry of the Contract. Winning bidder s total liability relating to contract shall in no event exceed the fees Winning bidder receives hereunder, such limitation shall not apply in the following cases (in addition to the case of willful breach of the contract): gross negligence or willful misconduct on the part of the Consultants or on the part of any person or firm acting on behalf of the Consultants in carrying out the Services, an indemnity in respect of third party claims for damage to third parties caused by the Consultants or any person or firm acting on behalf of the Consultants in carrying out the Services, infringement of Intellectual Property Rights 4.7 Conflict of interest The Winning bidder warrants that to the best of its knowledge after making diligent inquiry, at the date of signing the Contract no conflict of interest exists or is likely to arise in the performance of its obligations under the Contract by itself or by its employees and that based upon reasonable inquiry it has no reason to believe that any sub-contractor has such a conflict. If during the course of the Contract a conflict or risk of conflict of interest arises, the Winning bidder undertakes to notify in writing MoICT immediately that conflict or risk of conflict becomes known. The Winning bidder shall not, and shall use their best endeavors to ensure that any employee, agent or sub-contractor shall not, during the course of the Contract, engage in any activity or obtain any interest likely to conflict with, or restrict the fair and independent performance of obligations under the Contract and shall immediately disclose to MoICT such activity or interest. If the Winning bidder fails to notify MoICT or is unable or unwilling to resolve or deal with the conflict as required, MoICT may terminate this Contract in accordance with the provisions of termination set forth in the Contract. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 34

35 4.8 Secrecy and security The Winning bidder shall comply and shall ensure that any sub-contractor complies, so far as compliance is required, with the secrecy and security requirements of MoICT, or notified by MoICT to the Winning bidder from time to time. 4.9 Documents property All plans, drawings, specifications, designs, reports, and other documents and software submitted by the Winning bidder in accordance with the Contract shall become and remain the property of MoICT, and the Winning bidder shall, not later than upon termination or expiration of the Contract, deliver all such documents and software to MoICT, together with a detailed inventory thereof. Restrictions about the future use of these documents, if any, shall be specified in the Special Conditions of the Contract Removal or/and replacement of personnel Except as MoICT may otherwise agree, no changes shall be made in the key Personnel. If, for any reason beyond the reasonable control of the Winning bidder, it becomes necessary to replace any of the key Personnel, the Winning bidder shall provide as a replacement a person of equivalent or better qualifications and upon MoICT approval. If MoICT finds that any of the Personnel have (i) committed serious misconduct or have been charged with having committed a criminal action, or (ii) have reasonable cause to be dissatisfied with the performance of any of the Personnel, then the Winning bidder shall, at MoICT s written request specifying the grounds thereof, provide as a replacement a person with qualifications and experience acceptable to MoICT Other project-related terms MoICT reserves the right to conduct a technical audit on the project either by MoICT resources or by third party. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 35

36 5 ANNEXES 5.1 Proposed Edge Solution Hardware / Software List 5.2 Current Web Services List 5.3 Private Cloud Specifications 5.4 Service Level Agreement Requirements 5.5 E-Government Program Background and Implementation Framework 5.6 Technical Proposal Response Format 5.7 Financial Proposal Response Format 5.8 Confidentiality Undertaking 5.9 Key RFP Dates and Deadlines 5.10 Sample Arabic Agreement Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 36

37 5.1 Proposed Edge Solution Hardware / Software List IBM P/N Description Quantity D1ASXLL IBM DataPower Gateway Appliance Install APPLIANCE firmware Subscription & Support 24 MONTHS 5 D59D4LL D1AYNLL D0Q3TLL D0Q51LL IBM WebSphere Service Registry and Repository Processor Value Unit (PVU) License + SW Subscription & Support 24 Months Application Optimization Module for IBM DataPower Gateway Application Instance License + Software Subscription & Support 24 Months IBM SmartCloud Application Performance Management Standard Managed Virtual Server License + SW Subscription & Support 24 Months IBM SmartCloud Application Performance Management NON Production Managed Virtual Server License + SW Subscription & Support 24 Months D1AYULL D58XCLL Integration Module for IBM DataPower Gateway Application Instance License + Software Subscription & Support 24 Months WebSphere Transformation Extender Design Studio Authorized User License + 24 Months S&S 3 2 Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 37

38 Current Web Services List Entity System System Description Consuming Entity System for the consumer 1 Company Control Department (CCD) Company Registry System Part of CCD functions is to register new establishment as well as maintaining any changes on this information, the details of this portion of information is of interest to other entities in the Kingdom. ISTD (income and sales taxes department) ISTD requests the companies information as part of their work on taxes transactions. 2 Department of Land and Survey (DLS) Property Catalogue System Part of DLS functions is to register the land property rights as well as archiving and maintaining any changes on this information, the details of this portion of information is of interest to other 18 government entities in the Kingdom. MoJ MoJ requests the land information properties as part of their work on issuing Bails and Procuration s. 3 Driver Vehicle and Licensing Department (DVLD) Drivers Vehicles System and Part of DVLD functions is to registers the information of citizens that acquired driving licenses and information about the vehicles owned by either individuals or organizations; the detail of this portion of information is of interest to other entities in the Kingdom. RHC RHC requests the of information vehicles owned by them. 4 Amman chamber of Commerce (ACC) Subscribers Amman Chamber Commerce at of To provide ACC Subscribers information to the consuming government entities (Great Amman Municipality [GAM], Jordan Custom Development [JCD], National Aid fund [NAF], Civil Service Bureau [CSB]) GAM GAM requests the of information ACC Subscribers as part of their work on Vocational licenses. 5 Ministry of Finance (MOF) Property Tax In Jordan the property tax used to be collected by the Ministry of Finance (MOF); MOF is responsible for the main property tax activities. MOF providing DLS The property tax information is a pre-request to work on the Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 38

39 the government entities with the property tax information. property and land transactions at DLS. 6 Ministry of Justice (MOJ) Bails and Procurations Part of MOJ functions is to issue Bails and Procurations; the detail of this portion of information is of interest to other entities in the Kingdom. DLS DLS request the information of Bails and Procurations as a pre-request to accomplish the land and property transactions. 7 Cases System Part of MOJ functions is to register the details of courts cases around the kingdom JCD JCD requests the information for the cases related to the costumes business. 8 National Aid Fund (NAF) Benefiters from the National Aid Fund s (NAF) monthly assistance A total of 89,411 families are benefiting from the National Aid Fund s (NAF) monthly assistance at a cost of around JD7.152 million each month. Approximately 225,753 individuals receive an average of JD31.6 from the fund each month, according to NAF figures. Assistance targeting people with disabilities (PWD) reached JD284,180 at the end of this month, extended to 7,725 PWD. In addition, 31 individuals have benefited from JD21,132 in assistance to purchase medical equipment, while 211 families received urgent assistance amounting to JD42,760 this month. NAF provides some of the Jordanian entities with the information of their National Aid System. RHC RHC requests the information of NAF beneficiaries as part of their work on granting RHC funds. RHC need to check whether the beneficiary has another source of support. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 39

40 9 Ministry of Education (MOE) Edu-wave The Ministry of Education is the government entity responsible for the management and administration of public education in Jordan. MoE provides the avenue for enrichment and upward mobility of our people though education. NAF NAF requests the information of MoE students as part of their work on granting funds. NAF need to check whether the beneficiary has children studying in schools. 10 Ministry of Higher Education (MOHE) EMIS Part of MOHE functions is to register the students of Jordanian universities information; the detail of Registered/ nonregistered sudent is an interest to other entities in the Kingdom. Currently, few entities obtain this information from MOHE JCD JCD request (registered/ none registered) information as part of their work on granting access permission for the foreign students cars. 11 Amman Chamber of Industry (ACI) Certificate Origin of Part of ACI functions is to subscribe the information of Certificate of Origin. MIT MIT requests the Certificate of Origin as part of their work on the trademarks registry to insure the validation of their subscription. 12 Subscribers at Amman Chamber of Industry Part of ACI functions is to subscribe the firms in the kingdom; the detail of this portion of information is of interest to other entities in the Kingdom. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 40 MIT MIT requests the information the for subscribed at ACI as part of

41 their work on the trademarks. registry to insure the validation of their subscription. 13 Greater Amman Building Municipality License (GAM BL) Note: (System serves the twenty districts of the municipality in addition to the municipality s court, shamble, 14 food administration Property Tax department, and (GAM PT) community s health department System is a central one that serves the above departments through municipality s network) 15 Vocational Licensing System (GAM VL) GAM s building license web-service will provide data about the building licenses (land location, number and date of works permit..) GAM s property tax system will provide data about the taxes of the properties GAM s vocational licensing web-service will provide data about the vocational licenses MoL MoL requests DLS the building license information as part of their work on issuing work permits. The property tax information is a pre-request to work on the property and land transactions at DLS. SSC The vocational licenses information requested is by SSC as part of their work on SSC subscribers. 16 Citizen Traffic Tickets (GAM CTT) GAM s traffic tickets system web-service will provide data about the traffic tickets DVLD DVLD receive all the traffic tickets information from GAM, as DVLD is the owner of this information. 17 CSPD Civil registry All the information related to Civil registry ISTD ISTD requests Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 41

42 the civil registry information as part of their work on the government support for Jordanian families. 18 Marriage and Divorce information All the information related to Marriage and Divorce SSC The Marriage and Divorce information is a pre-requested for SSC work on SSC subscribers transactions. 19 JCD عن االستفسار الضريبية االرقام المخالفة االستفسار عن االرقام الضريبية المخالفة بهذف تخفيض ضريبة الذخل والمبيعات بنسبة % 2 ISTD االستفسار عن االرلام الضر ب ة المخالفة بهدف تخف ض ضر بة الدخل والمب عات بنسبة % 2 االستفسار عن بيانات المؤسسات الفردية والسجل التجاري 20 MIT المؤسسات بيانات الفردية ACC النظام الخاص بب انات مشترك غرفة تجارة عمان Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 42

43 5.3 Private Cloud Specification MoICT Private Cloud Solution is based on the Data Center Services (DCS) offering from CMS. DCS is comprised of a fabric in the form of one or more resource pools (clustered hosts running a supported hypervisor) and a fabric management component (System Center 2012 and associated products). A high level view of this relationship is provided below. Figure1: High-Level DCS Component Relationships While the implementation of each architecture varies based on the size, resource pool make-up (and versions), number of physical locations and workloads running within the DCS environment, the solution provides comprehensive IaaS services in a single architecture. Fabric Management DCS provides out-of-box (OOB) System Center virtualization infrastructure management capabilities with the core System Center products installed as part of the solution. The following products are leveraged within the Solution: Cloud Services Process Pack System Center Service Manager 2012 System Center Operations Manager 2012 System Center Virtual Machine Manager 2012 System Center Orchestrator 2012 Note: the fabric management components can be used to manage multiple fabrics without redeployment or re-development. If the government is to provide cloud services to the private sector, the fabric itself needs to be hosted on separate hardware, and on a separate network, for security purposes. This is so that government and non-government services are not mixed within the same hardware/network. The solution design will address this point. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 43

44 Virtual Machine Manager DCS requires System Center Virtual Machine Manager Two (2) SCVMM servers will be deployed and configured in a failover cluster during hydration using a dedicated SQL instance on the DCS virtualized SQL cluster. Operations Manager DCS requires System Center Operations Manager Two (2) servers will be utilized one supporting up to 3000 OpsMgr agents and one providing high availability. Operations Manager Installation uses a dedicated SQL instance on the DCS virtualized SQL cluster. The installation will follow a split SQL configuration : SQL Server Reporting Services (SSRS) OpsMgr components will reside on the OpsMgr VM Service Manager DCS requires System Center Service Manager DCS installs the Service Manager Management Server on two virtual machines. A third virtual machine hosts the Service Manager data warehouse server. Both the Service Manager database and the data warehouse database use a dedicated SQL instance on the DCS virtualized SQL cluster. The Service Manager portal is hosted on a fourth system with the DCS Portal. Orchestrator DCS requires System Center Orchestrator 2012 and the System Center integration packs for Orchestrator. The Orchestrator installation uses a dedicated SQL instance on the DCS virtualized SQL cluster. DCS hydrates two Orchestrator Runbook servers for High Availability and scale purposes. Orchestrator provides built in failover capability (it does not use failover clustering!). By default, if an Orchestrator server fails, any workflows that were running on that server will be started (not restarted) on the other Orchestrator server. The other reason two Orchestrator servers are deployed by default is for scalability. By default each Orchestrator Runbook server can run a maximum of 50 simultaneous workflows. This limit can be increased depending on server resources, but an additional server is hydrated to accommodate larger scale environments. Data Protection Manager System Center Data Protection Manager (DPM) 2012 is not hydrated by default in DCS v2.0 however it is installed and configured as part of a DCS solution. DPM enables VM level backups, while with customization file-level back-up will be implemented. To enable DPM, the DPM agent is installed in each desired VM and a protection group created for each. The DCS portal then can enable VM selfservice file recoveries. Configuration Manager Just like DPM 2012, System Center Configuration Manager (SCCM) 2012 is not hydrated by default in DCS however it can be installed and configured as part of a DCS solution. SCCM enables advanced inventory, configuration of baselines and other key features delivered by the product. A Primary SCCM Server is installed to handle the inventory, software distribution and software metering. Redundancy is accomplished through the Hyper-V cluster. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 44

45 DCS Portal Server DCS provides a dedicated portal interface to expose System Center functionality and allow for provisioning and management of IaaS resources. The Cloud Service Process pack in the Foundation and Advanced configurations is utilized to support out-of-box functionality with respect to IaaS management. This solution is illustrated in the diagram below with the servers/technologies hydrated by DCS 2.0; Fabric Figure 2:DCS 2.0 General Architecture 6 nodes of Hyper-V cluster where implemented in the Production Data Center a sample of the implementation figure is illustrated below. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 45

46 Figure 3:How Hyper-v nodes interconnects As illustrated above, all physical servers have 4 NICs each. HP Virtual System VS2 Solution for Microsoft [QTY:1] Rack HP 42U 1075mm i-series Shock Rack: HP 10K Rack Airflow Optimization Kit HP 42U 1075mm Side Panel Kit virtualization host Management Station One (1) HP BLc IN LCD ROHS Enclosure: 6X 2400W Platinum Efficiency FIO Power Supply bundle 6x HP Active Cool 2000 Fan Bundle (2) HP c7000 Onboard Administrator with KVM Option (6) HP ProLiant BL460c G7 Server (12) HP BL460c G7 Intel Xeon X5675 (3.06GHz/6-core/12MB/95W) FIO Processor (72) HP 16GB 4Rx4 PC R-7 R-DIMMs (192GB per server) (12) HP 146GB 6G SAS 15K 2.5in DP ENT HDD Two (2) HP ProLiant DL360 G7 Server: (16) HP 8GB 2Rx4 PC R-9 STD RDIMMs (4) Intel Xeon X5675 (3.06GHz/6-core/12MB/95W) Processors (2) HP 1GB Flash Backed Cache (8) 300GB 6G SAS 10K rpm SFF DP Enterprise Hard Drive (2) HP DL360 SL SATA DVD-RW Optical Kit Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 46

47 (4) HP 460w CS Platinum Power Supply Kit (2) HP Integrated Lights-Out 3 (ilo 3) Advanced HP Virtual Connect Individual SAS interconnect PN SAN Solution for BladeSystem Switches HP Insight Control license (1) HP Virtual Connect Flex-10 10Gb Enterprise Edition for BladeSystem c7000 (2) HP 3Gb SAS Switch BladeSystem (1) HP P TB SAS SAN Solution for BladeSystem (2) HP A XG-SFP (2) HP A G Eight (8) Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 47

48 5.4 Service Level Agreement Requirements The bidder is required to comply with the following: 1. Support Requirements defined under item Severity Levels defined under item Response /Resolution Times and Reporting Procedures defined in Response, Resolution, times for different severity levels table below. 4. Escalation Procedures and Penalties defined in the Penalties Table below Support Requirements: The bidder is required to provide the following: 1. Assign a contact person/account manager to be responsible of this contract. 2. Assign a hot line number to be used for reporting severity 1 incidents. 3. Define Escalation Procedure including the levels of escalation and name and contact details for contact person. 4. Use a ticketing system that records all incidents reported by MoICT, that can be accessed by MoICT and generate reports of various MoICT incidents. 5. Issue a service report after each site visit, to register reported incident, root cause, and followed procedures to solve issues. 6. Prepare a maintenance log sheet to be signed by the bidder support engineer, a representative engineer from MoICT/NITC Severity Levels: Severity One (Urgent) A severity one (1) issue is a catastrophic production problem which may severely impact the Proposed Edge ESB Solution Availability, In such case, part or all proposed Edge ESB Solution production components are down or not functioning; loss of production data and no procedural work around exists. Examples of Severity one cases: DB becoming corrupted or inaccessible. Severity Two (High) A severity two (2) issue is a problem where the Proposed Edge ESB Solution is functioning but in a severely reduced capacity. The situation is causing significant impact to portions of business operations and productivity of Proposed Edge ESB Solution. The system is exposed to potential loss or interruption of service. Example of Severity two cases: one node of cluster becomes down or unavailable, inability to update DB by entities representatives or solution administrators, or inability to synchronize data between DB nodes. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 48

49 Severity Three (Medium) A severity three (3) issue is a medium-to-low impact problem which involves partial non-critical functionality loss one which impairs some operations but allows the Proposed Edge ESB solution users/administrators to continue to function. This may be a minor issue with limited loss or no loss of functionality or impact to the client's operation and issues in which there is an easy circumvention or avoidance by the end user. Severity Four (Low) Important problem but it can wait no loss of functionality or impact to the client's operation and issues in which there is an easy circumvention or avoidance by the end user. Table 1: Response, Resolution, times for different severity levels Severity Response Time Resolution Time 1 1 hour 4 hours. 2 3 hours 24 hours 3 4 hours 72 hours Where: 4 8 hours One Week Response Time: Time taken to acknowledge receiving of reported incident calculated from the time sending an explaining the incident, opening a ticket on bidder ticketing system, or conducting a phone call with the assigned support engineer by the bidder or bidder s first line of support. Resolution Time: Time taken to solve the reported incident completely. Resolution Time is calculated from the end of the defined response time for each severity level as shown in the above table Escalation Procedure and Penalties: For incidents classified as Severity Level 1, 2, 3 & 4, if bidder: 1. Passed the Response Time: first level of escalation will be applied by notifying winning bidder s Technical Support Manager or the assigned contact person. 2. Passed the Resolution Time: MoICT is entitled to fix the problem and to apply penalty on the winning bidder in accordance with the following criteria in the below table and all costs incurred by MoICT for fixing will be charged to the winning bidder. However in all Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 49

50 cases the maximum total penalties that the winning bidder shall be charged shall not exceed 15% of the contract value. Table 2: Penalties Severity Definition Penalty 1 Must be done, essential to business survival. Business can t continue 2 Should be done, near essential to business survival. 3 Could be done, high benefit to business if time and resources are available. A penalty of 50 J.D. shall be applied for each hour pass the resolution time. This penalty shall continue for the first 24 hours (50x24). If delay continues, then the penalty of 500 J.D. per day shall be applied and for the maximum duration of 3 days; after that, 3 rd party will be called to fix the problem. A penalty of 100 J.D. shall be applied for each day pass the resolution time. This penalty will be applied for the maximum duration of 4 days; after that, 3 rd party will be called to fix the problem. A penalty of 50 J.D. shall be applied for each day pass the resolution time. This penalty will be applied for the maximum duration of 5 days; after that, 3 rd party will be called to fix the problem. 4 Important problem but can wait A penalty of 50 J.D. shall be applied for each day pass the resolution time. This penalty will be applied for the maximum duration of 10 days; after that, 3 rd party will be called to fix the problem Preventive Maintenance (PM) The winning bidder is required to provide the following visits for the purpose of PM on the hardware equipment and software from the date of the preliminary acceptance by MoICT. - Site visits to NITC one time for each month for the first six months and one time for each quarter for the remaining maintenance period. - Certified engineer with transportation who must present during all PM visits. - Checking all the items that are included in the checklist that will be provided by MoICT. - A PM form that must be signed by the winning bidder team, the MoICT. - Compliance with the PM schedule that will be provided by MoICT. - Solution to all problems found during PM visits. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 50

51 5.4.5 Penalties for defaulting on PM A penalty of 100 JD per visit per location will be charged for not accomplishing the PM aforementioned responsibilities Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 51

52 5.5 E-Government Program Background and Implementation Framework This section provides background material and information relating to this TOR. Nothing in this section shall be construed as a representation on the part of the Ministry of Information and Communications Technology (JOB) as to the JOB s future conduct or the project schedule. E-Government Program Background E-Government is a National Program initiated by His Majesty King Abdullah II. The purpose of e- Government program is to enhance the performance of government in terms of service provision, efficiency, accuracy, time and cost effectiveness, transparency, customer centricity, customer satisfaction, cross-governmental integration, and the way government is perceived. The e-government Program will support government transformation, using ICT tools to achieve the ultimate National goals of public sector development. This transformation process requires a focal point of contact to coordinate the efforts between Government entities and support them with best practices and subject matter expertise. The Ministry of Information and Communications Technology is responsible for the e-government Program which facilitates and provides support services to Government entities in the areas of Program Management Office (PMO), project management, change management, technical management and support services, risk management, quality management and others. The role of the e-government program is to plan, facilitate, manage and supervise the implementation of e-government through: Business Process Re-engineering (BPR) towards better and more efficient processes, human performance development (including knowledge transfer and training), organizations review and re-structuring to achieve greater efficiency. Additionally, the e- Government deploys best practices and latest technologies to enable Government stakeholders to implement new processes and create a knowledge-based community. The scope of e-government Program includes: Planning of the e-government Portfolio (including selecting priority e-services) Guiding and instigating Change Management efforts Determining technological standards for products and services integrated with e-government Infrastructure (Portal, Secure Government Network) Establishing Technical and Information Security Standards, Program and Project Management methods, Change Management standards, procedures and tools, and reporting requirements for e-government Projects across the Government entities Describing standards for e-government Infrastructure (e-government Architecture Framework (egaf), IIF, Reference Architecture) and developing other technologyoriented initiatives in order to establish a service-oriented and collaborative environment for e-services. Developing and supporting e-government strategy and providing support to its operations. The e-government Program has recently completed its 1st Wave of e-services (five Fast Track projects). The 2nd wave of e-services, which started in 2006, comprises a number of cross-organizational e- services. Objectives of the e-government Program The objectives of the e-government Program include: To develop and support the e-government strategy to be implemented across Government entities Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 52

53 To participate in the planning and coordinating of a sustainable national portfolio of e-government initiatives To maintain technological integration and interoperability of e-government initiatives, and encourage the re-usability of application components, to achieve consistency among Government entities for technical solutions To plan and implement security policies through a secured network environment for e- Government projects To promote and monitor a systematic method of planning, developing and implementing e-government projects To promote and monitor organizational transformation at the Ministry/ Department/ Organizational level necessary to establish effective e-government in involved governmental entities To offer necessary training for GoJ employees and transfer the knowledge at different levels (IT and non-it employees) in order to ensure proper service provision and to increase productivity and proficiency To create awareness and promote e-government activities To provide analysis and information on the status of e-government projects to sponsors and stakeholders. 1st Wave e-services The approach of the Jordanian government to development of e-government Program was two folds: developing a comprehensive strategy that defines the main building blocks of e-government, while simultaneously delivering e-services to citizens and businesses through fast track projects. Delivering e-services entailed specifying selected services and identifying them as Fast-Track Projects within the 1st Wave of e-services. These e-services were implemented in the government entities: Drivers and Vehicles Licensing Department Income Tax Department General Sales Tax Department Department of Lands and Survey Companies Control Department For each department, the analysis phase involved: confirming the overall project strategy Scoping and analyzing current services. The design phase involved: developing a strategy for the department redesigning the selected services for electronic delivery identifying organizational changes required to support the redesigned services developing a conceptual technical architecture that supports the delivery of all the services in scope defining the high level technology, functional, data and user interface requirements for the electronic delivery of each service Recommending required changes to the laws, directives, regulations, instructions and the required incorporation of the e-transactions Law. Providing a roadmap for implementation. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 53

54 Implementing, rolling out and supporting the selected e-services. 2nd Wave e-services The 1st wave paved the way for the definition of the 2nd Wave of e-services Portfolio. The scope of the 2nd wave project includes: Develop and confirm the criteria and build an automated ratings system for identifying, classifying, and prioritizing candidate e-services for the Second Wave of e-services under the e-government Program Identify, inventory, classify and prioritize candidate cross-governmental e-services that meet the criteria for inclusion in the e-services Portfolio for the next 3 years (A cross governmental service is a service that is provided by more than one governmental entity) Define each service, identify stakeholders (government entities and other), perform readiness assessment (organizational, technical, and legal) of stakeholders, apply ratings system to prioritize, perform high level design and conduct a needs assessment on all candidate e-services in the portfolio Define common components and major cross-references to define shared services amongst e-services (A shared service is a generic service that is jointly used in different service processes of various government entities). Analyze and study each of the services in the defined portfolio in terms of: - Goals achieved by the service and service functionality for the customer - Definition and analysis of the service recipients and stakeholders as well as entities cooperating in the service delivery process - Description of steps required to receive the service along with workflow diagram - Analysis of the service use pattern, frequency, volume of transactions and predicted demand dynamics - Recommended major changes and improvements in the service delivery process resulting from streamlining - Benefits resulting from providing the service in e- mode - Required access and delivery channels and shared services - Required systems for e-service delivery, their architecture and integration - Recommended e-service workflow - Legal issues associated with e-service implementation Analyze readiness of service provider in terms of organization, HR and technology. The e-services with the highest priority were selected for implementation in the 2nd Wave of e-service implementation. Implementation Framework This section provides a definition of a general framework for e-government infrastructure components that is based on the concept of the e-government Architecture Framework (egaf) and Service Oriented Architecture (SOA) as well as two other major initiatives e-government Portal and Secure Government Network that are major supporting infrastructure components for e-services. In addition to other important initiatives like the e-government Contact Center, and the Information Security e-government Architecture Framework (egaf) Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 54

55 As the facilitator of the implementation and delivery of governmental e-services, the e-government Program has been working diligently to define its target e-government federated enterprise architecture, which is meant to enable seamless integration and secure interoperability of services between distributed entities cohesively and cost effectively using SOA. The responsibility of the implementation and delivery of government e-services lies upon the government and its various entities: The e-government Program plays the role of the e-services enabler by providing the components that constitute the Central e-government Service Delivery Platform; The other governmental entities (mainly ministries) play the role of the e-services providers by composing and operating their e-services, having the choice to either outsource these services, or operate them in-house. The following diagram presents a high-level view of the various e-government stakeholders, and depicts the federated, customer-centric nature of the e-government architecture1: E-Government Users E-Government of Jordan Governmental Entities Conventional Channels Governmental Portals Contact Center E-Government Portal E-Gov Services Services E-Government Program Businesses Business Portals Figure 1: e-government of Jordan High-level View The e-government of Jordan is customer-centric, i.e. all e-services are centered on customers needs. Currently, the e-government Web Portal, which constitutes the central web informational portal of the e-government, co-exists with a number of other governmental portals. Ultimately, the e-government s portal will turn into a multi-channel, one-stop-shop for all government e-services, and will support various access and delivery channels (e.g. Web, SMS, Kiosks, etc). The following diagram depicts the main building blocks for the e-government target architecture: 1 The diagram is meant to present a high-level view of the e-government from a business perspective; hence many businesses and technical details do not appear for the sake of the overall understanding. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 55

56 E-Government of Jordan E-Government Program Identity Management Governmental Entities Services Directory Shared Services E-Government Portal Enterprise Service Bus (ESB) BPMS Technical Performance Model BPMS Businesses Figure 2: e-government Architecture High-level View As shown in the above diagram, the e-government Program will provide a central Enterprise Service Bus (ESB) that will serve as a unique point of traffic. It will take care of routing service invocations towards service providers and of returning responses back to the service clients (which could be the portal or some other service as in the case of cross-organizational e-services). The e-government Program will also provide a set of shared services (for instance payment gateway, notification gateway, etc) that can be invoked from within the context of any e-service, promoting reuse of components across the government and thus reducing the costs by eliminating the needs for dedicated implementations of components that perform the same functionalities offered by any of the central shared functionalities at the entities side. The services directory will maintain an active list of all available services as well as their interface specifications. A central identity management solution will be used to federate identities, provide (when applicable) single-sign-on, facilitate propagation of user identities and attributes across the e-government trust domain, and enable account provisioning. Finally, a central technical performance model will be put in place to enable concerned technical stakeholder at the e-government Program to monitor the health and performance of the overall e- Government and identify issues and bottlenecks as well as potential areas for improvement. In order to prevent vendor lock-in, all of the above components will be built solely upon open standards, such as Web Services, SOAP. Where necessary, all service providers shall conform to the above standards in order to interoperate with other components within the e-government framework. The e-government of Jordan Program will also provide Government Entities with an Enterprise Architecture Framework and methodology to help them in building their Enterprise Architecture in respect of the above principles. The e-government Program will also provide help and support on how to apply this framework to aid the entities during the course of the framework implementation. The e-government Program will provide all necessary documentation and support in order to enable project implementers to produce deliverables that are in line with the e-government architecture vision in the form of a Reference Model Winning PSPs shall have to access the necessary documentation. E-GAF & SOA The primary delivery models for e-government are: Government-to-Citizen (G2C) Government-to-Business (G2B) Government-to-Government (G2G) Jordan e-government program is capitalizing over the G2G, G2B, and G2C service models in order to provide information integration between the different government entities to improve government processes efficiency, easy end users accessibility, increase transparency and reduce total cost of ownership. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 56

57 The following figure depicts the different parties involved in the integration. Figure 3: Government of Jordan Integrating Participating Parties As seen in the figure above the following parties are involved in integration: 1. Government entities: Government entities form the major customer and beneficiary for the business integration service provided by the e-government central platform. G2G integration model shall introduce efficient mechanism for integrating the government entities in order to deliver G2C, G2E and G2B services. 2. Telecommunication companies: Telecommunication companies are considered business partners. The program will be responsible for providing the G2B integration services between those companies and the government entities. One example of such services can be the SMS notification. 3. Business partners: The program will be responsible for providing the G2B integration service between business partners and government entities. Example for such business partners: payment service providers (PSP) and private banks. 4. Contact center: Contact center s business is to serve the government entities end users. The program will be responsible for providing the G2B integration services between those contact centers and the government entities. The IT infrastructure in the government entities and other business partners in Jordan is heterogeneous across operating systems, applications and software packages. Existing applications are used to run current business processes; so starting from scratch to build new infrastructure is a very expensive and non-practical option. Hence; government entities should quickly respond to business changes with agility; leverage existing investments in applications and application Infrastructure in order to address newer business requirements; support new channels of interactions with clients and partners (other government entities); and feature an architecture that supports business oriented model. SOA is efficient for large and distributed systems where other types of integration are more complex and costly. Jordan e-government Business Integration Patterns The business integration patterns that will be enabled by the central platform infrastructure are: Vertical e-services integration pattern: defines the pattern in which services are provided end-to-end by one government entity. Its true that such services are provided by one government entity but their integration pattern may use some of the e- Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 57

58 government central platform shared services such as authentication, online payment, notification, contact center etc. Cross organizational e-services integration pattern: defines the pattern in which a government service requires the involvement of several government entities in order to be delivered. Composite e-services integration pattern: defines the pattern in which a service flows across multiple government entities and contribute to e-government overall objectives (e.g. GRP). Shared e-services integration pattern: shared services are defined as the enablers, providing technology-based functionality that are central to the provision of vertical and cross-organizational services. Their ultimate ownership belongs to the e- government central platform as part of the federated architecture framework. Jordan Information Interoperability Framework (IIF) The Jordan e-government program has initiated an information interoperability framework that will manage and standardize the exchange of common and shared information between the different parties involved in the e-government of Jordan such as the government entities, central platform and business partners. The IIF mandates that all the parties should speak the same language and this includes: Protocol: SOAP/HTTP(s) Content type: XML Standards: Jordan e-government standards Format: IIF format Hence each participating party must conform to the above standards. In the following figure a government entity A acting as web service consumer is requesting service from entity B (service provider). The request contains area code information. The area code information at the two entities local databases is different. For example, the area code is stored for Al-Shmesani area in entity A as SH while in entity B as 0612 as per the IIF standards. The IIF standards repository contains standardized area names and codes; for example for Al-Shemsani area the area code is The latest version of the IIF standards must exist at government entities A and B. Hence when entity A initiate a web service request, its IIF adapter will map the area codes and replace the SH with the standard area code which is When the request arrives to entity B web service interface the service will not need to do any mapping since its address data is compliant with the IIF standards. Figure 4: Information Interoperability Framework The ESB should be able to verify the request and response conformance with the IIF standards. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 58

59 The IIF adapter could be nothing more than a simple mapping code within the web service requester or provider components. It can also be part of the ESB Adapter component mentioned in the previous section. E-GAF and Business Process Management (BPM) The government entities in Jordan will provide cross organizational services whose logic is distributed across other government entities and business partners including the central platform. The main provider of a service [Principle Service Provider] will host the workflow of the Cross Organizational Service. Hence, the national ESB of Jordan will not host the workflow of any Government Entity Service, nevertheless, it should enable integration between different entities services to constitute a Cross Organizational Service. A government entity will utilize the central platform integration services published web services, and other government entities published e-services to compose the business processes for their cross organizational e-service. The following figure depicts the relation between the integration infrastructure provided by the e-government central platform and the BPM components at the government entities premises. Figure 5: E-GAF and BPM As depicted in the figure above, the application in government entity A starts a business process that includes executing tasks at government entity B, C in addition to the notification services provided by the e-government central platform. The application at A will communicate with the Business Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 59

60 Process Management System (BPMS) component2 at its premises to execute the complete process. The BPMS component invokes the entity B Web service (WS-B1), entity C Web service (WB-C1) and the Notification WS web services according to the rules that had been set earlier in its rule engine. Enterprise Service Bus Although building a point-to-point link between a consumer and provider is direct, a large number of interfaces such as the situation in e-government of Jordan will lead to the buildup of a complex mass of links with multiple security and transaction models. When routing control is distributed throughout the infrastructure, there is typically no consistent approach to common services such as logging, monitoring, or systems management. This type of environment is difficult to manage or maintain and inhibits change. To overcome such problems an ESB is introduced. The Enterprise Service Bus (ESB) is emerging as a service-oriented infrastructure component that makes such e-government large-scale implementation of the SOA principles manageable in such a heterogeneous world. An Enterprise Service Bus (ESB) is a pattern of middleware and software infrastructure that enables Service Oriented Architecture (SOA) by acting as an intermediary layer of middleware through which a set of reusable Government Services are made widely available. It unifies and connects services, applications and resources within the government of Jordan and provides a framework within which the capabilities of business' applications are made available for reuse by other applications throughout the organization and beyond. An ESB helps enterprises obtain the value of SOA by increasing connectivity, adding flexibility that speeds change, and providing greater control over use of the important resources it binds. Unlike many previous approaches for connecting distributed applications, for example RPC or distributed objects, the ESB pattern enables the connection of software running in parallel on different platforms, written in different programming languages and using different programming models. Service consumers connect to the bus and not the service provider that actually implements the service. This type of connection further decouples the consumer from the provider and allows for loosely coupled integration as advocated by SOA. The ESB model is depicted in the following figure. Figure 6: SOA implementation using ESB ESB implements other value-add capabilities such as delivery assurance and security. It is preferable to implement such capabilities centrally using the ESB rather than within the applications that are 2 WFMS: A software application that stores process definitions and runs jobs based on those process definitions via its workflow engine component. The workflow engine is the runtime execution module. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 60

61 distributed over the entities. However, the primary driver for an ESB is that it encourages decoupling between service consumers and providers. There are 3 alternatives for an application to exchange information with the ESB: Application-provided Web service interface: Some applications and legacy application vendors have adopted the open standards market needs and have included a Web services interface. The following figure depicts this alternative Figure 7: Application-provided Web service interface Non-Web service interface: The application does not expose business logic via Web services. An application-specific adapter can be supplied to provide a basic intermediary between the application API and the ESB. The following figure depicts this alternative. Figure 8: Non-Web service adapter Service wrapper as interface to adapter: In some cases the adapter may not supply the correct protocol that the ESB expects. In this case, the adapter would be Web service enabled. The following figure depicts this alternative Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 61

62 Figure 9: Web service enabled adapte All the above alternatives of are valid and can be used by government entities when connecting to the ESB. E-GAF Integration Reference Model The following figure depicts the E-GAF integration reference mode. Figure 10: E-GAF Integration Reference Model As depicted in the figure above; the reference model crosses the different parties involved in the SOA architecture: service consumer; integration services (ESB), and the service provider. The consumer will implement the Web service client application that contains either direct calls to published Web services or calls to the orchestrated or choreographed or business processes. The provider publishes his services (atomic and composite) through the ESB. The services are enabled by a set of components (JavaBean, EJB, COM, DCOM, PLSQL etc). Such components form the bridge between the backend applications, business applications and databases on one side and the web services on the other side. The integration services at the central platform represented by the ESB form the mediator between the service consumer and service provider. The ESB provides several services and functionalities such as integration hub, services registry, security, intelligent routing etc. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 62

63 Access Layer Gateway/Portal Layer MoICT e G o v e r n m e n t P r o g r a m Security, audit, high availability, manageability are quality of service attributes for the integration model e-government Portal The e-government program launched the e-government Portal in November A 24*7 facility designed to provide a focal point for users to obtain information and services and communicate with government. The primary goal of the e-government Portal is to: Serve as online, initial point-of-contact for customers of the GoJ, both inside and outside Jordan Build a bilingual Portal website targeting Business, Citizen and Government (G2B, G2C, G2G) with a search engine, Content Management System and other shared services. Ultimately, the portal will provide a one-stop-shop for all GoJ web presence, providing a central framework for organizing and presenting information and services offered by the entire Government via multiple access channels. The portal is a sophisticated and interactive communication medium designed to reach targeted users with timely and accurate information. The concept of e-government Portal is illustrated by the following chart: PC Kiosk Contact center Mobile Other Busin ess Home Acces s Acces s Internet Portal and Content Management Data Authentication Audit & Conversion Messaging Transaction Management Payment Engine Services Secure Government Network Department A Department X Figure 11: E-Government Portal E-Government Layers Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 63

64 The technical solution that will enable the GOJ e-government vision will allow users to access, via multiple access points (initially the Internet), a common gateway, which will in turn take requests for services from the users and pass them to the back-end systems. The E-government environment consists of three layers: 1. Service Delivery Layer Access Channels: These include PC Access Internet (from Business or Home) Phone Access - IVR or VoiceXML Contact Center Kiosk Access in Public Locations Mobile Access (Wireless and PDA) Other Access Points 2. Gateway Layer Common Portal Services Hosted Shared Services 3. Government/SGN/Third party entity Layer The SGN Government Dept. Legacy Systems. Third Party entities. Content Management System (CMS) Portal content is created and approved for publication by various government entities. The content management system provides a data repository of published content the infrastructure and technology to aggregate, integrate and publish content onto the portal and other designated websites. This enables the content to be created, managed and deployed without the knowledge of the underlying technologies used for presentation to the end user. It will enable content managers from various government entities to manage their related content on the Portal in an efficient and easy manner. Search Engine A multilingual (initially Arabic/English) search engine is a vital component of GOJ portal and is implemented in parallel to the Portal Content Management System (CMS). It also relies significantly on both the information architecture and the information taxonomy/metadata approach that is to be adhered to. It provides the functionality to search for all services, information, and transactions stored on any Web or application Server owned by the government that will be provided to users. The search engine allows users to make search queries in English or Arabic. Current Portal Environment The current e-government Portal environment is based on IBM products including Websphere portal, portal Server, DB2 and Tivoli monitoring. The e-government portal has been designed with the following non-functional assumptions in mind: 1. Success of Jordan e-government portal project does not depend only on the functionality, but also on availability. Solution availability is provided through: Load balancing for service provisioning Servers (application Server, web server) Clustering for database server (for DB Servers in the second phase of the project) Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 64

65 2. The number of internet users and usage of internet in Jordan is expected to grow fast. Therefore, scalability is very important (to start small and grow fast) through scaling horizontally and vertically. The architecture of e-government Portal phase-1 has 3 functional blocks, as depicted in the diagram below,: Web proxy Servers with load balancing feature for high availability and scalability these Servers are located in a DMZ and are isolated from the internet and the internal with a Protocol Firewall node and a Domain Firewall node to provide another layer of security. The Portal production environment with portal Servers where published content is stored and a Web Content Authoring Server for authoring content. Development, staging, testing and production environments. Figure 12: e-government Portal phase-1 Front-end Servers are load balanced via Cisco hardware load-balancing devices. Web proxy Servers provide a second layer of security as end users have no direct access to the application Server (Portal). These Servers also provide load balancing functions for balancing the load between application Servers. Integration between IBM Information Integration for Content and OmniFind Search Engine provides strong search capabilities not just over the content published by internal content contributors, but also as federated search across all different external data sources. Websphere Portal Server runs on Websphere Application Server and provides the portal framework and personalization. Jordan e-government portal is mainly information serving portal in Phase I, but with future support for transactions in the next phases Secure Government Network The Secure Government Network (SGN) is a large initiative linking all government entities to a secure Government Network as a part of a recently developed Connectivity Strategy. The main role of the SGN is to provide connectivity to government entities. Currently, the following services are provided through the SGN: File sharing/exchange between government's entities connected through the SGN. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 65

66 services (electronic services that include messaging solution, calendar, personal communications tools, etc.). Inter-application communication The entities currently connected to the SGN are: وزارة التخط ط.1 أمانة عمان الكبرى.2 وزارة الصناعة و التجارة.3 وزارة المال ة.4 رئاسة الوزراء.5 وزارة الخارج ة.6 وزارة االشغال واالسكان العامة.7 دائرة األحوال المدن ة والجوازات.8 دائرة االراض والمساحة.9 دائرة ضر بة الدخل والمب عات.10 البنن المركزي األردن.11 وزارة الس احة و اآلثار.12 د وان الخدمة المدن ة.13 ادارة ترخ ص السوال ن و المركبات.14 ادارة االلامة و الحدود.15 المخابرات العامة.16 وزارة الداخل ة.17 غرفة تجارة عمان.18 غرفة صناعة عمان.19 مرالبة الشركات.20 المركز الطب الشامل.21 المركز الملك للتوث ك.22 مؤسسة رعا ة أموال األ تام.23 دائرة اللوازم العامة.24 مؤسسة التدر ب المهن.25 دائرة الشراء الموحد.26 Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 66

67 مستشفى األم ر حمزة.27 ه ئة تنظ م لطاع النمل.28 دائرة لاض المضاة.29 مركز إدارة األزمات.30 المركز الجغراف الملك األردن.31 وزارة العمل.32 دائرة الجمارن.33 د وان المحاسبة.34 مجلس النواب.35 وزارة التعل م العال.36 دائرة العطاءات الحكوم ة.37 ه ئة االستثمار.38 وزارة العدل.39 وزارة الصحة.40 وزارة الترب ة والتعل م.41 مجلس األع ان.42 مركز الحس ن للسرطان.43 وزارة الشؤون البلد ة.44 المكتبة الوطن ة.45 المؤسسة العامة للضمان االجتماع.46 وزارة الزراعة.47 وزارة التنم ة االجتماع ة.48 وزارة الثمافة.49 وزارة الطالة.50 د وان التشر ع والرأي.51 لصر العدل.52 وزارة الب ئة.53 دائرة اإلحصاءات العامة.54 دائرة الموازنة العامة.55 Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 67

68 صندوق المعونة الوطن ة.56 متحف االردن.57 صندوق دعم البحث العلم.58 مؤسسة اإلسكان والتطو ر الحضري.59 وزارة تطو ر المطاع العام.60 وزارة الشؤون البرلمان ة.61 وكالة األنباء األردن ة.62 وزارة النمل.63 المد ر ة العامة للدفاع المدن.64 صندوق التشغ ل والتدر ب والتعل م المهن والتمن.65 ه ئة الطالة الذر ة األردن ة.66 ه ئة مكافحة الفساد.67 وزارة األولاف والشؤون والممدسات االسالم ة.68 الموات المسلحة االردن ة.69 صندوق توف ر البر د.70 ه ئة تنظ م لطاع الطالة والمعادن.71 سلطة منطمة العمبة االلتصاد ة الخاصة.72 د وان المظالم.73 بنن تنم ة المدن والمرى.74 المركز الثماف الملك.75 صندوق استثمار أموال الضمان االجتماع.76 سلطة المصادر الطب ع ة.77 ه ئة تنظ م الط ران المدن.78 دائرة الشؤون الفلسط ن ة.79 مؤسسة المواصفات و المما س.80 مؤسسة المناطك الحرة.81 صندوق التنم ة و التشغ ل.82 الد وان الملك الهاشم.83 ه ئة تنظ م لطاع االتصاالت.84 Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 68

69 اله ئة المستملة لالنتخاب.85 دائرة المتابعة و التفت ش.86 (المعهد الوطن للتدر ب )سابما معهد االدارة العامة.87 دائرة اآلثار العامة.88 ه ئة األوراق المال ة.89 وزارة الم اه.90 المجلس الطب األردن.91 المؤسسة االردن ة لتطو ر المشار ع االلتصاد ة.92 المد ر ة العامة لموات الدرن.93 دائرة االفتاء العام.94 و ازرة االتصاالت وتكنولوجيا المعمومات.95 المحكمة الدستور ة.96 مبنى النظام المال الموحد.97 مد ر ة الخدمات الطب ة الملك ة.98 ادارة األزمات ف الموات المسلحة األردن ة.99 مستشفى الزرلاء الحكوم.100 The following diagram illustrates the current SGN architecture: Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 69

70 Figure 13: current SGN architecture Upon request, MoICT will provide the winning bidder with related document(s) describing in detail Connectivity Strategy and detailed requirements related to SGN e-government Contact Centre The vision of the Contact Centre Initiative is to support the transformation of Government into a customer-centric organization a paradigm shift in the way the public sector operates. The E- Government Contact Centre program aims to create a solution to support the interactions of each government entity with its stakeholders. In order to reach that vision, the maturity model depicted below has been developed. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 70

71 Figure 14: NCC Maturity Model and Roadmap In its final maturity level, the Contact Centre should be seen as one of the access and delivery channels of the government including to traditional channels such as face-to-face or post and modern channels like the Internet. In addition, the Contact Centre will be a support method for modern channels Information Security Information Security spans all phases of e-government, and all layers of the e-government enterprise architecture. It is both a guiding principle for e-government and an attribute of the ICT infrastructure. Hence, it is a high priority to: Develop and execute an Information Security Roadmap for e- Government that covers important security issues Issue Information Security policies for the Government of Jordan Develop and apply information security standards, practices and measurements. A Security Assessment has been conducted. As a result, the information security unit will have a number of projects and actions that will be delivered as part of the e-government program roadmap over the next 3 years. Edge Enterprise Service Bus RFP Confidential and Propitiatory P a g e 71