Build it or Buy it?

This is the second time in as many as 6 months that we stand ahead to take a decision whether we build or buy.. eventually the first time we chose to go a SEMI approach.. pick something that can be integrated and partially built.. but it was more of a buy decision this time we havent made the decision yet, but we are about to...

I am sure this is one of your favourite question that you get every now and then???? anyways .. some tips and hints on when to switch your boards for either side of decisions...I give you our UI evaluation case study and I am sure that will help you make a decision if you land in the same bullock cart as we do.

This is a 3 fold process that involves thorough investigation on whether to build something and support it or use the off the shelf product ... I would divide this process into various stages and 3 high level folds...
1. The Business need
2. The Technology need
3. The future need

Remember any decision you make on either side you will have to consider the 3 fold approach that revolves around the above 3... We needed to build a top class UI for our future product and we had to decide on the technologies, frameworks and architectures and designs... We chose the 3 folded approach and it seems to have worked in a better way...

Approach .. and Steps : The Business need
1. Its the Google Wave that is future, do you need it?
A majority of times decision makers tend to move there directions towards buying products based on the success stories of the product, testimonials and what they hear over the Arrington world (I am not sarcastic). So what if Google Wave will do the future of collaboration but if your product or your customer doesnt see any real turn value why go that way??? I read over a friends status message that Google Wave is amazing and he would get that into his product soon... Gosssshhhh save me How would you use it a farther question??? is there a need? is your customer asking for something that ONLY Google wave can provide? The answer is difficult... sometimes looking at technology as a first step in taking a decision is probably a not so good thing to do. Lead it by checking what you need and then moving to what the available products can do.. Didnt I say sometime back "We are a Good Agile Team, We can still do with what we have in terms of Development product tools"

2. Use case 1 needs Grids, Use case 2 needs tables, Use case 3 needs rows and columns
Well wow.. does it happen? No it cant.. it will never.. You would never know the exact requirement.. but there is a eagle view of what is available,this eagle view can determine what you need and to what level... If you know the exact immediate needs to a certain level it would then mean that you can define what you can use to build.... Havent you heard from your friends that a company implemented a full ERP solution just to manage the timesheets and payrolls of their employees?? Honestly thats the case always... the step here would be to detail the needs and then decide how we build it... Technology is possible.. Business not!!!!
If you prefer to build it then think of ONLY what needs to be built... A CMS can be a blogger or a Drupal.. you have to choose what you need and build only that....

3. Time is an excuse, sip it
It has always being a major item in discussions where decision makers call a buy as less time consuming... to me it is not.. even if you get a best documented product.. there is a usability , usage and understanding which needs time before you actually spend an effort.. while making this decision you have to ensure that if you build it on your own will you be able to do it in a reasonable timeframe? A lot of time buy is used for easily build able options and build is used for easily buy able options... if you think of time you tend to make wrong decisions...
Time is an important factor but gulp it till:
1. You have exact needs you want
2. exact needs you want to build now
3. exact timeframe it will take you to build
4. time frame it will take to understand, integrate and maintain...

Approach ... Steps the Technical Need
4. Rip your architecture naked and then compare
Its an amazing product , got an amazing architecture, works with the new technologies and frameworks....
1. Does it fit your architecture?
2. Does it go well with the architecture in both its current and planned phase?
3. Would it be an overhead to migrate your existing architecture to adapt to the new integration?

If you are going to build it then:
1. Will it get upgraded with your technology upgrades?
2. does it happen to fall on a path where the frameworks/standards in use can be used without limitations?

Bring a level of nudity in your architecture and try to fit the solution.. would give a view of what to do..

5. Can you make the most of it for your technology?
When making a decision we usually think that we can mould our architectures, frameworks and designs in a way we want.. exact way we want.. we are sometimes wrong, miserably wrong... this is one area where we should be careful about... will integrating the off shelf product give you a chance to renovate your architecture? think it like this... can using JBPM mean that in future you can turn from tomcats to JBoss??? think it like this... Can using a JBoss let you evolve your Transaction Management??? Most of the times these architectures or products are aloof with a simple API access... just lets you use it.. doesnt let your architectures learn whats new and what they can improve on...

Approach ... Steps : The Future Need
6. Maintain and Upgrade or Upgrade and maintain???
Imagine your offshelf product changed its architecture (This has happened with us in the past where we had to change our interfacing architecture because the Viewing technology we use upgraded its design), will you be forced to upgrade yours?

Imagine a bug in the integrating product whose fix means a design change for your and the products design.. Are you ready to Maintain because the off shelf tool has to be upgraded?

When you build it... the question reverses...
Since its you who has built it.. you can decide to upgrade it when you think of it...(Thank god we just chose Interfacing wrappers for Castor and Hibernate) its maintain for bug fixes and upgrade when you need it...

Now if you these 6 pointers in mind I am sure you will have all possible evaluation metrics in front of you.. and then you would be able to make a better decision... just so that you get more help... An argument on the ROI is always there...
So the initial short-term cost of implementing ready to go solution is often more than a self built solution, but the ROI is better for the ready to go solution in long term... with a consideration that :
1. The adapted product takes care of technology upgrades.
2. The adapted product isolates and fixes any design, implementation.
3. The adapted product provides you the facility to migrate the data in future when you have to go away from them, there is an upgrade in the design (This is overlooked always)

Go for a ready to go solution when you are sure that :
1. The business and technical future is aligned.
2. It can meet majority of your needs without modifying the product’s software modules. And it meets all of what you need upfront.
3. If you think that you have a Team of Dumbasses who cannot build or maintain the custom solution you need.