Software Package versus Specific Development

A company requires many IT systems to run its business, and typically spends a few percent of its revenue on building and operating those IT systems. A typical IT system will live for a decade and sometimes much more before being replaced. There are two strategies to deploy an IT system: software package or specific development. The choice will deeply shape the company for the life time of the system.

Software Package

Software package provides directly a solution for a business process. For instance , an accounting software will provide you directly a solution to register your transactions, create invoices and file tax return. Additionally, software packages allow you, to some extent, to adapt them to your needs, but there is always going to be a limit. Very few packaged software vendors have developed quality plug-in frameworks to allow for extension, something other industries do better: wordpress or many video-games come to mind here.

Specific Development

On the other hand, in a specific development, you develop yourself the requested business logic. This is done on top of a generic IT infrastructure that does not know anything about your business process. One such infrastructure is a database that stored safely your data. Fortunately, there are great, stable, and open-source infrastructures for most of the basic technologies you need. In specific development, you implement directly, according to your own rules, the business logic, which is great if you have special needs or constraints.

However, you also have to implement some infrastructure common to all business systems, such as security and access control, workflows, and application page layout. And this is where low-code platforms, such as Open Lowcode can help here, by providing those common bricks ready to assemble, and all flexibility to develop what you need on top (the mortar).

So, you have to create a new business system, or replace an old one, and you should choose which way to go, packaged software or specific. This post suggests a method to get to a decision.

Size and cost of the topic

The first criteria to look at is the cost of developing the system. This should be seen in the context of your company IT budget, a typical few percents of your company revenue (for example, it may be 100M€ for a company with several B€ of revenue), and generally a standard ratio per industry. Systems are:

• Huge if they represent several years of IT budget.
• Big if their development and deployment cost represent around 1 year of IT budget
• Small if their development and deployment cost represent far less that1 year of IT budget

There is a natural limit to how much you can invest in new systems. You will typically be able to undertake one big project every 3 to 5 years, and several small ones per year.

Business Impact

IT systems fall in several categories depending on their business impact, and how standard the requirements are:

• A strategic system is crucial to the competitive position of your company, and this is an area where you expect to be able to innovate. If your company focus is logistics, and you pretend to be the best in the world, you probably want to have your own supply chain software with all your proprietary innovations implemented quickly.
• A normalized system is implementing an enforced standard process. The quintessential standard process is accounting, where there are laws and norms the company absolutely has to follow. Legal standards are not the only one, and there are also industry or scientific standards that are really applied: steel alloys are really standardized across the industry, and their mechanical properties also are. Here, caution should be applied that there are some ISO norms that are more a marketing trick or a hobby than a really applied industry standard, it is always better to ask a few disconnected experts before making a judgment call.
• Many systems do not fall into this category, and are neither strategic nor normalized. However, having good systems can be critical for the productivity of the company. Such systems include word processors and office suite, many industrial systems, HR systems...

Insights

So, based on those two criteria, it is possible to propose a strategy, considering the following facts:

• Some commercial software is very expensive while providing little value. While, in a perfect market, you would expect relatively simple software price to decrease, and also old technology to commoditize, enterprise software vendors are making a great effort at keeping price high in a market that includes mostly ad-hoc private transactions. So you should systematically challenge or reflect on the value a solution will provide and its cost. Just having the good title is not enough.
• Using commercial software, you are at the mercy of the editor roadmap, and this includes, every few years, having to perform a potentially painful and costly upgrade. Specific software also suffers from obsolescence of the basic technologies used, but this is typically a fraction of the cost of an upgrade of packaged commercial software. To quote one, changing database version is no big deal.
• Extending commercial software to fit to your requirements is almost always going to be extremely painful, as most commercial software does not have stable, powerful and properly documented APIs and customization points. First development is painful, but typically, the pain is felt mostly during an upgrade. Specific development of the same features is relatively easier.
• You are likely under-estimating the cost of developing new software, or adapting existing software. Especially, there is a lot of work to stabilize a piece of software once it has been written, often an extra 30 to 100% of the original estimates. So keeping a working system, or using a widely spread packaged software as it is intended to be used, the stabilization work is already done
• There are some topics that are just too big for your company to do on its own, and the smaller the company, the more there are such topics. This means that, in that case, you just have to make a smart purchasing decision, and go with whatever software exists. This may shape the strategy of your company, and prevent you from innovating in some areas. It is very important, and very rare, that all stakeholders recognize this, and adapt their strategy.

Finally, the decision matrix

So taking all this into account, decisions become quite obvious.

• You should clearly buy software packages for any big or huge normalized topics. Examples of huge topics include a full accounting and tax suite, probably including payroll.
• You should also procure software packages for any huge topic that is neither strategic nor normalized, as you cannot afford to build your own. One example is a word processor or spreadsheet. As those are huge investments you cannot afford, you should just use an existing product and live with its limitations.
• If you have a need for a huge topic that is also really strategic, you have a problem. Your company considers it worth having a huge investment on this precise topic well beyond the normal IT budget. As an alternative, you create a real partnership with a software vendor to incorporate your requirements. As you will become highly dependent from the supplier, you probably want to limit the partnership to the minimum scope required
• If you have a need for a big or small strategic topic, then, you should definitely go the specific way. This will give you exactly what you want, and you will get more flexibility. Open Lowcode is a very efficient way to do that
• For simple normalized topics, and other topics simple or big, both packaged strategies or specific development may make sense. This includes a big part of the famous ERP system. Companies typically customize their ERP to take into account their specifics. However, many companies do not consider supply chain as a differenciating factor, just something not to fail at. One approach I could advocate is to get your local development team build a specific prototype. You could invest 10% of the original development budget and see how far they go. Thus, you will get a good understanding of the complexity of the problem, and how skilled your local team is, a big factor in deciding if going the specific direction is a good decision. With Open Lowcode, you need less technical skills as the framework already provides a very good base, and will guide your developers.

This is not exactly a fair game

While your team develops specific solutions, external vendors sell software package. You will not compare the two approaches in fair conditions. Especially, the specific development solution will lack the powerful, professional, and self-interested advocates from the vendor companies. Whatever happens, they will be happy to get your money. And nobody may ever know that is would have been 3 times cheaper to go to another route. This is even before mentionning the famous "Nobody has ever been fired to choose a big famous vendor" that will be common in your teams. So, to compensate this bias, you probably want to nudge slightly the decision into the specific development direction, and be the devil’s advocate when the packaged software case will be made. At least, you should run a few hackathons and see what comes out of it.