Canned, Customized, or Custom: Which Software Choice is Right for You?

Businesses looking for specialized software naturally want to save money in their purchases.  Do you go for a “canned” system, or hire people to build something custom for you?  The answer is that it depends on the nature of what you are trying to accomplish, and what products and systems are available to meet your needs.

Note that we are talking here only about business-level software, software that is deployed over the entire business, or a section of the business – interconnecting workers, establishing collective information hubs, and automating workflows.  Such software is multiuser, and will typically provide different functionality and access levels to users depending on their positions and roles.  We are not talking about specialized workstation software or the usual office suites, browsers, and the like.  Those are by and large individual productivity tools, and the challenges we are discussing here generally do not apply to them.

“Canned” business-level software systems represent a wide variety of offerings and technologies, for example:

  • “Big ticket” or “monolithic” software packages designed for the enterprise that cover major, but fairly standard areas of business, like ERP, human resources systems, supply chain management, accounting, customer relationship management, and others.
  • More specialized big packages/products that are often targeted to specific industries, such as medical and pharmaceutical systems, tax systems for accountants, etc.  These are designed to automate major chunks of activity within those businesses.
  • Web-based template systems, such as content management and e-commerce systems, which allow users to build out their own sites with relative ease.
  • Software-as-a-service or cloud systems.  These systems in general promote flexibility through configuration – little or no software coding required.

What all these systems have in common is that they provide ways to design and deploy a business software system without having to write custom code.  Instead, once the products are installed (or the services subscribed), they are set up for a particular business by configuration: making selections from menus, entering information in fields, adding users, and so on.  The skills of a custom programmer are not required, and therefore they can be set up less expensively.  In many cases a reasonably technically savvy purchaser can do it him/herself.  Granted, in the big ticket systems, with deployments that affect hundreds or even thousands of workers, there is so much involved that an outside team is usually necessary, and often some custom coding will be required.  Nevertheless, there is still the understanding that the system already includes the major functional blocks, and that nothing needs to be built from scratch.

Our initial question can best be answered by asking another question:  Given what you want to do, both immediately and for some time into the future, will a package or product enable you to do it in a straightforward way?  We are not looking for 100%.  Often the old 80-20 or 90-10 rules will give us the right answer.  If it is going to cost way more to approach 100%, it may not be worth it, especially if the 80% or 90% will get you moving forward in a positive way.  You can make real money on the 80%, which could fund something more complex in the future.

There is a middle ground between a canned package and a completely custom solution, and that is customization.  Many packages provide some access points where software coders can come in and build capabilities that cannot be achieved by configuration alone.  Customization does require software development skills.  Among the systems and packages that offer optional customization, there is a very wide range in terms of how much it is possible to do, how easy it is to do, and so on.  You do not have carte blanche to make modifications, as the package or system itself is determining the major functionality.

The Middle Ground: Customization

Sometimes vendors want to have it both ways., a Software-as-a-Service set of offerings, has made it a central theme in their advertising that they have put an end to the need for software coding.  They have a logo showing the word “SOFTWARE” inside a red circle with a diagonal bar (like a no left turn sign).  In other words, when you license their products you can do everything you need by configuration alone.  Nevertheless, the company promotes its extensive toolset for software developers to customize its cloud offerings, including a comprehensive, object-oriented programming language.  I guess software isn’t completely obsolete after all!

The ability to customize a standard product may appear offer the best of all worlds: all the features and functionality of a comprehensive package coupled the ability to make it do whatever you want.  However, as we noted above, the ability to customize varies considerably.  You cannot assume that just because there is a developer’s toolkit or an API (application programming interface), you will be able to make the product do exactly what you want.  These are case-by-case choices:  What are you getting from the core product without customization?  What do you want to add or modify beyond its core capabilities?  What do the developer tools allow you to do?  How difficult will it be to accomplish what you want in that environment?

When you are planning for a system and have not yet decided on a product or package or a custom solution, it is important to consider carefully the complexity and uniqueness of the process you want to automate.  If your process is quite unique or specialized, or has many steps or “moving parts,” you may want to investigate a custom solution, rather than a product, package, or platform.

Here are some Considerations to keep in mind when you are choosing between customizable package or platform, and a custom-built system:

1.      Big Ticket = Industrial Strength.

The “big ticket” systems, like SAP, IMB Websphere, Peoplesoft, Oracle, and so on, are very complex and expensive, and an organization must make major commitments of time and resources to deploy them, as well as making major shifts in process.  However, they are attractive to large organizations because they are “industrial strength.”  This means several things.

  • They have an established track record of reliability.
  • Most have multiple modules covering various major business areas.  Over the years they have grown rich feature sets.  This offers a kind of one-stop shopping for major corporations.
  • They have large consulting and support organizations behind them, and there are multiple vendors and partners to choose from.
  • There is a strong level of confidence that the companies and products will be around for many years.
  • They typically run on a range of hardware and software operating systems, permitting an IT Department to stick with its preferred platforms.
  • Recently many of these products have added cloud versions, giving customers another option.
  • They scale up and out as needed.
  • They often include, or have available as options, software that connects with a number of other systems and databases.
  • They all provide relatively robust and rich APIs and customization tools.

Big ticket systems have earned a well-respected place in the software pantheon, and are often an excellent fit for large organizations.  They are the standard bearers for what we refer to as “enterprise software.”  Nevertheless, they don’t define the role model for business software.  There are several other important considerations, as we shall see…

2.      Is the value of the core technology overstated?

Salespeople will often recommend their products based on the importance of the core features and technology.  They may then point out that the additional features the customer wants can be added using customization tools.  They will sell “how much you get” in the core product, and minimize the degree of difficulty in adding the custom features.

This is in fact a rather common occurrence, and it can really skew the assessment of products.  About a year ago, we were acting as advisors for a company that wanted to make an arrangement with another company to license their technology.  The prospective buyer had been convinced that the technology in question would get them perhaps 80% of the way toward a specialized software technology they were developing.  We were very skeptical, and the seller was reluctant to have us involved in the deal at all.  Finally, we got a tour of the product’s features.  Our conclusion, as we had guessed, was that this technology might only get our clients 20% of the way to their goal, and the costs of building out from and interfacing to that platform would eat up any value in the 20%.  The clients were enticed by the prospect of partnering with a known entity, which was a value point for them.  We just wanted to make sure they knew what they were getting in making their decision.

In another instance I became familiar with, a company wanted to build out a very complicated workflow critical to their customer retention.  A salesman convinced them that they could build their system on a well-known customer relationship management (CRM) platform, and would get all the benefits of CRM, like managing their prospects, plus their workflow.  They did get their system built competently, but it was based on a tangle of customizations to the platform.

Fortunately for this company, things worked out reasonably well.  However, when I looked at how the system had been sold, I realized that the glamor of the core technology made them think they were getting a lot more than they did.  The CRM system was not a bad technology, but it got them nowhere close to where they needed to go.  Had the system been designed and developed “from scratch” the effort to get them the extras they were promised in the CRM would have been less than 5%.  In my estimation, a custom system would have been a more cost-effective way to go in the long run, and would have been a cleaner design.

3.       Pay now, or pay later.

Custom software is typically more expensive initially than a package, often considerably more.  Therefore if you can get 80-90% of what you want in a package, you should probably go that route.  There are plenty of systems and packages out there meeting a huge range of needs.  If you are not looking for customization at all, you are probably fine.

However, if you will be customizing a product or package to meet your goals, you may want to make a long-range calculation of your investment.  Maybe you will save 50% up front by customizing a product compared with a custom solution.  However, you will be paying for the product and the customization by developers.  Also, products may have annual licensing fees, which tend to increase.  You may also be limiting the value of your intellectual property.  Your software might be turned into a product to sell to other companies.  This can still be done based on customizations, but then you are selling an add-on, rather than a full product.

4.      Version sensitivity.  Upgrades are a problem.

Continuing our discussion of pay now/pay later, we can also point out version issues, to which customization of products/platforms are particularly sensitive.

In software, operating systems, standalone products, and custom systems seem to have a long lifespan.  Windows XP was released in 2001, and is still supported by Microsoft, and is the operating system of choice for many.  When the Y2K crisis was upon us, companies realized that they had hundreds or even thousands of programs that had to be checked that had been running for many years.

Version upgrades to a product tend to “break” customizations.  This is an issue programmers have been dealing with since the early days of computers and software.  The impacts of version upgrades on customizations run the gamut between: everything is fine as it is, a few small tweaks will take care of it, major re-coding needs to be done, and the customizations simply cannot be ported to the new version.

During my years at Cambridge Software Group in the mid-1990s, we sold products that were add-ons to Lotus Notes.  With every new version of Notes we would scramble to rewrite them.  By the late 1990s Notes had evolved to the point where our products were out-of-date.

Recently I spoke with a company that had commissioned a system to automate workflow a number of years ago that was designed and built by customizing a subscription product.  The initial development had proved challenging, but was completed successfully.  Subsequently they paid for, but did not implement several version upgrades to the product.  Why?  They knew that each version would break their customization and thus necessitate a fair amount of development effort to get the system working again.  Finally, after several years, support was being dropped for their version, forcing them to upgrade.  They soon realized that weeks of development (at expensive rates) were going to be needed to rework their customization.

Another downside factor for this company was that the regular version upgrades they had to defer most likely contained important bug fixes and useful enhancements.

Had this company originally opted for a custom-designed system, they would have had far fewer of these issues.  They may not have had to upgrade at all, or if had chosen to do so, it would have been at the operating system or programming language version level.  In relative terms these are usually far less traumatic.  As we noted earlier, custom systems can often run for many years without upgrades.

5.      Integration, interconnection: lateral customization can be good.

So far, my comments have not been favorable to customizing a product or package.  Yet there is a kind of customization that, generally speaking, is good.  It is generally straightforward, less sensitive to version upgrades, and can add a great deal of efficiency to the business.

Many products and platforms provide APIs that allow developers to connect them with other systems.  Businesses generally run on many software systems, and there can be real power in interconnecting or integrating them.  This makes for more extensive process automation and workflows, and brings valuable data to systems where it can analyzed or distributed.  For convenience, I refer to this as lateral customization.  Typically this involves getting data from one system into another, like an export-import, but automated.

Because lateral customization is often treated as a core feature by product companies, they will typically provide clean APIs, and will make an effort to make version upgrades as low-impact as possible.  Also, you are dealing with well-defined points of entry and exit, rather than changes to the fabric of the product.  Even if some coding is required for a version upgrade, it will usually be straightforward and well documented.  In addition, there may be standards that apply, such as ODBC for inter-database connections – meaning that you are working in a rational, well-supported world.

6.      Customization of core logic is not so good.

Unlike lateral customization, if the core logic of the product is being tweaked, this is more challenging.  Let’s say the product is designed to move tasks from A to B to C.  If you would like the product to move the tasks from A to B to C to D to E to F to G, this is a considerable extension of capabilities.  If you want it to move tasks from A to D and E in parallel and then conditionally to C or F, and then back to A, this is likely to involve core customizations.  How vulnerable these will be to version upgrades will depend on the product.  However, it is certainly a red flag calling for serious evaluation.  As we noted above, the value of the core technology may not be sufficient to justify the long-term costs and complications, even if there is an initial savings.

Developers know that whenever you are customizing a product or platform, you are dealing with various limitations, quirks, and bugs.  Sometimes these can be brick walls.  When you are doing custom work, there is much less of that to contend with.  Such limitations can add to long-term costs, which may call into question the ROI based on the initial cost savings.

When selecting for a customizable product, it is important to do further research.  If the customizations will be minimal, and almost everything can be done with configuration, there is only a small risk.  If a good deal of customization will be needed, be sure to assess the value of the core you are getting, as we noted above.  If you are satisfied, then make sure to talk with your software people about the quality of software tools provided for customization.  Some product companies are careful to support the migration of custom code that worked on older versions, even when their upgrades add new customization capabilities.  Some do a good job of documenting the upgrade path for custom editions.  However, not all are that friendly.

7.      Not your father’s custom software.

When I began work as a programmer in 1980 developing industrial control systems, we were working in assembly language with virtually no debugging tools, “burning” chips for every change, and writing pages and pages of code to do simple things like an integer divide.  We were also very constrained by processor speeds, especially challenging since much of the processing was real-time.  I remember spending days poring over a section of code just to find one more register to use for calculations during an interrupt, so I could avoid using much slower memory – and this was make-or-break to the viability of a product.  Despite all the challenges we managed to develop both the software and hardware for some extremely sophisticated products over a number of years.

Today the tools available to software developers have advanced by at least two orders of magnitude.  Computer speed, memory, and disk storage have ceased to be limitations for most developers.  They often don’t worry about efficiency and optimization any more.  We now have libraries of routines making it easy to do complicated things.  Our development, debugging, and code management environments are fabulous.  Software development still poses many challenges, and requires talent, creativity, artistry, and experience to do well.  However, those artists can now do things much more quickly, powerfully, and reliably.

What this means is that custom software is easier to develop, and the costs are approaching those of customizable products, certainly when analyzed over the long haul.  Also, due to all the improvements, custom software scales well.  What used to require a mainframe is now done on a small server box in the data center.  Developers can use readily available libraries, modules, and tools to build enterprise-caliber software, or web software that serves tens of thousands!

Also, experienced developers have a repertoire of code and routines they have done in the past, along with the know-how, which give them a leg up on new projects.

8.      Extensibility.

Custom software may cost more initially, but what happens when you want to enhance or extend your software?  New software capabilities can translate into new business opportunities.  Businesspeople often have wish lists of things they would like to do as software enhancements.

One of the beauties of custom software is that you are not boxed into the limitations and quirks of a platform when you want to add capabilities.  Your desired enhancements may or may not be easy to do.  However, unless you have selected a product or platform specifically because it will facilitate a planned enhancement, chances are it will be easier to do in a custom environment.  When custom applications are completed, developers are often aware of many “low hanging fruit” enhancements.  This is why it is often so difficult to tear programmers away from their code.  You hear them saying things like:  “In just a couple of hours, I’ll be able to add the … feature, which you weren’t planning on having until next year!”

Customize of Custom?

There is often a strong lure up front for customizable products because of a lower initial cost.  Hopefully, the considerations we have listed will help the businessperson avoid some of the perils involved.

Is it always a mistake to customize a product then?  By no means!  In fact, I would always argue that the proper sequence when you are looking to buy software is:

  • Is there a high quality product, package, or service that meets most or all my needs out of the box, and that only requires configuration?
  • If not, is there a high quality product, package, or service that can meet my needs by doing some customization?
  • If not, what are my options for hiring a programmer or a team to build a custom application for me?

Nowadays, there are so many packages and products out there, with so many niches covered, that finding a good fit for your business is easier than ever before.  However, the considerations above have shown how important it is to do your due diligence.  Resist the sales hype, the inflation of core capabilities and value, and the minimization of the challenges involved in customization.  Also, consider your long range aspirations and the overall costs over a number of years.

Don’t assume that a product will do what you want.

This is not an issue with customization per se, but it is relevant to the discussion.  If you find a package you think will work for you, don’t assume it will do the things you really need it do – just because it is a high-end package or is expensive.  People will often see a demo or a review and be completely wowed, and just assume the product will do the minor thing they are looking for.  Make sure you investigate and find out exactly how it will do what you need.

In the last couple years I have twice run into businesspeople who needed an accounting system to do split invoicing.  One CEO of a 150-person company was spending many hours each month to fix his invoices manually, because the expensive system he bought couldn’t do it.  Another individual who did do a careful investigation reported that he researched many systems before he found one that could handle split invoices, and it was quite expensive (but worth it for what he needed to do).  Perhaps today more products have those capabilities.

Ask for Expert Help

If you are unsure about products, packages, subscriptions, and customization, you can ask experts for advice.  Talk to some vendors first so you get a feel for the lay of the land, then find an expert who is not trying to sell you a product.  It is best to find one who has some familiarity with the types of products you are considering.  However, understand that even the “experts” may not be familiar with all the products you are considering.  There are so many thousands of products out there, and so many ways people want to use them, that even the experts will want to check in with colleagues, do research, grill the vendors, or do proofs of concept.  Consider hiring an expert to help you do your due diligence. This may seem like throwing away money, because you are not “getting” anything – whereas the vendors will come to your office and give you a free dog-and-pony show.  However, this relatively small up-front expense may save you from making a big, expensive mistake.

Preferred Systems and Platforms for Customization

Most software companies do work with customizable products and platforms, even if they specialize in custom work.  It might help the reader to understand how we at Russell Kennedy Partners look at those systems.  This is really a “personal” perspective that has evolved over a number of years.  There are many excellent companies that have very different specialties.  Therefore I offer this as an illustration, rather than as a recommendation.

  • Some packages that are highly specialized – tax software, for example.  It would be totally impractical to try to duplicate these in a custom design.  If they provide developer tools, then they can be incorporated into or integrated with another system.
  • Sometimes we work with systems we are targeting for data and information, like the major social networking sites.  We use the documented APIs to retrieve data so we can build the software we want.  The end-result may be custom work, but by necessity it is dependent on other major systems.
  • Sometimes our assignment is to build an add-on to a product or package for a client, perhaps to create a product, or perhaps to provide a valuable business connector.
  • We sometimes work with packaged systems, but we typically prefer those where we gain valuable features and that have excellent software tools for interface and customization.  As we have worked extensively with Microsoft products in recent years, we favor platforms like SharePoint.  It costs less than comparable third-party offerings, has a tremendous support network, and can be readily customized with sophisticated classes in Visual Studio (Microsoft’s development suite).  A platform like this, “close to the operating system,” provides a broader safety net than the average third-party product.

Copyright © 2012 Patrick D. Russell


This entry was posted in ARCHIVE (Posts prior to 2013), Software Price/Value. Bookmark the permalink.

Comments are closed.