What’s Under the Hood of Your Alarm Automation System?

by Rod Coles, President/CEO

I remember buying my first car: it was a 1967 Austin Maxi; I paid £100 for it. Before I paid out my money, I looked it up and down and then I looked under the hood. To me, it looked like a mechanical mess, but my Dad explained what all the various parts were, and what was good and not so good about the engine. Since that time, I have purchased a few more modern cars, and the engines have become more advanced, but each time I have looked under the hood checking the basics, like the first time.

Do you know what’s under the hood of your alarm automation system?

Is it a work of beauty like a Mercedes or Ferrari engine? More basic, but solid like a Ford? Maybe it is one of those kit cars that looks like a Ferrari, but has an old 1967 Maxi engine. Or, is it just an old 1967 Maxi?

How do you know? What makes up the “engine” of an alarm automation system and does it even matter? Why should you care?

Your automation system is a complex piece of software that runs your monitoring business and has some caveats other software manufacturers don’t have to address. For example, it must run 24/7. You can shut down your accounting system for a few hours on a Sunday afternoon, but not your monitoring.

We all know that changing monitoring systems is an involved process, so making the right decision is important. Ensuring the product has the functionality you need is a given, but you need to do more; you need to look under the hood.

Here are four things under the hood of your monitoring system that you should question:

  1. What programming language is it written in?
  2. What database is it using?
  3. Does it support multi-processing?
  4. Does it support 64-bit applications?

What programming language is it written in?

The programming language is important because it tells you how future-proof your investment is. If the language is not enjoying popular support, then:

  • It could have many flaws.
  • It could be hard to write in, and therefore not productive.
  • It could be hard to produce good products.
  • It could be hard to get good programmers.

Most companies use a variety of different tools; this perfectly normal. The questions you should focus on are at the core of the application: “What language is the signal processing written in?” and “What are the main user interfaces written in?”

If you get any of the following responses, you should be concerned:

  • “Delphi” – originally developed by Borland in 1995, it was purchased by Embarcadero in 2009. The Technical Career recruiting company Dice.com listed Delphi as one of five languages destined for death. This is one you should not invest in.
  • “Thoroughbred“ – developed by a company of the same name in the 1980’s. This is a 4GL language which used to be popular in the 90’s. 4GL’s were never really intended for large projects; the advent of the internet killed most of them. This is a very proprietary system and definitely has its limits.
  • “Powerbuilder” – another 4GL product developed in 1991. Now owned by SAP, it has been kept up to date, but the main criticism is that it is always following, never leading.
  • “Visual Basic” – developed by Microsoft in 1991. This product was declared legacy by Microsoft, and has since been replaced by their .Net products. This language was used by Bold to develop its original User Interface for Manitou, but has been replaced by the browser-based ManitouNEO, which is written in HTML5.

What database is being used?

The database is very much at the heart of your alarm automation system; it contains all your data. It’s responsible for keeping your data backed up and replicated, as well as its integrity. The type of database being used is dependent somewhat on the operating system. All automation providers except one use Windows as the server environment, so that is what we will focus on. Microsoft SQL Server is by far the market leader in the Enterprise Database market; it has proved itself to be a front-runner and innovator. Quite frankly, any provider not supporting Microsoft SQL should be avoided. One product to be particularly careful of is Sybase ASE (now SAP). Bold moved away from this product in 2005 because of MS SQL Server’s superiority. Another warning bell? There has not been a major release of Sybase ASE since 2014!

Does it support multi-processing?

You might think this is getting too techie – what is multi-processing anyway?

Multi-processing is the ability for your software application to do more than one thing at a time. An example might be processing more than one signal at a time or handling more than one request from an operator. It’s like having four security lines open at the airport versus just one.

Well, they must already do that, right? The answer is not as obvious as it seems. Computers are very good at doing things quickly, so you may not notice. Just like the airport, one line is fine until it gets busy, then things start to slow down. You may not notice this problem until your business starts to grow. Additionally, you may not be making the most use of your server. Typically, a server will have four or more cores (think of processors). An application that does not support multi-processing will only use one core. That’s like having four security stations at the airport but everyone is using just one line. You are paying for equipment that is not getting used.

Does it support 64-bit applications?

This one may actually be getting too techie, but stay with me. Most computers being purchased today are 64-bit. What that means to you is they can run faster and process more information. Bold’s ManitouNEO product is available in a 64-bit version. This means as your company grows, the software grows with it. If you run a 32-bit application on your new Windows Server with 64GB of memory, it can use a maximum of 2GB – the rest is wasted money. So, check to see if your automation provider can provide 64-bit software.

Cloud Computing

We are going through a major industry change right now. Traditional, on-premises software is moving to the cloud, and that makes this due diligence even more important. As a kid, I remember my Dad lifting the hood of our VW Beetle and telling me that someone had stolen the engine. Aghast, I looked at the empty space where our engine should be and wondered how that had happened in the ten minutes we had been in the grocery store. Like the Wizard of Oz, my Dad was pulling the strings, showing me what he wanted me to see.

With the advent of cloud computing, this will happen more and more. Software companies can hide all their old c#@p in the cloud behind a shiny new user interface, and you will never see it. So, does it matter, “out of sight, out of mind?” It’s not like you will have to deal with it, will you? Yes, you will, because the demands of modern software are way beyond what many of these products were designed to manage. The programming languages they are written in are old, they may not be supported long-term, and they don’t allow your automation provider to react to a changing industry. Most importantly, they are not scalable, which is crucial when talking about cloud computing.

Since Bold acquired ABM a few years ago, there are now about seven software providers left in the industry. Most of these companies have been around for 30 or more years. All automation software companies are faced with the same problem; as technology changes, how do they keep up? Back in 2000, Bold had the choice to continue with its Theos based legacy product or re-write. Bold started from scratch and built their Manitou product line, and what they did really well was the software foundation. At the time, no one knew whether Windows or Unix/Linux would be the operating system of the future. Bold built a foundation that was operating system and database independent; the foundation of the Manitou product was written using C++. That is the same language that Microsoft, Adobe and Oracle used for its products, and is at the core of many their products today. Since that time, the core has expanded to include C#, HTML5 and Java Script languages, but these are languages you can be confident in.

One more consideration is the User Interface (UI, or “what you see on the screen”). In 2003, Bold released Manitou with a Windows UI. Previously, character-based UI’s were the norm. Today, Windows UI’s are outdated. Now browser-based UI’s are the norm. Bold recently released ManitouNEO with its new browser-based UI to replace the Windows one. Browser-based UI’s are more flexible, integrate easier with other products, and are simpler and less disruptive to deploy. The reason Bold could drop in a new UI is because of the solid foundation on which the software was designed. It had good separation between the UI and the back end of the software.

In summary, these four questions should always be considered when looking under the hood of your current or potential new alarm automation software.

  1. What programming language is it written in?
  2. What database is it using?
  3. Does it support multi-processing?
  4. Does it support 64-bit applications?

And don’t forget the Cloud. It’s a fantastic technology, but it can also be used to hide some poor solutions. In our business “okay” is not good enough. While it is true not everyone needs a 2017 Ferrari engine, it’s important to do some basic checks and make sure that it’s not a 1967 Austin Maxi.

PS – If you are wondering what a 1967 Austin Maxi looked like, here it is: