Our Client is a large banking institution based in Europe, established in 1864.
Today the bank has approximately 421.000 clients, with a network of more than a 100 retail branches and 4 corporate centres. The Client decided to migrate its entire core banking system, and for that project they were looking for a reliable software development partner.
Download the full Case Study
The Client's core banking system consists of over 70 products that can be roughly divided into three units. The first unit is Loans, Deposits, and Risk. The second unit is the Payment System, which is divided into domestic and international payments. Digital Channels and Card Business, which includes internet banking and mobile banking applications, are the last unit.
The whole system is monolithic, and all the products within are interconnected.
The Client’s system is built on an Oracle database, while the business logic is mainly written in PL/SQL and Cobol. Newer applications use .NET WebForms with a common Masterpage. Old applications use MSS International’s WebManager. In the Service layer, there is no business logic, just an invocation of backend modules.
Our Client decided to migrate to a new core banking solution. Since the migration process is long and uncertain, they needed a trusted partner that will maintain the current system and develop new mandatory functionalities until the new system is ready.
Serengeti's task in the project was to maintain the system through handling user requests (incidents and service requests) and developing and testing new functionalities that are defined through change requests. When developing a new functionality, the old Cobol logic and screens are rewritten to a combination of PL/SQL and .NET. In addition, we have actively participated in defining user requirements, and we took on all actions in the development cycle, from estimations to implementation and stabilization.
Before the beginning of the project, our team received a product documentation and participated in knowledge transfer workshops with the developers that maintained the bank’s products before them. The team also had available support from previous developers for six months after the start of the project, for incidents that the team might not be able to solve on their own. However, they never had to use this support.
Serengeti’s team of 10 developers has worked for more than 10 years in the banking sector and has wide domain knowledge about the industry requirements and regulations. All developers have the technical expertise of technologies used in the bank system.
Preparation for the project started more than three months before the beginning of the actual project. We have analysed the system and estimated the amount of work that needed to be done. After that, the necessary size of the team was defined, and it was agreed that it would be necessary to provide 24/7 support for critical products for which we have agreed to provide passive overtime standby.
To prove that our team is ready for a job like this, we have completed a pilot project. It was a medium-sized change request that had an impact on several of the bank's products. This project went smoothly, and after it was implemented, we started to maintain the entire system.
The first part of our job is system maintenance through handling user requests. There are two main types of requests. The first type is called a Service request, and it is usually a request for information about a specific situation or a quick fix of a problem that can be done manually by the user, but it would be time-consuming. Service requests can be categorized as low, medium, or high priority. Our team solves about 90 service requests per month.
The second type of user request is called Incidents, i.e., problems that affect the bank’s business and must be solved quickly. Incidents are categorized on a scale from low to major, with low being the isolated problem that affects only one client and major affecting the whole bank. The latest is very rare but it must be solved in the shortest time possible, regardless of the working hours. We have defined an SLA response and resolution time for all types of incidents. Our team solves about 40 incidents per month.
The second part of our job is development of new functionalities through change requests. For this we use the Waterfall methodology and Microsoft Team Foundation Server to track the status of the request.
At the beginning of the process, in the user requirements definition phase, we work with business users. Our architects, who are business domain experts, consult them and propose the best way to solve a problem. After the completion of the functional specification, we have the presentation meeting between the bank’s business analysts and our developers, after which we start working on high-level estimation.
When the estimation is done, business unit that requested the change must decide if we should do the request or not. If we get the confirmation, the phase of detailed estimation and writing of technical specifications follows.
When the technical specification is done, we present it to business analysts and the business unit that created the request, to ensure we understood each other correctly. The development phase follows, and after the development is done, we do factory testing on provided test cases. If needed, we can add more test cases. In the user testing phase, we provide support to the testers and solve defects in the shortest possible time. Deployment is done through custom deployment software that the bank uses. We have monthly releases, but it is possible to schedule additional releases if needed.
After the stabilization period, maintenance is done through service requests and incidents.
What happens when everything is not going according to the plan? In April 2020, the national bank, in response to the COVID lockdown, mandated several rules which had to be implemented very quickly to the core banking system. Deadline was very short which meant we had to ignore waterfall SDLC and work agile, directly with business users. There was no functional or technical specification before the development we wrote those documents after the job have been done. Testing was done directly with business users because there was no time for factory testing. In the end, we have managed to implement all the changes in time.
However, it would not have been possible to do this with just our core team of 10 developers. While defining the team for this project, we have anticipated that circumstances like this might arise, so we have formed a team of 10 developers with additional 3 shadow developers who were in standby mode from the beginning of the project. They were junior developers who sat with our seniors who worked on the project and learned from them. When the COVID crisis came, they were ready to help with real tasks, so we have easily expanded our team.
Due to the right choice of developers, who are experts in the banking domain, the knowledge transfer process took a very short time.
Up until now, our team of 10 developers has solved more than 700 service requests and more than 300 incidents.
We have already put into production 10 change requests and are continuously working on new ones.
Serengeti's team has had 0 breaches of SLA, and all the mandatory requests were done in time.
The Client was surprised at how fast and efficient we are with our relatively small team. We have received a 5-star review on Clutch from the Client, direct praise from the board members for our effort in the COVID crisis, and our team received commendations from business users with whom we work almost daily.
Having been convinced of the high level of professionalism and quality of the service provided by Serengeti, the Client decided to put our team fully in charge of the maintenance and development of new functionalities.
The most valuable result of this co-operation is that the Client has gained a long-term, trusted software development partner.
