Default database approach

Last Friday, while enjoying a not-at-all healthy Salisbury steak with cheese, I had an interesting discussion with a partner: should NAV consultancies create default databases?

A default database (in this context) is a packaged solution built upon standard Microsoft Dynamics NAV, where a consultancy has introduced a number of features that they sell to all their customers as the standard solution, instead of standard NAV. The modifications to standard NAV can range from simple report adornments to minor feature improvements  to full-scale horizontal or vertical functionalities.

The partner offered a resolute No, while I was more inclined towards a Yes, why not approach.

I believe there is no definite answer to this question, and there are numerous pros and cons to default databases. I understand many consultancies, especially new ones, are adopting either approach without proper understanding of all implications: either they jump into reinventing sliced bread by modifying NAV all over, or they stick to holy scripture of standard C/AL.

If you have grounds for either approach, good! But if you do either way, and don’t know exactly why, you might reconsider your practices. Here I’ll try to analyze the pros and cons, so if you don’t (yet) have an opinion of your own, you are free to adopt mine 🙂 Of course, I’d like to hear from you, so if you do have an opinion on this topic, please comment on this post.

Let me start with the pros:

  • Repeatability: This is the most obvious benefit. You can give your customers more cowbell for only a slight increase in price tag. If you find yourself doing the same customization over and over for different customers, maybe you can make it more affordable for them by packaging it up into your default database, and start projects from that database, instead of from  standard NAV.
  • Specific concepts: NAV is a very generic solution. It supports most of typical ERP processes, but at a very generic level, and to successfully put them to work you frequently need to do some C/AL. A good example (up until recently, anyway) was purchase approval workflow: many customers asked for it, but it wasn’t included (now it is). If you had this functionality in your default database, you could easily enable it if your customers needed it, and do so at a much lower cost than if you had to start from scratch..
  • Vertical edge: If you plan on targeting specific verticals, your projects can benefit a lot if you start from a default database which covers some specific requirements up front. This applies in reverse logic as well: if you have developed a few specific highly vertical features, you increase your market edge and the likelihood of landing a project with customers in these verticals.

On the other hand, there are very loud cons:

  • Discipline: With a default database, you need extreme discipline in doing your projects. It is very common that consultancies end up with more default databases than there are customers (one “default” database per customer, and a couple of in-house development/staging/testing ones). When you decide to have a default database, then you should not only keep improving it for your future projects, but you should deploy the improvements to all your existing customers, and never do development of default database in parallel with implementation projects. Otherwise, the default database will backfire in maintenance costs.
  • Maintenance costs: If you decide to create a default database, you must have a dedicated person to maintain it (maybe not immediately, but after a while, you most certainly do.) This person must maintain a single default database for each official release of NAV, make sure that these versions are upgradeable, and that all of the default customizations are deployed to all customers. This can easily introduce significant overhead which outweighs all the benefits of default databases.
  • Upgradeability: By building a default database you make future upgrade projects more costly for your customers than they should be in the first place. If you start your projects with a pristine NAV solution, you have a common and a very clear starting point of all your customizations, so upgrades are easy. On the other hand, if you have a default database, in addition to maintaining it, you need to maintain as many upgrade toolkits as there are NAV versions deployed with your customers.
  • Copyright issues: Depending on your contract with customers, some customizations might end up being their intellectual property, not yours. This can raise issues with default databases and cause unnecessary disputes. But this can be sorted out at legal level, it has nothing to do with NAV itself.

Any of these arguments can be refuted at length, and there are many counter-arguments you can make against each of them (please do!). If you went like “I disagree” while reading any of the above, it only proves that there is no one-size-fits-all approach to this topic.

However, there are a few good practices that can be put to work regardless of which camp you belong to:

  • Default setups: Instead of touching the standard C/AL code, you do default setups. Things like default charts of accounts and posting schemes or functional areas setups for specific verticals, supplementary data setups (such as currencies, payment terms, etc.), number series, etc. This can save a lot of implementation costs, and leave the standard business logic untouched. It makes your projects repeatable, while not affecting upgradeability or maintenance costs at all.
  • Default RIM templates: You may streamline your projects by preparing RIM templates for specific verticals, or by adopting them to your local market conditions. This makes your projects very repeatable, and decreases overall costs, while not introducing any of the issues of default databases.
  • Default objects: You package some default features, but don’t include them in your projects by default, and you only include them upon customer request. This still increases repeatability, but is much lighter on your maintenance costs, and upgradeability.

Combine these three, and you have a winner!

But you can have a winner by adopting a default database approach, too! Actually, you already have it: it is called Microsoft Dynamics Entrepreneur Solution. It is a Microsoft’s “default database” approach with NAV for small customers: a shrink-wrapped ERP based on NAV standard functionality, which targets small customers with little interest in customizations. A highly effective way of targeting a specific market segment. This proves to me that default database approach can be a very sound one, and very profitable for its successful adopters.

There is absolutely no reason you can’t adopt the same approach by developing your entrepreneur solutions. If you are an ISV (or planning on becoming one), instead of developing your very own ERP system from scratch, why not starting from a highly customizable ERP platform (which NAV truly is), and turn it into a more specialized ERP solution that you market to a specific market segment. If ISV’s can build a stable business model by developing ERP systems from scratch, I bet you can do more by starting from a more than a solid foundation. Give it some brainpower!


Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

Leave a Reply