Blog Home  Home Feed your aggregator (RSS 2.0)  
Rays Development Blog - Build Vs. Buy - Innovation or stagnation?
A look into the mind of a VB Developer
 
# Sunday, 21 June 2009

Let’s be clear, to innovate you need to reach.

There are many companies that I have run into over the years that have continuous innovation as one of their core values, but have a buy instead of build mandate. They want to reach for the stars, but they feel they need to (or even can) do it using existing technology.

Why are people so build averse?

One thing that I have noticed is that even when you are in a ‘buy’ environment you end up building, the building is simply different. Instead of building UI, databases or business rules you end up building glue. Glue code that connects disparate systems. Glue code that moves data between stores. Glue code that provides services to secondary consumers. Glue code to allow enterprise level reporting where reporting was not available in the purchased system.

So explain to me again why people are so build averse?

Innovation starts with the ability to take a risk and move in a different direction.  It is difficult to consider moving an industry in an entirely different direction when you are building on top of existing applications that fit into a different paradigm.  After all, are you not looking to do something different? Are you not looking to accomplish something that the industry is not yet fully ready for in order to get a jump on the competition?

If you answer to these questions is yes then how do you expect to be efficiently innovative using what already exists to move forward in a different direction?

I know that it is simpler to buy something off the shelf and place the responsibility to make it work on the shoulders of a vendor. I also know that it may seem to be cheaper to buy a bunch of cots products and spend time to data integrate them using tools like Informatica, and other data integration methodologies. But once you stray from being able to open a shrink wrapped box and being able to simply install and use you have strayed into a build situation, like it or not. It is similar to putting a ton of effort into deciding what car you want to buy then once you take ownership you drive it right over to the custom shop and have the engine replaced with one that has more power, the interior redone to what you really wanted, and the exterior modified. If the car you bought was under powered and the interior was not what you wanted and the exterior was also not to your liking then why did you buy it?

Consider also what gets induced when you spend your money to glue stuff together and the industry changes. It sounds like you are insulated in cases like this because you feel that the vendor is responsible for bringing the application you purchased into regulatory compliance, and they are, but what about all that glue that you built? The vendors responsibility ends at their borders and whatever you have done to augment your systems over the years is not their responsibility. When push comes to shove they are not responsible for how you use the system and are only bound to deliver to you a system that fulfils the legal and regulatory requirements of the line of business as well as the stated requirements and features of what you purchased. They can’t be held responsible for what you glued onto their product, and nor should they be.

Additionally you cannot predict how they are going to make changes as time progresses so you are stuck working your changes to their time-lines and schedules. You will find yourself having to wait for their release cycles and then your install, evaluate and test cycles to complete before you can even start any decent planning to make changes to your internal systems of glue code before you move a new version into production. If your processes are not fast enough, or your vendors release schedule very aggressive, you can find yourself stuck in an endless cycle of install, test, modify, and move to production, a process that can place some very high stress on both people resources as well as hardware and software costs, not to mention the potential for harm to your business if things do not go right.

I am not saying that it always makes sense to build. No one can say that. Buy Microsoft Office and be happy that you did. Buy an accounting package and be happy that you did. But if your business is unique, or you need to make it unique as a differentiator, then consider the build task, even if you need to live with a coddled together bought system in parallel as you do it.

 

Saturday, 20 June 2009 23:31:35 (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Design | Requirements  | 
Comments are closed.
Copyright © 2019 Raymond Cassick. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: