Buy or Build?

June 2018

CTO: Should we buy or build a Content Management System?
ME: Yes!

What is the question?

Although often presented as a choice, buy vs. build is a false dichotomy.

Most modern software development blends SaaS, vendor components, APIs and a mix of bespoke code and configuration. It relies on integrations with the rest of the organisations software systems whether you are building entire platforms or individual features.

Aside from commodity stuff, there's typically nothing on the market that, out-of-the-box, integrates with your ecosystem and can keep up with all your commercial, technology, product aspirations. So you need to build something.

But boutique requirements are easy to come by and also an enemy - we can't afford to invest energy in every single area we want to. So you need to buy something.

It is of course possible to limit our aspirations to whatever we can find on the market - we often do this. A system that does 80% of what we need. But often this isn’t good enough, a tech-reliant business built on commodity parts is one that lacks distinction & competitiveness.

Orchestration

One way in which in-house technology successfully positions itself where buy and build is the expectation is an orchestration layer - glue to a suite of different tools.

Consider a recent video management system we built, it integrates many different systems, focusing on the user experience and flow/collaboration of people using these different tools to do their jobs.

To illustrate, it's a system that blends transcoding (zencoder), transcription (3playmedia), hosting (amazon s3, fastly), tagging & metadata (internal system), a searchable video archive (mongohq), planning & comm’s (asana, slack), authorisation (google), analytics (amazon redshift, keen.io), syndication (youtube), and publishing (eidos) to ft.com, as well as integration with our upstream video studio, editing & archive systems.

The user journey is quite transparent across all these subsystems, we can swap them in/out (for cost, for functionality reasons etc.) and introduce new ideas in to the tool and take them away with relative ease. We can elect to build the parts that don't exist or are unique to us. The system itself is quite simple & malleable - sticking disparate specialist and commodity tools together.

Each third-party system here represents years of engineering effort. We have no business or advantage replicating these things, but each of these things can not talk to the other in the way the we imagine we need to create value (productivity, commercial, quality ...) for the company.

The advantage here is that we've given people a tool made of other tools, added the IP that we wanted by combining and filling the gaps, making the dozen or so specialist systems feel like one.

The competitive advantage is in the UX, the orchestration, flexibility, and the agility such an architecture yields. The antithesis of enterprise vertical integration.

|++

So the question is not, "which system shall we buy?" or "shall we build this?", it's "what is the right blend of buy vs. build?", not either/or - it's a scale, software development as a recipe with many ingredients, your answer will change over time.