Build Vs Buy: The ongoing enterprise software dilemma

Build Vs Buy: The ongoing enterprise software dilemma

Build vs Buy – For many companies the complexity associated with enterprise class solutions can be frustrating, often leading to the question “would we be better off building our own, rather than trying to use solutions designed to meet needs that go far beyond those we have today?”

Building software is generally a lot more involved and complex than companies believe, and the hidden costs, risks and complexities only often show themselves once a path is committed to, and then this can then be too late to allow for change. Even the simplest management tool, which may start off as a script written in-house can lead to unseen consequences in the areas of risk, compliance, security, support and regression testing.

These risks can be summarized as follows:

Staff

The talented, passionate prodigy that builds you a whizzy solution in-house, is going to get a better job at some point, she’ll get a promotion or leave for more money, and it’s then that you will find that the code they built for you wasn’t as well documented as your new team needs.

Build Vs Buy: The ongoing enterprise software dilemma
Build Vs Buy: The ongoing enterprise software dilemma

Companies must invest their limited resources in ways that maximize their ability to produce and distribute their products profitably. When you develop a product, you want to be able to capitalize on that investment by selling it to as many customers as possible. Sometimes your staff will discover that available solutions in the market that they wish to consume are not 100% in line with your requirements, and your teams may want to solve this problem themselves.

You must maintain a very strict understanding of what is a cost and what is a profit center. When you invest in a cost center, you cannot scale this investment in ways that maximize the value to your company. While your staff may see the possibility of building a better widget, their passion will not allow you to grow this investment in ways that materially help the company.

In the short term building your own answer in a problem can save you operational and capital expense, but very quickly this investment will turn negative, as you have to maintain currency with all the changes going on in the business.

In fact, staff that build their own technology internally in cost centers are more likely to take those skills to other companies as they will quickly find that the passion, they felt for initiating a project is not maintained at the project reaches maturity. Great leaders know this issue and channel their talented staff to partner with vendors in exchange for glory and discounts, as this maintains success and maximizes retention.

Scale

As a business grows and changes, custom code designed for one purpose can become difficult to fit into the new environment. Many fantastic COBOL applications are still in use today with their green-screen level function key and tab driven interfaces because they cannot be easily updated.

When a vendor invests in delivering a solution to a specific business problem, the process starts with an analysis of the problem being considered and the people who specifically have this problem. This provides an understanding of the value of solving this problem to the market as a whole and allows the vendor in decide how much to invest in solving this problem considering how much the market as a whole would be willing to pay to have this problem solved.

This allows the cost of the research and development to be spread across the market. Without this consideration of scale, a consuming company would have to make this entire investment themselves, and this would generally not be economically viable.

Competitive Edge

Applications and tools must be portable to allow your business to evolve to use blockchain, clouds, 5G, the edge and much more. When you build your own code, you don’t get to consider all these choices and still do it on a budget and quickly.

One of the biggest challenges companies face when they engage a build strategy for software is simply the moving target nature of technology. There is a continual evolution of technology as new devices, versions, applications and more are added to the ecosystem. Everything from changes to operating systems and new thinking around security and machine learning mean than every single part of the environment must be continually maintained to ensure currency with every other component. Vendors generally charge a maintenance fee to fund this continual research, development and support need.

Many vendors find this cost to be much higher than expected, but it is a basic cost of doing business. For a customer who develops their own software they will find it even harder to justify these costs, as without the volume effect of selling the same solution to many customers, having people research the effect of any change on a specific feature or function can be cost prohibitive.

Risk

When you build your own management applications, you take on the requirement to make sure they are secure, requiring penetration testing, validation of all the code bases you are using, architecting for automated testing and much more. Many companies of all sizes have invested many billions in failed internal projects that have brought down their credibility, flexibility and revenue, the risks to reputation and the fundamentals of the business outweigh any advantage.

Build Vs Buy: The ongoing enterprise software dilemma
Build Vs Buy: The ongoing enterprise software dilemma

Cost

When you develop your own software, you also have to develop your own documentation and training, and be ready to support new versions of everything that will come down the Pyke in any combination that will be needed (regression testing)

Best Practices

While software vendors are continually aware of how every customer is using their product and are motivated to maintain currency with best practices to maximize retention. When you build your own software, you take on this burden, without the crowd sourced feedback of a cohort of users.

Summary

When To BuildWhen To Buy
For ad-hoc applications specific to a
single business process.
When use of the s/w is critical to your
business operation.
You have a problem which
is unique to your business and no
available s/w adequately addresses it.
you have a common problem that available s/w is adequately developed and
customizable to address.
To solve a problem that doesn’t effect other areas of your business.The s/w will be used throughout your organization and will interact with other applications.
If you have a strong IT dept that will remain with your company for a very
long time with the resources to build,
maintain, and support the application
forever.
Your IT dep it not equipped to build the
application or maintain and support it
long-term.

There are times when you may want to build your own software, but there is only one reason to do it: Only build your own software if doing so will provide you with a competitive advantage that you can turn into revenue.

If it’s ego then don’t built it, buy it!

Many IT teams have been caught in a never-ending loop of Id, ego and super-ego caused by the desire to do it themselves and hitting the tsunami of project management realities. When you develop your own software, you consider three key areas:

  • What do you want to achieve?
  • How much do you want to spend to achieve it?
  • How quickly do you want it delivered?

But you can only pick 2 of the 3, the other will always be out of your control. That is the reality of software development project management and is the key reason you buy vs build everything you can.

For more information please view the webinar on the topic of build vs buy, as this link