« Latency Exists, Cope! | Main | Chaotic Perspectives »

Tuesday, February 27, 2007

Comments

wpbarr

The decision isn't build vs. buy, it's overcoming the institutional inertia of not invented here. :)

Arun Jacob

I maintain a blog with a similar "simplicity" theme among other things. Got pointed to this blog by a colleague who reads both :-)

Great blog. I am hooked.

https://simplicity-works-everytime.blogspot.com/2007/03/simplicity-serendipity.html

Gunnar

To add another rail to this discussion, buy and build are not mutually exclusive. Pat Christiansen and I wrote an essay on this callled the Buy/Build Balance

https://arctecgroup.net/040304.htm

If you buy SAP you ae likely to still write tons and tons of code. Was that a buy or a build?

If you build your own J2EE stuff you are still constrained and pushed in certain directions by BEA or JBoss. Was that a build or a buy?

I like to use Clayton Christensen's work to get at the issues you describe as Business Impact, Incremental Benefits, and Holistic Costs. Specifically the law of conservation of modularity is at the heart of this

(summarized by Phil Windley)
https://www.windley.com/archives/2004/03/osbc2004_clayto.shtml

"Clayton introduces the “law of conservation of modularity.” The idea is that either the integrated system or the subsystems need to be modular and comfortable in order to optimize performance for the other. He uses Microsoft OS and Linux as examples. Applications in Microsoft are suboptimized in order for the OS to be optimized (this is a result of closed source) whereas in Linux, the OS is suboptimized via an open and modular architecture in order to optimize the application (i.e. being able to change code in the OS to optimize application performance).
In Clayton’s world, “modular” implies “suboptimal” or “inefficient.” You can’t make money on the modular layers in the value-added chain (they’re the integators). You make money at the borders to the modular layers. Another way of looking at this is that no one is going to make money on SOAP, you’re going to make money on the parts that talk SOAP, the services."

I think this is also at the center of a lot of the Rest/WS-* debates. It is interesting that Redmond invests heavily in opening up while Google shuts down its SOAP pipe...

I don't think there is a one size fits all. So may be you buy more where you need modularity (so you get economies of scale) and build more where you have your secret sauce.

If you look at Ping Identity, they wrap JBoss and you deploy a Ping binary that gives you federation. They have relatively simple needs from a JBoss standpoint, HTTP i/o.

Then you have Cape Clear which deploys inside a JBoss container, you deploy the JBos bits and then load Cape Clear. Cape Clear uses many, many JBoss services - HTTP, messaging, on and on.

Stan

"A build vs buy decision is primarily about determining if a vendor product can be sufficiently customized to solve the problem that your organization faces." But don't forget to factor in whether your users can be sufficiently customized to use the product. The more flexible they are, the less work you have to do. My sad experience has been that the customers want what they want, and we spend so much to customize the product into what they had in mind all along that the economics of buy vs build go all wrong.

Or maybe I just really enjoy building. :)

Rajgo

Hi Dan,

You have stated some of the important points that must be kept in mind for a build vs buy. However,I think you have missed one important point. The build vs buy decision is also hugely determined by the current execution capability of the team to deliver.

Also, the build or buy decisions are different for Software Product Companies, and for in house IT departments

Large companies probably have more resources and this point might or might not come up depending on the team. But in a small team like the one that I run, this is a major factor for me.

I too am tempted always to go and write some capability that I think I need, but sometimes it is not just worth it.

Here are some horror stories from Hyderbad about some over enthusiastic Developers

One company in Hyderabad chose to build their own bug tracking system, instead of using a third party tool (free or commercial). What a waste of people's time and company money.

In another company, a developer who was a purist OO Guy, wrote an XMI to C# code generator and spent 8 months in generating an object model that should have been built in a month.


The moral of these stories is that the build or buy decision must be taken by mature brains and must not be given just to hardcore developers who have no other point of view.

Andres

Alas, would the build vs. buy decision be a rational one! More often than not, however, we encounter emotional resistance. Microsoft (and Oracle and so forth) is a swearword for a large number of people and getting their stuff into the system even if it would make perfect sense is often fought with vengeance. And there's the problem for decision-makers who inevitably can not be familiar with all the technical details of a huge million-dollar system: how to distinguish between real and subjective arguments? Even more: if there is considerable resistance to the system among the engineers for whatever reason, can the system still be bought and implemented successfully?

Good example of this is MS Exchange that I have seen working perfectly fine and fitting nicely in in a reasonably big organization. In another organization of approximately the same size, however, the thing never seems to work properly. It can't be for the skill of people and the environment is fairly similar too. So I think it all comes down to whether you can look at a bought system neutrally without any prejudice.

Ben Kruger

Time to market (TTM) and resources should also be major contributing factors. Additionally in smaller or medium sized companies, often times uninformed people are making decisions to buy rather than to build. What compounds these decisions is the product chosen to buy rather than build is not the right fit or necessarily the best product out there. I have been bitten in the ass time and time again with bought solutions that were then replaced by built solutions. However those bought solutions did enable TTM to happen in a quick manner.

Geva Perry

Dan - from a different perspective (one that may not interest you as much), I wrote about the Build Vs. Buy issue and why it makes it so hard to market software platforms to software developers.

See here: https://gevaperry.typepad.com/main/2007/02/marketing_to_de.html

Ian Rae

Build/Buy decisions are interesting in terms of adding simplicity. Using 3rd-party stuff generally involves getting lots of 'features' you don't need in order to get a few things you do.

I like the adding simplicity idea. My blog talks about an Ira Glass video on simplicity in storytelling.

Paul Anderson

Another major consideration with "buy" is that you seldom are buying just that product/API - you are usually buying hidden or opportunistic thin-end-of-wedge vendor lock-in potential.

danial

good blog

Account Deleted

Excellent blog

Account Deleted

nice one

The comments to this entry are closed.