We use cookies to enhance your experience. Read our privacy policy.
What partnership
means for us:
Competence,
Commitment & Haste
Don't miss the latest news.
Subscribe to our newsletter!
  • /
  • /
Some time ago when working on a large-scale project for a federal customer, OmegaLab team collaborated with the professionals from IBS. We had a chance to demonstrate our prowess in fulfilling specific tasks as well as our ability to fit into projects of the highest architectural complexity.

This case study will show you how to join an ongoing project with an extensive history, to commence work in three different areas at once. How to develop a data collection gateway in 2 months and receive positive customer feedback.

Getting started

The initial setup involved completion of the paperwork, interviewing the team members, and investigating the 4-year history of the project, which allowed us to become an official IBS partner in the process.

After familiarizing ourselves with the types of tasks we needed to complete, we joined the project with a high level of confidence.

Task description

OmegaLab team was tasked with the development of an electronic document gateway as a part of a large-scale system for thousands of users with varying access rights.

This component specifically ensures the document flow between clients and the managing organization. It allows both to upload and retrieve data, put, and validate electronic signatures, and track the movement of documents.

IBS provided detailed terms of reference describing the general system operation and the required component specifications. The work logic was already developed by the integrator's specialists. We were also provided with all the necessary access rights, extensive project documentation and the opportunity to contact experienced system developers who know all the details of its services.

There were two aspects of the project that made it stand out for us:

  • OmegaLab has been invited to work on three different areas simultaneously, which included the database, backend, and frontend

    It is more common to develop some parts, such as backend, internally and to employ an outsourced team for working on another element. But in this project, both OmegaLab and IBS teams worked together on each of its layers.

  • Apart from fulfilling the role of storage, the database should act as a business logic layer by outputting certain data and transferring it to the UI.

    This data is then synchronized with other APMs in two separate ways depending on the user behavior.

Components' functionality

  • Obtaining the entire history of document flow from a third-party automated workplace, processing and storing it in the database.

  • Obtaining online documentation from a third-party workstation, processing it, and storing it in the database.

  • Uploading the documents and electronic signature, sending them to a third-party automated workplace, processing and storing in the database of a third-party automated workplace.

  • Presenting the history of document flow with a third-party automated workplace.

Challenges

1. Lack of data for transition due to converging work areas

The work on the project started simultaneously across all development areas: database, backend, and frontend. In our case, the database not only serves as storage but also generates data. When backend and frontend developers enter the project sequentially, the latter can immediately start working on data transition. But in this case, Java programmers who are responsible for data transition to the UI level had nothing to work with at first

Solution:

Java programmers had to create fake data in controllers so that UI programmers could start their work, which took a while considering a rather strict project timing

2. Synchronization of databases

According to the terms of reference, Java not only transfers data from the database to the UI, but also synchronizes with a third-party service database

Solution:

We have built a complex system of data uploading, which successfully solves this problem. According to the module logic, there are two types of synchronization considering user behavior:

  • User documents are uploaded to the user account only after the first visit
  • From this point on, the data from the user account starts synchronization ith other automated workplaces (databases of third-party services)
  • Both types of synchronization have been successfully implemented.

3. Work coordination considering other services

Even with perfect management, such a complex project, involving dozens of development teams, implies constantly emerging issues when it comes to responsibility areas of different teams. There are situations when the service is ready to be delivered according to the timings, but the final testing is impossible because the adjacent module is still not finished

Solution:

Under the guidance of an experienced lead developer, the team was flexible enough to place plugs, initiate discussions, and make improvements aimed at high efficiency and overall success of the project. The teams developing adjacent modules have been tasked with providing mock data for verification

4. Tight deadlines

Only 2 months were allocated for the whole project. Considering that it took a week to form the team and familiarize it with the features of the system, there was no room for error

Solution:

The entire team was composed of experienced mid to senior level developers. From the very beginning, we actively communicated with IBS, as well as with other project teams. We once had to investigate why the service, common to several teams and necessary for testing our part of work, was not functioning right. We figured out the problematic areas, fixed the issues, launched the service, and handed in our part of work on time

What we got lucky with

It was a blessing to work with such qualified professionals, as IBS: the architecture of the module and its business logic were clearly planned and detailed in the TOR - they were fully implemented without any hiccups. IBS also maintains extremely well-organized project documentation. Without that, a quick immersion and implementation of the project in such an extremely short time would be impossible.

The conclusion based on the joint project with IBS

  • Fast and high-quality recruitment tailored to the client's needs is the decisive factor in choosing a partner by the integrator.

  • The ability to work simultaneously with the database, backend, and frontend, to take full responsibility for a separate unit of work makes it possible to consider the company as a partner for a wider range of tasks.

  • For a successful module development, it is necessary to understand the operational processes and timing of other teams on the project and take the initiative.

  • Short project timeframe does not necessarily imply chaos and lots of uncontrollable processes.

In the end, we were able to successfully fit into a large-scale project that continues to evolve. Thanks to clear communication with other teams, we fully completed our part of the work in a noticeably short time with a highly satisfactory result.

It is safe to say that OmegaLab and IBS became a single team during this project. After all, IBS employees were among members of the working group run by a lead developer from OmegaLab.
Projects
Solutions
Consulting
& Other Services
About
Product Vision
Analytics
MVP project development
Mockup design
Product roadmap building
Software development
© 2024 Omega Lab B.V.
VAT 861621220.B.01
Utrecht, the Netherlands
Goeman Borgesiuslaan 77, 3515ET