0

OK, so please tell me if this is the worst idea ever, or if it might have some merit. Here it goes:

I have a customer who uses a legacy application that stores data in an Omnis database file (*.DF1). This application manages reservations and bookings for campgrounds, and is locally hosted on a server that runs at my customer's site. The customer is able to take reservations online via a third party bookings engine, but it's not quite fully automated - the site manager has to upload an availability list to the booking site, and then even once a booking is made, the manager has to call and confirm the reservation (most likely because due to sync issues it's possible to double-book).

Only around 5% of reservations are currently made online; the rest are by phone. We're looking to tilt that drastically in the other direction as we ramp up online marketing efforts and target new customers, so we need a way to support easy and accurate online booking in a way that can scale. The bookings engine doesn't have an API, and of course neither does this legacy application (both are actually made by the same parent company).

My initial plan is to build a set of APIs that can connect to this local database file and expose web services to allow retrieval and creation/updating of bookings. This way, the site manager can still use the app for creating reservations as per usual, but we now have control of online bookings by being able to sync with the source database. I plan to solve load issues by using an intermediary database hosted on AWS to act as a surrogate system of record. Reservations would be written into the surrogate database, then inserted into the source database.

Basically the setup would look something like this:

Website --> Bookings Web Service --> Surrogate Bookings DB (AWS) --> Java client on site-managed server --> Source DB

I do realize that there could still be sync issues here in that the site manager could be creating a booking, but I could potentially solve that by sending an email or alert when an online booking is made, so that if they are on the phone with a customer they have the latest view into what is being booked online.

Is having a separate API that can write into a database that another application can also write into a recipe for disaster? The other solution is to keep my surrogate bookings database totally separate, but then I have the issue of how we make absolutely sure that nothing gets double-booked in the main system because they would be disconnected.

Would appreciate any insight as to how people get around these kinds of issues when legacy applications meet modern requirements.

  • 1
    Have you considered a migration? Probably, the current system has recovered the initial investment. What you are suggesting seems to me a walkaround. Why don't just move to a new system? – Laiv Dec 21 '16 at 17:59
  • There are two problems with a migration to their new application. The first is that it's still the same booking system - it takes users to a third-party site that is not intuitive or user friendly. Syncing issues are alleviated, but it can't offer us the flexibility to allow users to look up availability right on our homepage and is not mobile friendly. UX is going to hurt us on conversions (it already is if it represents 5% of our bookings). Second is that this new app doesn't expose any APIs, which I need for data extraction and analytics, so I need a workaround for that anyway. – Ryan Dec 21 '16 at 19:00
  • 1
    By migration, I was suggesting killing the current one in all the senses. Tell to your company to sell a whole system migration instead of a walkaround. I think that the walkaround might not meet the customer expectations. IMHO the solution given seems to me convoluted. More likely a palliative remedy. Changing that 5℅ is speak about changing the business strategy. Like moving from smoke signals to WhatsApp. – Laiv Dec 21 '16 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.