Migration & Enhancements of Municipals Trading System (MUNI)

Table of Content Background Functional Overview of Municipal Bonds Trading Business Objectives For Muni Project Key Challenges Faced Solution: The Time to Act BACKGROUND Our client’s businesses encompass a broad range of financial services asset management, banking and consumer finance, credit and charge cards, insurance, investments, investment banking and trading and use diverse channels to make them available to consumer and corporate customers around the world. The group has a huge global presence including Asia Pacific, Middle East, Europe, America, Latin America, Mexico and Japan. Our client is largely organized into five business groups. FUNCTIONAL OVERVIEW OF MUNICIPAL BONDS TRADING The Municipals trading system (referred to as MUNI, throughout the document) is a comprehensive suite of integrated applications that facilitates the Municipal Business Division in Trading of Municipal bonds and making markets across segments including Institutional, Retail, and B2B e-Commerce (middle market). MUNI facilitates trading by providing bidding, ticketing, positioning, pricing, and offering functions through front office platform. MUNI also has interfaces with other systems. It posts trades to the Mainframe TMS system, which is the books and records of the fir m. It sends retail offerings to the BOSS system, which is the retail distribution and order, capture system. It sends middle market offerings to the MuniCenter, which is external B2B distribution partner. MUNI also provide archives of trading activities for daily and historic reporting and analysis. Municipal Trading systems are dependent on other systems that maintain bond data, counter. BUSINESS OBJECTIVES FOR MUNI PROJECT: MUNI architecture contains client and server components running on Solaris 2.5 machines. The high level goal of the project is to migrate server side components on Solaris 2.8 from existing Solaris 2.5 machines, by making minimal changes to client side components on Solaris 2.5. The project deliverables includes migration, enhancements and end to end testing of the system. End to end testing includes understanding of the systems, documentation of test cases and execution of the same. The features and upgrades that were required to be implemented on the client side and server side are listed below: Municipal Trading Systems - B2B Etrading, Bid Wanted KEY CHALLENGES FACED MUNI system is developed using multiple sets of technologies and multiple interface points with various external systems. Key Management / Environment Challenges faced during the project: Quick & detailed understanding of the MUNI system functionality to develop test cases for end-to-end testing. Effective change management to handle some major decisions during project life cycle. E.g.: Decision to change Server side Orbix layer to RMI, Decision to use Weblogic 8.1. Achieve aggressive delivery schedule in spite of major outages in external dependencies like Municenter, BOSS etc. Major co-ordination challenge to execute parallel testing by Xoriant and the client using the common test environment. Dependency of packages within MUNI also caused a delay at times in testing of the complete flow. Key Technical challenges faced during the project: Provide multi-OS support i.e. Create packages (unit of code), which can compile on Solaris 2.5 and Solaris 2.8 as well. Re-engineer server side components from CORBA to RMI. Development of 2 packages from C++ to JAVA Migrate the code for few legacy libraries Migrate from weblogic5.1 to 8.1. Promotion of 6 sub-systems into production within 3 months was walking a tight rope. SOLUTION: ‘THE TIME TO ACT’ The Xoriant onsite/offshore ‘Hybrid’ team was formed to achieve project goals through execution of mammoth task in aggressive delivery schedule. There were 15 members in India team and 4 on-site. The team was formed with importance given to experience and also young talent. There were many members in the team who had knowledge & experience of working on the client projects, client environment & client processes. There was a special thrust on “Quality” of deliverables & the Xoriant team achieved the desired results through: Implementation of CMM-4 compliant standards in internal project execution framework developed by Xoriant. Adherence to coding standards. Developers fill up migration check list before submission of the code to QA Strict code review process before QA team starts testing on a particular piece of code. Code review list was prepared based on the past experience of the client projects and the specific requirements of MUNI project. Project AUDIT done by the SQA within Xoriant to ensure that all documents, checklist, review documents, release logs were updated, available to everyone and followed by everyone in the team. The technical challenges were addressed through: Technically competent team members with expertise on multiple technologies Knowledge repository in Active community. Learning documents created from past client projects. The management challenges were addressed through: Effective project planning & tracking Communication within the team (onsite/offshore) and with the customer was given utmost importance, since correct communication is the key for success. There were technical leads on both sides to ensure that the project was going in right direction and issues were resolved based on priority. Daily meetings of the key people on both sides, weekly meeting with client and twice a week meeting of entire offshore team ensured no loss of information. Daily deliverables for each team member and project status were circulated to entire team in e-mails to avoid any communication gap. All the queries / defects were recorded in a bug tracking system and they were tracked till the closure. Daily Automated reports indicating the query / defect status against the team member were sent to the entire team. Presence of 4 onsite team members ensured that the queries raised by offshore team were resolved with the help of the client SME (Subject Matter Expert). The onsite team was in constant touch with the SME’s to gather detailed knowledge of each system. Weekly Management reporting for status, risk management & issue escalation Client-Side (will continue to be on Solaris 2.5.1) Compile using version 4.2 Upgrade Orbix version 2.3 to version 3.0.1 Rehash SSE Client Library API(s) into a separate library Recompile RNet source code on Solaris 2.5.1 and wrap it in the Municipal package. Ad Apply the necessary changes for obtaining all passwords through an encrypted mechanism. All passwords will be stored in encrypted format on the application servers. Application code, needing access to the passwords, will decrypt them through appropriate password decryption APIs Server-Side (will be migrated to Solaris 8) Forte 7.0 for C/C++ compilation Java 1.3.0_04 or 1.4.x1_02 Perl from 4.0 to 5.0 (or 5.6) TIBCO RV from version 5.3 to version 6.9 Sybase CT-Lib from 11.1.1_8147 to 12.5_32bit_10072 MQSeries version 5.3 JConnect to version 5.5 Log4J to version 1.2.8 WebLogic to version 8.1, EJB to 2.0 XML Parser upgrade from IBM 3.1 to Apache 2.2.0 Migrating 2 components from C to JAVA (Enhancement) Migrating Orbix Code to RMI on Server Side Components. Move all cron jobs to Centralized Autosys version 3.5