Monday, February 25, 2008

How to take Build vs Buy decision in case of Software Products?

In the world of software development once in a while everyone reaches that crossroad where he needs to decide - Should we build that software or buy it? Build vs Buy !! Deal or No Deal !!

Here are suggestions that will help you. When making a Buy vs Build decision do the following:
  • Consider only the costs that are affected by your decision (example you may or may not decide to buy additionaly 24X7 support)
  • Include all Opportunity Costs (are you going to miss on some other core oppurtunity / project in your own industry)
  • Ignore Sunk Costs, these are costs that have already been incurred (example can be hardware cost as either version of bought or in house build software will require similar hardware)Calculate total costs of each option. Total cost = fixed (avoidable) costs + variable (avoidable) costs
  • Considering "Soft" or "Intangible" cost/benefits, for example future use of product or learning, team reputation or burden (in terms or learning or development), derivative products.

Other Important Hints/Viewpoints
  • A very important consideration is to look at the Marginal cost i.e. the cost for deploying an additional host (cpu) with the same software.
  • For coming up with oppurtunity cost - look at the nature of technology/product and its maturity level - analysis in the Short Run and in the Long Run
  • Look at the service/product provider and its industry - will you be price taker or price chooser? How much can you negotiate? What are hidden benefits/costs of partnership?
  • Evaluate options using the net present value (NPV) & internal rate of return (IRR) approach
  • A little known fact is about the Basic Accounting ... Is it favourable for company's accounting? - This is very important as software bought is a depreciable asset for organization while software built will be treated as an ongoing expense without any balance sheet asset created out of it.
Hope you have some food for thought and solid points to make your case in your next board/council meeting.
Arvind

Sunday, February 24, 2008

Does the best technology & architecture guarantee a successful SOA or BPM?

Have you ever wondered that given best technology & architecture ...Are you guarantee a successful SOA or BPM project?

Answer is a simple and a big NO.
There is much more to a successful SOA or BPM implementation & adoption then just choosing the right tools and technology and architecting the finest blueprints. The best and brightest team of IT architects and engineers definitely help to do the toughest of design & implementation projects .... but that is just half the task.
Embracing SOA or BPM or for that matter any new initiative like WEB 2.0 and Collaboration is a major change for the organization. By nature changes are difficult as people see change with a grain of salt and skepticism.

Hence the Architecture Community has an additional and significant responsibility to be the "Change Agents" in the organization. They need to understand basic human nature & group behavior in order to be successful in their SOA or BPM initiative. They need to understand that shift in attitude seldom comes at once. The rate at which different groups, divisions or individuals will adopt these changes will vary by individual, or the type of change or the organizational context.

They need to identify these stages of change and simultaneously work on those while doing their core IT or Business job.
Understand that it is not sufficient for just you to have adopted this change. You have to guide and lead the larger community through the various stages of change, namely
1) Awareness
2) Interest (people develop curiosity)
3) Trail (skepticism is overcome)
4) Adoption
I will further share my experience about managing change during these various stages in some later blog or if there is an interest in the community.

Arvind