Enterprise Software: Build or Buy?

So is there a need to custom-build software? One can understand that thirty or forty years ago such packages did not exist, and even if they did, they definitely not with such extensive business coverage. For that reason all enterprise business function support software had to be built from scratch. Over time, packaged products began to emerge, starting with software for accounting and finance, then purchasing and sales, and slowly to core business functions, especially those in manufacturing. The concept of Manufacturing Resources Planning (or MRP) arose, and that evolved further into MRP-II and finally into ERP, or Enterprise Resource Planning. As market acceptance grew, the product companies addressed several other industry sectors as well. The next frontier was to address the SME/SMB (or small business) segment which had for a long time been left out of the benefits of enterprise planning and support software. With such extensive coverage of all kinds of business processes, does building new software make any sense at all?

As with most things in IT, the answer is still it depends. Yes, there are very good packaged offerings available today for an assortment of core business processes, but the fact is that the market for custom-built enterprise software is still strong as well. There are many factors to consider in the build vs make decision, and what seems like the right thing to do for one business may not make as much sense for another. Some of the considerations are as follows.

Time to implement

A quick consideration of what it takes to develop a piece of software that supports complex business use cases may lead one to conclude that it would take far more time to develop a customised software solution from scratch when there might be one that’s ready for use straight out of the box. But that’s not necessarily true.

It’s true that the actual development time in a custom-built software would be high, but in the case of a product, that might be offset by the time required to analyse and develop solutions for gaps between the package functionality and actual business requirements, and the amount of time to do testing. Users (who may not have been involved in the functional solution definition) have to spend time understanding the software, and figuring out which features they need, which they don’t and how the software works. In addition, there is usually a lot of time to be spent on integrating the package into the existing IT environment. Later one as well, changes may be quite difficult to implement within the well-defined, but possibly rigid design of a package.

Fitness for need and purpose

When software is custom built it is designed in response to very specific business needs and realities. When the job is well done there could be no match for a solution that provides a perfect solution not only to processing needs, but also in the way it integrates into the enterprise IT landscape. With a package, there may or may not be a good fit right out of the box. When use cases are simple and common within the industry, a package may provide a good fit, but it’s very likely that it comes with several additional unrequired features as well, along with constraints and bloatware to match. There may also be requirements that are not met and which call for package customization. The question to be asked here is Will the software fit in to the way the business works or will the business need to change the way it works in order to meet the design of the software?

Costs and Risks

Developing custom software in-house is practical when there is an IT budget to cover the costs of staffing and infrastructure as well as adequate management support for the process of building good software. There are risks associated with it, of course. It takes organizational as well as IT departmental confidence to build enterprise grade software, and to be confident that it will be done right. Large projects often overrun cost and time budgets, and this naturally presents a risk. An additional risk is that during the project lifecycle business requirements change due to external environment changes or corporate action. In such cases packaged products may actually already have solutions prebuilt because they are meant to meet the common functional requirements across a range of clients within a particular industry. The experience of implementing the package at a number of client sites also gives its developers exposure to a broader range of variations in not only use cases but also innovative solutions for different situations.

Over time, of course, all software has to be maintained. Packaged software maintenance can be expensive due to recurring license fees. What needs to be seen is whether this is still preferable to the cost of maintaining a team to maintain custom built software and having to ramp it up or down according to changes in maintenance demand. Packaged software is also usually technologically upgraded by its developers from time to time. While small patches may be offered at no cost, largescale changes in versions are usually available only at additional charge. Even so, their availability is an advantage.

Availability of expertise

Building custom software, especially in-house, requires the availability of a minimum amount of expertise, not only in technology, but also in the entire gamut of software lifecycle tasks, and in conceptualising and designing the most appropriate solutions. When working with a package vendor, however, the requirement for such expertise in-house is potentially much less, not only for the immediate or foreseen requirements, but for the unknown future as well. Deep functional expertise is best maintained within the business, however this can be constrained by not having as much exposure to a range of business environments as a package vendor might have.

Control

Once a company invests in developing its own software it has complete control over every aspect of it, such as how it is designed, what technologies it is based on, what scope of functionality it supports, how many instances can be rolled out, how and when to change it, and when to re-engineer it. They can also choose whether to continue to develop it in-house or ask a vendor to take over maintaining it. And, of course, they completely own the intellectual property rights to the software and its internals. With a package, however, some of these freedoms are constrained. The vendor owns the product IPR, and decides the future course of the product features and technology roadmap, its licensing policies, and for how long the product will be supported. To that extent, the customer does get locked in with the vendor. It’s for each buyer enterprise to consider this aspect and decide whether the constraints are acceptable when weighed against the option of developing the software themselves.

For all these reasons the decision to go with an available package is not necessarily an open and shut case, not even nearly. It all depends.