"Programming today is a race between software engineers stirring to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Unknown
Many public finance businesses are grappling with the "build vs buy" question as it relates to their analytic tools. I've commented here on the challenges of building good financial software and frankly, most firms that aren't specifically in software
development are poorly equipped to do so. And this is a tangentially related and important question.
Of course, build vs buy is not a new question generally but it may be new to some in financial services. The most succinct variant of the common wisdom on this is in this infoworld article . Here's the bottom line from the article:
"Decades of trial, error, and egghead analysis have yielded a consensus conclusion: Buy when you need to automate commodity business processes; build when you're dealing with the core processes that differentiate your company."
There's an interesting dynamic about the technology "backbone" behind a public finance business (providing accurate/current debt profiling, refund screens, historic prices and reset histories from EMMA, bond and option valuation functionality, etc). Although these may be commodity business processes that every banking/advisory/investment firm must do in one form or another, that data backbone serves as the foundation for proprietary analytic tools and reports that can differentiate one from the rest.
At IA, we do both automation and innovation so that the workflow public finance analytics need to support are fully addressed. This allows us to be far more efficient and effective in designing each.
Other good "build vs buy" articles here:
Comments