For commercial configurable packages such as Murex, Summit, Sunguard, Calypso…, banks (big or small) are more likely to deploy to middle/back office where differentiation is unimportant. In contrast, Front office (eg. pre-trade pricing) is competitive among banks, and involves traders’ personal views, models, strategies and entire proprietary product creations. If you use software package, such a unique competitive edge is sometimes achievable by configuration, but only up to a limit. Beyond that limit, you can write plug-in modules for the vendor product (such as pricing modules) but up to a limit. Beyond that limit, you can request features but vendors are slow and/or expensive. Therefore, bigger investment banks choose Build over Buy. You can engage an external consultancy, or hire your own developers.
Middle/Back office includes booking, position master, PnL, risk, STP, clearance/settlement, GL, cash management …
Another Example — Charles River is an OMS/EMS software vendor, popular with small buy-sides. Selling points include rich feature set out-of-the-box, extension points in the form of plug-in modules client programmers can create. The last resort (Avoid!) for a desperate client is a formal Feature Request to the vendor. May take a long time. This is the dark side of the Buy (vs build) route. Vendors like to defend themselves by playing up the rich and extensible features, superior software quality, and quick FR turnaround.
ETL vendors are interested in middle/back office, and front office too. I feel CEP, Distributed cache vendors … are competing for the same customers.
For a large trading desk’s front office, the Build route is preferred. An Asia regional bank’s trading/eCommerce IT head told me.
Another practical way to customize is to add stored procs into the vendor-designed database schema. Read-only procs are powerful and safe, but functionally limited. Next level is DML stored proc. This requires intimate knowledge of table relationships. I feel with practice some API users can master it.