|
We work in client environments that encourage and welcome technical innovations. It allows us to combine advanced technologies with our creative designs, to formulate cutting-edge solutions to fulfill our clients’ needs. We strictly contain the risks associated with these unprecedented solutions by in-depth technological validations and thorough production simulation tests, before these solutions are deployed in the production environments.
 End-to-End Metro AA DR Solutions over Extended Distance
Standby Metro Disaster Recovery Centers with extended distance has been the industry status quo for years. Majority of the equipment invested in the Metro DR Centers are idle most of the time, except for development and testing purposes. Our client tabled the following desires for their Metro DR investments back in 2008:
-
Make effective use of their idle MIPS in their DR Center with 70 KM fibre distance away from their Production center
-
Ensure that business operations can be resumed within 10 minutes when disaster occurs
-
Ensure zero data loss for DR failover and fallback
-
Provide acceptable transaction response time
Our client’s banking operations rely on applications that run in the mainframe and open systems, the design must cover all the key applications in both systems. When a disaster occurs, all major applications in these systems must be resumed within 10 minutes without data loss.
-
In 2009, we teamed with our client to bring their mainframe Metro Active-Active solution to life. The mainframe systems in the Primary and Secondary Centers participate in a cross-site Parallel Sysplex with DB2 Data Sharing. Both Centers are active and they receive and process business transactions at the same time. In Active/Active mode, the idled mainframe MIPS in the Secondary Center are effectively utilized. This actualization of mainframe true Active/Active architecture brings saving to our client, and allows them to have flexible processing power to handle workload spikes.
-
In early 2011, we assisted our client to simulate disasters that target their Primary Center, to confirm that their Metro AA DR architecture works according to design and meets all their requirements. We conducted in-depth studies of the applications and application environments to iron out all the single-point-of-failure (SPOF). We designed and simulated extensive component failures, application failures, subsystem failures, and system failures to ensure that the architecture and failover/fallback procedures worked as design. When zero risk was assured, we assisted our client to conduct AA DR rehearsals on the Production system for both planned and unplanned outages. For planned disaster failover, no interruption to the business operation was observed. For unplanned disaster, Primary Center workloads failed over to the Secondary Center in 7 minutes and normal business operation resumed. Workload fallback to the Primary Center was automatic and was transparent to the business operation.
-
Using the same concept and design principle, we continued to build Metro AA DR solutions for critical banking applications in the open systems. In 2012, the first Metro AA DR solution in our client’s open systems was successfully launched. Based on this success, we teamed with our client to deploy key applications throughout 2013. In early 2014 after extensive testing and technical validation, our client conducted an AA DR rehearsal on their Production systems. Planned and unplanned disaster failover and fallback were smooth and successful, meeting all the RTO and RPO requirements.
Our client have been effectively using their idle mainframe MIPS in the Metro DR Center since 2009, resulting in significant reduction of total MIPS requirement which deferred the need for CPU capacity upgrade. Substantial saving is achieved through this AA DR architecture. Our client’s business is better protected against any natural or human triggered disasters. Key banking operations can be resumed within 10 minutes even the Primary Center is completely down.
SOA Based Mainframe Core Banking System
To meet with challenges of the fast growing, dynamic and highly competitive financial market, our client needed a faster and better way to deliver banking products and functions to better support their business. Our client sought our consultation for infrastructural solutions in their Core Banking System which must be:
-
Agile to meet the dynamic financial market needs
-
Able to deliver functions rapidly for business demands
-
Able to adapt to future architectural changes, including portability to the open systems
The requirements of agility and speed-to-market led us to look into Service Oriented Architecture (SOA). The mainframe based Core Banking System connects to and interacts with all major application systems (both mainframe and open systems). The new application architecture must provide standard interfaces, message exchange formats and rules for the service requesters/providers to these systems. A few Proof of Concepts (POC) were conducted to iron out critical technical uncertainties. Certain business functions from the existing Core Banking system were selected to build a prototype based on SOA design. This exercise helped us and our client to better understand the techniques and processes required for the identification, specification and realization of services, their flows and composition, and the enterprise-scale components (Platform) needed to realize the quality of the services. After series of functional/performance tests and revisions to the original design, a preliminary enterprise-scale architectural design was formulated. The new architecture and design was approved by our client, and a major application architecture reengineering project was launched.
To help realize the new SOA architecture, we created a SOA Development Tool to assist our client to develop and govern components, services, service flows, data structures, standardized interfaces, message exchange formats, data dictionary, and documents the applications during development. We participated in the development of the enterprise-scale common services (Platform) to speed up and support the application development. To monitor the business transactions that go through the system, we created a new business transaction monitor that ties business transactions with key performance indicators.
Due to the scale and complexity of this Core Banking architectural reengineering project, the application development and deployment are done in phases. After 2 years of extensive development and validations, the roll out of overseas branches was successfully deployed in 2011 through 2012. Built on this success, the development and refinement of the application continued. Working closely with our client, the first pilot domestic branch was successfully deployed in late 2014.
Business transaction Monitoring System
Our client needs a monitor to track business transactions and associated performance indicators. Sunflower was invited to design and build a tailor-made monitor to provide:
-
Real time monitoring of each business transaction for its time-spent in all system components, resource consumptions status and processing exceptions
-
Proactive alerts when abnormality in processing pattern and/or resource consumption is first detected and confirmed
-
Useful information for application problem determination
-
Automatic abend analysis and reporting
-
Historical business transaction volume and performance data for trend analysis and proactive tuning
-
Historical business transaction data for business pattern, trend and customer behavior analysis
Based on our in-depth understanding of our client’s Core Banking application system, Sunflower designed and deployed the Application Monitoring System (AMS) which bridges the gaps between applications and system components. Our design is a two-tier application structure with a combination of system and application programming. Data collection is done in the mainframe where the business transactions take place. Data processing, analysis, storage and presentation are implemented in the AIX server where the end users are connected. This structure allows minimal usage of mainframe resources and provides flexibility for future changes. With the introduction of this monitor, problems are able to be resolved/prevented before they have a chance to cause major impacts to the business operations. This monitor has been well received by our client, and it becomes an integral part of the Production environment.
Application Architecture Restructuring
Our client enjoyed a rapid expansion in the credit card business. Due to the credit card software design limit, transaction response time suffered during the peak hours and repeated production incidents were reported. Our recommendation was to run the application with multiple CICS regions in a CICSPlex environment, to lift the single TCB limitation. However, for the limitation of precedent experience, the client was caught in a dilemma - to put up with the processing/operation issues by application running in many standalone CICSs; or to replace the credit card application completely. Neither was a good option to our client.
Sunflower was requested to design, implement and deploy our recommendation. We worked closely with the client’s application team to conduct a detailed application study with focus on the application affinity and dependency. We designed an application/system architecture to allow the application to run in a CICSPlex structure. Application changes were made to resolve the affinity and dependency issues. Load balancing among the CICS regions was effectively addressed. Repeated load tests and production simulation tests were conducted to validate the integrity and performance of the new architecture. This new application architecture was deployed smoothly to production in 2007.
With this new application/system architecture, AORs can be added when business volume demands for it. The limiting factor that hindered our client’s credit card business expansion was lifted. From 2007 to 2014, our client experienced a 12 folds increase in their credit card business. This application architecture effectively supports our client’s business growth, with improved response time and system availability.
Batch Automation
Our client needed to replace their Core Banking application batch scheduling function with Control-M job scheduling software for better batch monitoring, management and reporting. The application provider proposed extensive application changes and a long running project. The costs, time and complexity would have made the project unjustifiable. Sunflower was invited to conduct a feasibility study for better alternatives.
Through detailed analysis of the application batch processing flows, rules, exception processing, vendor scheduling functions and Control-M scheduling process, we proposed a solution that bridges the vendor scheduling functions to Control-M scheduling process. Our solution did not require any change to the Core Banking application which significantly reduced the project risks and time for deployment. With some system and application programming, our solution is fully automatic and is transparent to the batch operators. This batch automation solution was successfully deployed to production within a few months after the project was approved.
|
