1. Information Technology Division Executive Office for Administration and Finance Interchange CommBridge Upgrade Introduction

2. Agenda CommBridge Upgrade Introduction Legacy CommBridge Architecture Overview – Point-to-point MQ Server 5.x, 6.x Interchange Architecture Overview – Legacy CommBridge Pattern – Additional Interchange Enterprise Patterns High Level Upgrade Project Process Next Steps

3. CommBridge Upgrade Introduction Overview of the CommBridge Enterprise Upgrade Project & SAI Team – Architecture – Configuration Options & Patterns – Goals – SAI Team – Timelines

4. Legacy CommBridge Architecture Uses Point-to-Point IBM MQ Server (versions 5.x and 6.x) for Messaging Requires use of custom coded executables (cbfxfr and cbfrcv) for file based interfaces Imposes limitations on files to be transferred (fixed record length, *.DAT, *.INF) Relies on unsupported products by IBM and Entrust

5. CommBridge Upgrade & Interchange Goals CommBridge Upgrade Goal – “Replace unsupported COTS products in current solution (e.g. IBM MQ 5.x, Entrust) with supported equivalents (IBM FTE 7.x)” Interchange Goal – “Provide a set of Enterprise Patterns for File and Message based transfers for agencies to use as a roadmap” Future Goals include migrating from these fixed integration and implementation dependent endpoints to more flexible dynamically driven solutions

6. InterChange Offerings (Present/Future) Enterprise Integration Styles – File Based Managed File Transfer (IBM FTE / JSCAPE-FTP) – Shared Database ODBC / JDBC – Remote Procedure Invocation Not Offered by SAI – Message Based Enterprise Messaging Infrastructure (MQ7 / Oracle?) Web Services (XML Gateway)

7. InterChange Style Recommendations Integration Style SAI – CommBridge Design Recommendation File BasedRecommended for existing CommBridge interfaces that do not desire to upgrade to the message based approach. Also recommended for any new requests that are one-time lightweight file transfers or for end-points that do not have messaging capability or have specific protocol requirements (e.g. S/FTP/S). Shared DatabaseNot recommended; exceptional cases may be required. This approach is not recommended since the message based approach offers a more standards based approach to providing access to a diverse set of end points without requiring platform specific DBMS knowledge or code. This approach would only be recommended in rare cases where the communicating applications have mutually trusted security credentials, require specific performance standards or must be supported for legacy purposes. Remote Procedure CallThis style of integration is not necessarily suitable for the Shared Application Infrastructure model. It would be used between communicating applications without involvement in the shared service. It may be desired for performance reasons but has drawbacks by not being based on open standards and tightly couples the endpoints. Therefore, this style would not be recommended for CommBridge interfaces. Message BasedRecommended for any existing CommBridge interface already using messaging and any new service coming on board. This is appropriate for synchronous web services as well as asynchronous queue/topic based communications.

8. InterChange High Level Design

9. IBM MQ-FTE Design Statewide FTE target topology HR/CMS WMQ V7.0 FTE Agent WMQ V7.0 Coord QMgr WMQ V7.0 Cmd/Agent QMgr SAI Zone TRE WMQ V7.0 FTE Agent DSS FTE Agent FRB FTE Agent Initial deployment of FTE will include three v7.0 queue managers in the SAI zone. One will be a dedicated Coordination queue manager and two will act as Command/Agent queue managers. Initial agency deployments will utilize FTE client agents connected to the SAI queue managers. Usage will be monitored to determine actual throughput. Agencies with sufficient volume may be upgraded to use a dedicated queue manager. Data is routed directly between queue managers hosting agent endpoints where possible. “Sufficient volume” will be determined by server utilization and agent throughput. In the diagram HRCMS and Treasury are used as examples of “high volume” nodes with dedicated queue managers but this is only a projection at this point. WMQ V7.0 Cmd/Agent QMgr

10. IBM MQ-FTE Design FTE/Commbridge Coexistence topology 4321 FTE AgentWMQ v5.3FTE AgentWMQ v6.0FTE Agent WMQ v7.0 HR/CMS FTE Agent 1.FTE coexists with v5.3 of WMQ by utilizing an FTE client agent 2.Where v6.0 QMgrs exist, FTE can use the local queue manager in bindings mode without disturbing Commbridge. 3.On high-volume nodes where Commbridge can be completely replaced, the FTE agent can connect to a v7.0 queue manager. 4.Where Commbridge does not exist or can be eliminated and the volume does not warrant a dedicated QMgr, a stand-alone FTE client agent can be used. Initial deployment of FTE agent on the HR/CMS host uses FTE client agent to allow coexistence with CommBridge. WMQ V7.0 Coord QMgr WMQ V7.0 Cmd/Agent QMgr SAI Zone WMQ V7.0 Cmd/Agent QMgr

11. IBM MQ-FTE Design FTE Post-Commbridge target topology HR/CMS 21 FTE Agent WMQ v7.0 WMQ V7.0 FTE Agent Use cases: 1.Initial deployment of all agencies utilizes the FTE client agent. 2.On high-volume nodes, the FTE agent may be upgraded to use a local v7.0 queue manager. Although HR/CMS is shown here with a dedicated queue manager, a determination whether to upgrade to a full queue manager would be made after implementation, based on observed usage, server utilization and throughput. The target topology may include a dedicated queue manager for HR/CMS. Traffic through the firewall passes through a shared SAI WMQ layer to simplify firewall connectivity and security. WMQ V7.0 Coord QMgr WMQ V7.0 Cmd/Agent QMgr SAI Zone WMQ V7.0 Cmd/Agent QMgr

12. Deployment Sequence Under Consideration HR/CMS (Going Live) – Focus on Batch File Pattern – Limited Messaging & Transformations – Pilot Lightweight Deployment Footprint – IBM MQ FTE – Pilot Operational Support NewMMIS (Proposed) – Focus on File Based Legacy CommBridge Patterns – Focus on Message Based Patterns? – Message Transformations – Upgrade Messaging Backbone – IBM MQ7 MMARS / TRE Smaller Agencies/Applications Mainframe – Diverse Footprint with Dependencies

13. Example: HR/CMS Timeframes The HR/CMS 9.0 project is anticipated to go live by mid-March 2010, at which time all legacy CommBridge interfaces must have been, at a minimum, upgraded to WebSphere MQ File Transfer Edition 7.0.1 and tested to ensure the successful transfer of files and execution of all necessary business processes. Other important dates are as follows: Late November 2009, Pre-Production The HR/CMS environment must be delivered to HR/CMS implementation team for unit testing including WebSphere MQ FTE 7.0.1. Early December 2009, First Run The first run of a basic payroll with approximately 12 outside vendors. At a minimum, the interfaces necessary to complete a payroll run must be in place by this time. Early-January 2010, Full Payroll Run. All CommBridge interfaces for a payroll run must be transferring files as anticipated and with performance equivalent to or better than performance achieved today. March 2010, System Goes Live All CommBridge interfaces for all business processes must be transferring files as anticipated and all business processes must be executing successfully with performance equivalent to or better than that maintained today. Nov 2009 Dec 2009 Jan 2010 Mar 2010

14. Typical Upgrade Project Activities Initial Interface Analysis QA / Prod Env Set Up Interface Configuration QA Interface Testing QA Interface Migration to Prod Operational Handover Dev/Test Env Set Up and Unit Testing

15. NewMMIS Specifics NewMMIS specifics – General Questions, – Touch points, – Configuration requirements for the purpose of evaluating NewMMIS impact; Change Orders? NewMMIS resource requirements

16. Next Steps Joint SAI/NewMMIS Project Planning Session – Define Project Scope Preserve Existing Interfaces? Upgrade Files and Messaging? – Identify Resources Required – Understand Project Dependencies Follow up technical session if interested – SAI Enterprise Patterns Available & Planned