Iper had existing clients who were using their service which was built as proof of concept (PoC). The PoC offered some functionality but both Iper and its clients were demanding much more features from the system. As part of the project initiation, we had to understand what are the most essential features to Iper and its clients while making sure those could be delivered in a technical and architectural sensible manner. We managed to find a common ground where these two requirements meet and that lead us to lay a solid foundation to the solution we built.
Iper consolidate data from different sources to provide meaningful information to their clients. Data from different sources should be cleansed prior to use and the frequency of different sources releasing data are different. On the other hand, the system should provide most up-to-date data to all Iper clients as that is the primary value provided by the service. Managing these two aspects with defined scope was a real challenge but we managed to overcome that with a detailed discussion with Iper and its clients.
The most critical technology challenge we faced when developing the Iper solution was meeting their requirement for response time. All Iper data were on Microsoft SQL server enterprise edition and it was required to use free text search for filtering required records. Building indexes for free text search ended up being a heuristic task when it comes to meet ranking of results for Iper requirements. With some trial and error approach we managed to tune the indexes to meet provided SLAs by client and it was an interesting experience to get involved and solve that problem.
Iper rely on multiple different sources for data for their system and such data become available at different frequencies. At the same time, Iper should be able to provide most up-to-date data to their clients and it was a requirement to update the production database with most recently received data from any source. When updated from one source of data, it was a challenging task to maintain the integrity of data with other sources. The volumes of data (usually in the scale of tens of millions) introduced a different dimension to the challenge as it was required to manage processing and memory resources also at affordable levels.
When Fidenz started developing the cloud solution for Iper, there was an existing Proof of Concept level solution in place which was used by few of Iper clients. End clients had integrated that service with their internal custom applications and it was part of our responsibility to migrate these clients to the new system. These custom applications were developed with many different technologies and the use cases were different one to another. As part of the new system deployment we started working with each client at a time to onboard them into the new platform. Initial resistance to change was as expected, but soon after they were integrated properly, they started enjoying the richness of the new service.
The system we developed was used 24×7 and upgrading and maintenance of the system was a real challenge. But we adopted few techniques where we could switch databases instantly after updates and warm boots of the system which minimized the downtime of the system so that business could continue as usual.