To buy or to build?
Should we buy the IT system from a vendor, or should we build it in-house? For some folks out there, myself included, this is a crossroad clouded with uncertainty. To scatter the clouds and shed light into the paths ahead, let's hear what the elderlies of software engineering craftsmanship say:
If it’s a core business function — do it yourself, no matter what.
Pick your core business competencies and goals, and do those in house. If you’re a software company, writing excellent code is how you’re going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you’re a pharmaceutical company, write software for drug research, but don’t write your own accounting package. If you’re a web accounting service, write your own accounting package, but don’t try to create your own magazine ads. If you have customers, never outsource customer service.
— Joel Spolsky, from In Defense of Not-Invented-Here Syndrome
Cores are the central competencies of the organization. These are things that customers are willing to pay for and what investors reward. Context is everything else. [...] As we fund core features and applications, we need to make sure that context doesn’t kill core.
Of the applications and services that you manage, which of them are customers willing to pay you for? Which ones truly enhance competitive advantage? And which can you rely on vendors for?
— Kim Gene, from The Unicorn Project, chapter 17
When it comes to build versus buy, the frequently repeated but rarely followed wisdom is good advice: if you're a technology company, vendors usually generate significant value if they're outside your company's core competency; within your core competency, they generally slow you down.
— Will Larson, from Build vs Buy
So according to the advice, the crossroad sign can read: