Grid Computing: Roll Your Own or Buy
A common question in the software development process is: “What should I build vs. what I should buy?” You’ll often hear engineers shoot down a buy decision because they “can build it themselves.” No doubt they can. If they couldn’t they wouldn’t be software engineers. But you really don’t want your teams building everything in-house. It’s expensive and unless it increases your company’s competitive advantage the expense is not worth the gain. Here are some common build it in-house problems:
- The team lacks experience in the technology area so they:
a. underestimate the time and complexity of the solution
b. poorly architect the solution
c. can’t provide on going support and/or maintenance for the solution
d. add more talent to help - The in-house solutions distracts from core competency, consequently putting key technology solutions behind schedule. This directly affects the bottom line on a continual long-term basis. If you think that you’re going to write something and never touch it again...well that’s not going to happen. So don’t kid yourself.
So why am I telling you this? Because many companies are building their own in-house grid solutions. Unless you plan on being a grid platform company...why are you building your own? Now, one good reason is there is no 3rd party solution available. When this happens creating your own will give your company a competitive advantage. This is a good reason to roll your own.
However, if a 3rd party company has a solution that provides what you need or they are willing to work with you. Buy. Technology is an enabler. It allows companies to provide higher quality customer service faster and to provide new and innovative products. If you allow your technology teams to become distracted by building systems that are money pits with no competitive advantage tied to them, then you are handicapping your company’s ability to respond to market shifts, customer needs, and new revenue opportunities.
Too much of that and you'll need to get your resume cleaned up.
Labels: Concurrency
1 Comments:
Excellent post! And I'll add one more pitfall: even if they end up with a working distributed solution, it will be a purpose-built tool. It won't be extensible, and it won't help them the next time they need to distribute an application. Sure, they'll have more experience writing it the second time around, but unless they're doing something identical to the first one, they'll end up discovering a whole new set of hurdles and difficulties.
Post a Comment
<< Home