How to recognize a good Notes component...

I will discuss here how to recognize a good component. By component I mean an external software that is installed as a module and it extends Lotus Notes or Lotus Domino. For example an antivirus, or a disclaimer.

A good component will always meet the expectations without giving too much work to the administrator.

Here are some tips that are useful when you evaluate a Lotus Notes/Domino component:

* It must be built using the Lotus Notes C API: Many components uses Lotusscript or formula or java or the C++ API. Lotusscript has serious disadvantages for example agents in the server have a time limit and it consumes CPU. The java API or the C++ API are just wrappers of the Lotus Notes C API.... so it's just another layer that makes the development of the component easier. Developing a component in Lotusscript or Java or even the C++ API is by far easier than developing it in Lotus Notes C API. Again, for the vender it's easier (and cheapest) NOT to use the Notes C API since development is faster. The Lotus Notes client and the Lotus Domino server themselves are written using the Lotus Notes C API... the indexer, the replica task, the Notes client and all internal components uses this API. As you can see if the component uses this API then it will be at the same level than the Notes client or the Domino server. It's a native API. The C++ API for example will be discontinued (it is already discontinued) by IBM... they said it in Lotusphere 2009. The Notes C API is the lowest-level API so it provides with with full capabilities. If you as a customer wants your vendor to do an enhancement to a product, if your vendor uses the C API then it will for sure be able to implement this enhancement.

* The component should not modify any Lotus Notes DB template. It's easier for deployment purposes to modify the DB templates. However when it's time to do an upgrade or to modify the template then here problems start. Consider migrating from 8.0.2 to 8.5.1... templates will need to be also migrated so you will loose the vendor components, or you will need to do extra work to also migrate the vendor component. If you have two components from two different vendors that modifies the templates then you will be in serious problems. Uninstalling code from templates is a mess if you have modified the same template for other purposes...

* Ask to other customers to see if the component is well working. Usually in the site of the vendor you will find the customers... feel free to contact them to ask about post-sales services. If you go to notes.net you will find many questions from customers using antivirus from serious vendors where they don't answer their questions or they say "wait 6 months and in the next release it will be fixed".

* A recent version number with many nice features does not mean that it's more stable than a previous one. The more things they provide in new releases, the more complex the component. As you know, Domino 7.0.3 is more stable than R 8.0.1 for example.

* A crash during the testing phase is a REAL OPPORTUNITY!!! A crash does not mean that the component is really bad. All components crashes... even Domino itself crashes as you already know. So if you find a crash during testing phase then this is a opportunity since you will be able to ask the vendor for a solution and you will evaluate the support. Don't interpret a crash as a fatal bug, it's a bug that affected the memory and it caused a crash... the same bug could have affected other things than the memory. Again, take into account the time it takes to the vendor to solve the problem.

* Deployment. Deploying a server component is straightforward. But depoying a client component is harder. There are many ways to deploy a client component. Sending emails to the users to ask them to execute an attachment, sending an email to all users with a stored form that silently deploys the software, modifying the DB template, and so on... a good component's vendor is not the one that tell you "this deployment method is the best, bla bla bla". A good vendor will ask you "which deploying method from the following list do you prefer?". Again, a good vendor invest time and effort in software to make administrators happier.

* Compatibility with other components. Making one component compatible with another is not easy. There are things that cannot be always covered. For example if you have an antivirus and an antispam (usually they are joint but just for the example purpose) from different vendors then you will usually have a synchronization problem. The best component will provide you with a mechanism to configure itself in such a way that it can recognize the other component. For example an antispam can recognize that an antivirus is installed... so it will wait for the antivirus to do its job and then the antispam will do its own job. In this case the antispam is a "better component" than the antivirus since it implements all the synchronization mechanisms.

I hope it helps you to evaluate a component. Evaluating a third party solution is not an easy task...