In virtually every RFP we receive, we always get the same extensive list of questions on features, security, and data protection.

Here’s one question we never get:

"What is your plugin architecture based on?"

From personal experience, we cannot stress the importance of this question enough. 

Old MS Word plugins are built on the COM and VSTO architecture. These plugins work by spreading their tentacles deep into the bowels of MS Word to allow them to manipulate it in the same way a puppeteer manipulates his puppet’s strings.

The plugin's freedom to do whatever it wants, has significant drawbacks:

  • Instability: any programming mistake can cause Word to crash, or cause mysterious errors.
  • Plugins cannot play together nicely, and can easily step on each other's toes. Again, causing crashes.
  • Complex Updates: Patching these add-ins isn't straightforward. IT admins often struggle with compatibility issues.
  • Slow: the old plugins rely on local memory and CPU resources. This slows their launch time significantly.  

Eventually, Microsoft took notice and created a new type of plugin architecture called (a little bit uninspiringly) “Office Add-Ins”. 

Plugins of the new generation:

  • Do not consume local memory or CPU resources, ensuring better performance.
  • Are pushed from the cloud, meaning no local installations.
  • Are based on modern web technology, and can therefore run on Windows, Mac, mobile devices and even in browsers.

But just because this new technology exists, does not mean that vendors are spending time and money converting their existing applications towards the new plugin architecture. In fact, for many existing plugins that have been on the market for quite some years, this conversion is simply impossible to do, because a lot of functionality they rely on is deliberately forbidden territory in the new plugin architecture.

The inherent issues are often not detected until a proof of concept or until the contract has already been signed.

When shopping around for a new plugin, ask your vendor whether it uses the old "COM" or "VSTO" architecture, or instead the new "Office.JS" architecture.