Should you build (software)... or should you buy?

Senior director of platform strategy at ‘mass customisation’ specialist company Cimpress is Eugene Hsu.

Hsu argues the point that modern software architectures have changed the nature of the build vs. buy question — he says that the build vs. buy tradeoff used to be more of an either/or proposition.

That is to say, firms could option to either build custom software, or buy a complete solution that addressed all of current needs — and there wasn’t much of a middle ground.

But, says Hsu, The iterative and modular nature of modern software development is changing that previous balance.

He contends that many companies now offer fine-grained services [and microservices… and Application Programming Interfaces (APIs) that connect smaller component pieces of functionality] that address a variety of areas: computation, storage, e-commerce, security, machine learning, payments and more.

These services can be easily integrated with existing software components to help you accomplish your business objectives more efficiently.

“I’ve found that the most effective approach is to bias [your software purchasing] towards third-party components and only build the components that provide your business with a significant competitive advantage. This helps your current engineers focus on what’s most important. Additionally, it makes it much easier to onboard new engineers — instead of teaching them the intricacies of your proprietary code, they can benefit from the documentation and training materials that third-party service providers typically offer,” said Cimpress’ Hsu.

Hsu’s 3-laws of build vs. buy

  • Doing this [above approach] requires your own software architecture to be modular. It’s much harder to plug third-party services into monolithic architectures. If your company still hasn’t made this transition, it’s highly advisable that you make it so. Modular architectures enable your business to be more agile.
  • It’s often tempting to build your own service if the third-party service doesn’t do exactly what you need. Let’s say that it accomplishes 90% – but ask yourself if the missing 10% is worth taking your engineers away from delivering unique value to your customers.
  • Even if you decide that building your own service is the right thing to do, it can be useful to build prototypes using third-party services. It gets your innovations to market faster and helps you learn.

    Cimpress’ Eugene Hsu: a mantra for modularity matters, man.

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

Did you compare performance to Oracle NOSQL (built on Berkeley DB) ?
Cancel

With as big and complex a system as you describe, how do your customers figure out what is and isn't working?  How do they dig into the data and how to they gain insights about their advertisements?

When did you use SQL and why?  What contexts have you found make sense for SQL and have you ever chosen the wrong type of data store?

Thank you for sharing this rather informative article, as I had not considered how big a data set advertising creates.

Cancel

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close