Build V. Buy - Be Careful What you Wish For
We develop software all day, every day, and it is generally pretty difficult. Therefore, I'm always surprised when I encounter a potential customer in a build v. buy mode.
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):
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?
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?
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?