Software Build v Buy

build-vs-buy-colocation-data-centersDuring a recent discussion I was asked if I was a supporter of “buy” or “build” philosophy for software solutions. Whilst I think this is an unusual question as I feel you should evaluate each software component on its merits, it is still a valid question and  is getting more relevant as technology progresses. I actually think there are at four main options with nuances of within the “buy” option that need to be considered.

These are;

  • Re-use / Refactor existing solutions
  • Rent (SaaS)
  • Buy
  • Build

Every organisation should have a set of “Architecture Principles/Guidelines” that describe both the landscape into which the solution components must fit and  the decision making process behind what to consider when replacing (or adding) software components..

It is also important to note that the buy option can have three distinct flavours;

  1. Configuration only (no code changes allowed, pretty much the same as rent)
  2. Minimal Code changes allowed, Generally less than 20% of code base and mostly additions rather than modifications
  3. Product is a base that you will heavily modify to be your own after purchase

Note – Option 3 actually fits more into the Build category as you will be going your own route and not taking any upgrades from the vendor as your version will be significantly different within a short timeframe.

Option 2 is interesting in that unless you work with the vendor to make your enhancements in a controlled and valid manner you can also make upgradability very difficult and expensive.

So when should you build?  There are many reasons put forward for building your own software but in reality only one should be used as the catalyst for embarking on this route.

If the software component is a Business Differentiator then a Build approach MAY be a valid option.  A “business differentiator” means that the software solution(s) gives you a competitive edge in you marketplace, in essence the solution is you IP and an accountable asset to the organisation.

If you decide to “build” then you should treat the software component as a real software “product” and make sure there is a PLM (product lifecycle management) process in place for it. Owning a piece of software that is critical to your business can turn out to be very costly if not approached in the right manner. It needs to have a multi-year budget, roadmap, comprehensive support & management program and most of all a “product owner” whose responsibility is to make sure it is not “over engineered” and does not become a black box or bottleneck that people are afraid to touch.  Also be pragmatic and initiate regular reviews of the product’s technologies and viable commercial alternatives that may come to market.

If you do decide to build then the technology choice is key to ensuring your Internal Product is built in a manner that best meets your organisations needs.  Do not immediately decide to build on a particular technology base just because you have the skills currently in-house.  Conversely do not build on the latest and greatest new fad because your techies want to try something new.  Build on a technology base that makes architectural sense to the needs of the organisation, future growth / expansion / usage & models.  By all means be cutting edge if necessary, but beware of being “bleeding edge”.

It is also a good exercise to sit down and review your organisations software applications/components on a regular basis and look at the lifecycle management of each piece.  As part of this process you should also engage in a theoretical exercise  how would you would run the business just using the “rent” option, i.e. “cloud”.  As you discount cloud options for components, work back through the buy, re-use and build options until you get to a sensible architecture that meets the needs of the business and justifies the costs/benefits from all perspectives.  This will give you a realistic roadmap for a pragmatic approach as to what parts of your architecture landscape fit into which category for software ownership.

About Brian Maguire

Working in IT for 30+ years. Recent position was Global Enterprise Architect for Las Vegas Sands Corporation. Currently immersed in the startup scene in Budapest.
This entry was posted in Architecture, IT Strategy, Software, Software Development. Bookmark the permalink.

2 Responses to Software Build v Buy

  1. Michael says:

    Good points here, Brian. I’ve got a question pertaining to your point on the internal “product”. This morning at a seminar, someone raised the concern of vendor lock-in when it comes to cloud solutions. The speaker said, “I want to know how I’d get my data out before putting it in.” But I’m not sure how different that is from locking your data inside some crusty internal system laden with technical debt. Have you ever seen anyone actually plan for the obsolescence of a system as far back as when it’s being planned?

    • Have to say no, it has never been something that people think about prior to building or purchasing a solution where they are in control of the database.

      However as we move more into the cloud based apps (SaaS) it is a critical question that needs to be asked when deciding on a vendor. Quite a few SaaS companies make it easy to load your data into their systems but have not put quite so much thought on you leaving them for a rival.

      The main “data move” related questions I would advise people to ask prior to any cloud decision would be;
      1. Can I get my data out quickly and at a point in time of my choosing for referential integrity constraints to be in force
      2. How will the data be provided, getting file schemas means you need to understand what might be a complex data model with all its associated coded standards and potential consultancy costs for vendor proprietary knowledge. It is more preferable to get data represented as model/object/entity in xml/json notation.
      3. How much will the data-retrieval cost me.
      4. How sure am I that my data is both delivered to me AND removed from the vendors database (auditability of the removal is critical).
      5. How is the data delivered to me.
      6. How is PCI, PII, and other encrypted data managed in the data retrieval

      If you do go to a cloud provider, it is also critical that you test the data retrieval process as part of your risk management exercise on a regular basis

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s