Subscribe
About

Build or buy?

There are a number of factors to consider when debating the pros and cons of building or buying software.

Len Weincier
By Len Weincier, Owner and director, GuruHut.
Johannesburg, 17 Jun 2010

To build or to buy? That is the question. It's the oldest question in the software development book. And although there is no simple answer, as each instance of software development is as different as a snowflake, this in itself is a very good reason for a similarly unique software solution to be developed for each implementation.

When a company is considering a new software implementation, it should take into account a variety of factors, including budget, timeframe, needs to be met, processes to be automated, strategy to be supported, and cultural requirements of the organisation.

Even when the evidence revealed by all these factors is weighed up, decision-makers still have to be cognisant of the fact that the hidden costs and unexpected complications can reveal themselves in bought software solutions.

Hidden costs

For one thing, a piece of bought software generally only answers to around 60% of a company's needs at best. This leaves the customer with many aspects of the business unautomated, waiting for some future point at which a product upgrade might allow for them to be incorporated into the solution, or requiring the additional services of a software developer later in the game.

The cost and time savings that are lauded as a benefit of already-built software solutions are often eaten up in customisation time and fees. Accredited, specialised vendor consultants don't come cheap, as they have invested a lot in their training, and their fees are often dictated by the international company that owns the software.

In fact, bringing in a team of specialised consultants who make a company's business processes fit their software solution, rather than the other way around, can end up getting expensive very quickly - and everyone knows it's tough to get rid of consultants once they have a foot in the door. Companies end up investing a lot of money in doing business the way that expensive consultants want them to do business, rather than having their own, existing processes automated.

Retaining IP

Companies that build software have the advantage of retaining their own intellectual property. The software implementation can be mapped to the company's specific needs and requirements, and the software architect can mirror the company's business processes in automation.

Companies that build software have the advantage of retaining their own intellectual property.

Len Weincier is owner and director of GuruHut.

This has the added benefit of making it easier and simpler for staff to learn to use the new system. Of course, some level of training will be required, but since the implementation will generally reflect processes with which they are already familiar, the time - and again, costs - spent on training won't be significant. Software development and process automation shouldn't have to mean a cultural change for the entire organisation.

Good software developers will also ask their customers the right questions. In many cases, the desire to automate isn't just about business processes, it's about some final requirement that needs to be unpacked and assessed for satisfactory delivery to take place.

Experienced software developers will also be able to take into account the development lifespan, make anticipate changes in technology, regulatory environments or business needs, and be agile enough to allow for these or to respond to them as they occur. This level of flexibility means that on delivery, the customer will have an up-to-date solution, without having incurred too many costs for changes to the initial brief.

Keeping the faith

Companies understandably have faith in industry leaders and brand names in software development. They have the weight of success and experience behind them.

But just because they are very good at their own business, it doesn't mean their solution is the right fit for someone else's.

In fact, an agile software developer who is used to finding flexible solutions to any implementation requirement is likely to add far more value to the automation process. Of course, the key lies in identifying the right software development team for the job.

Share