It depends on the existing system you have in place. Most real time systems have multiple components which need to communicate with each other without introducing delays ... You can't just pend on a single queue waiting for events(or poll multiple queues). I believe some people reverse engeneer IB interface so they can bypass the threads/queue and work directly on socket level. For FIX, I chose to implement my own engine (very basic, not fully compliant) to avoid having too many threads. That's one of the problems giving estimates, you need to know the existing system to get an idea of what the amount of effort required. And it will take more than an hour just to come up with a proper solution/proposal. If you are, or ever dealt with, programmers you know you can never get a straight answer ... It's always - "it depends"
I got locked into IB by writing a bunch of code for the TWS API and then stuck with them far longer than I should have and otherwise would have because of it. Using FIX makes that a lot less likely to happen, although keep in mind that you most probably will still have to do some work on your code if and when you switch brokers, just not nearly as much.
This is helpful. I have structured my current OMS this way and so based on what you are saying we can abstract out the broker specific apis from our general OMS functionality... if we can do so with TWS and FIX, one can have an OMS one for each with common reusable oms functionality. this is a clean approach. thanks