On the surface, and at the white board, the build decision looks somewhat 'easy'.
The scenario typically unfolds in the following way:
A manager has articulated a requirement. A local developer, or team, has a few 'extra cycles' and should be able to create some specific base functionality in a few days or weeks. I call this 'the first 80% is easy'.
It can't be that difficult, since it just involves (pick one):
- Capturing every chat conversation on a server - it's just some C++ and Notes API code
- Routing inbound IM conversations to an expert - ti's just some Java and Sametime API
- Creating a reporting system to search, report, export, and manage thousands of IM conversations - it's just SQL reporting
In my experience, it's the final 20% of any project that consumes most of the time/money/effort....and the final 5% is really, really difficult.
Putting on my 'manager' hat, I would ask the following types of questions:
Can you achieve?
- A proven, solution that doesn’t degrade the performance of the Sametime, or OCS server
- A scalable application that can handle thousands, or tens of thousands, of concurrent conversations
- Can the features match the core features of the commercial off the shelf offerings
- What will be done in the future when we move to a new version of Sametime/OCS (i.e. in 12 months when we move to ST 8.5 who will update, test, and rebuild the application)?
Ultimately: Why do we want to be in the business of recreating a product that is already available in the market, is already tested, and has the benefit of other customers, feedback loops, and multiple deployments?