A Building Manager (ABM) is faced with many things as automation replaces labor and paper. One of these things is deciding which -- of the massive amount available -- of hardware and software options should be used in their buildings.

Depending upon the facility's size, the building manager may be able to decide upon and purchase these things directly; or the manager may be part of a decision-making team that collectively decides what should be brought in.

ABM may also need to make the decision on whether to purchase the software/devices from a 3rd party, or if some of these things can be done in-house.

There was an AutomatedBuildings (AB) article recently
http://www.automatedbuildings.com/news/jun12/articles/tyrrellsystems/120528011404tyrrell.html
about how the author believes that technical details are no longer more important than function in devices nowadays, and that APPs are better than browser-based applications.

B U T, the technical aspects of devices, platforms and software must still remain a top factor in helping to decide on what ABM purchases. Here's why:

Background

A good deal of the push towards APPS (applications loaded directly onto devices) versus browser-based was stimulated by the device vendors themselves. Apple really started this trend by deciding that they can more easily control what is in the applications run on their iOS iPhone/iPad platform -- if they were in the form of applications directly on the device themselves -- rather than in web-based applications that could change after Apple had approved them.

And by the way, then Apple could also charge a hefty fee for each application purchased from their app store as well. This is a revenue source that they would not get if applications were run directly from the internet in a browser. Soon, the other mobile OS vendors were rushing to create App Stores of their own as well.

As a byproduct of this, the software developers writing the applications that ABM actually cares about, now have to write separate versions of their applications specifically for the generally closed APP frameworks of each platform vendor. (See Figure 1).

The benefits from all of this really are more for the device vendor, than the user, or the software developers -- who must now [usually] create separate versions for any of the device platforms that they wish to support. That is, if they expect optimal performance from the underlying device.

One immediate impact to ABM is that they may need to handle different APP versions (and contracts; and vendor contacts; and feature upgrade timelines; and costs) for the same application running across different platforms in their buildings. All as opposed to a browser-based app, that would be bought once and run on everything.

App versus browser-based applications

I am not as quick to say that the move to Apps versus browser-based applications on mobile devices is a good thing for users (or for developers).

What really is happening here is more of the device/platform vendors (e.g. like Apple/Microsoft) realizing that the dollars of the old model of being able to sell applications as packages on PCs was going to drop precipitously, as customers moved toward mobile devices. Users wanted applications to be web-based, and therefore available from anywhere. Not just as a package installed on just one PC/Mac. The platform vendors found that by evolving (forcing?) the APP model on devices, that they could replicate the model flow (and approximate dollars) of the sell-an-application-as-a-package on a PC or Mac model.

The trade-off is that developers have to develop separate versions for each of the desired target platforms, with more development dollars being spent on rebuilding apps specifically for each platform and less on new or improved features for the application itself.

How does ABM decision today -- affect tomorrow?

It's not all about functionality. Really. There is also the impact on your buildings if the company providing the devices makes a dramatic, unexpected change in the way they do things. Or, worse, if their underlying technical platform can not keep up with changes in the market.

For a good example, consider all of the users of the Blackberry from RIM. The growth of the Blackberry was tied to a very easy to use push email interface. The email framework was wonderful and many bought into the platform as a result. But in the long run, RIM struggled because their underlying platform was difficult for 3rd party vendors to build applications for and they could not keep up with the massive jumps in functionality offered by Android and iOS (Apple) devices. Blackberry became a closed platform, that no one wants to build for now.

Sidebar To be fair, there are many other examples of companies pulling the rug out of proprietary platforms. Microsoft has, almost shamefully, changed their platforms at their will. The latest example is how all Windows Mobile 6 and below applications just won't work on the new Windows Phone 8. Why should users have to replace all of their apps? -- other than for the obvious answer that Microsoft gets the App Store revenue from all of the replacement apps that must be re-bought. Apple's Firewire anyone?

If you have hundreds ... or thousands ... of Blackberry devices now, purchased only for the features that they offered, then you have already learned that the underlying technology of these things are important and really needs strong consideration as well.

If you had bought into the RIM experience on a large scale before, you are probably looking at switching out much of your infrastructure now for more flexible devices, and those with wider support. And you are probably learning a good bit about Android versus iOS technical aspects, because you want to get something flexible. Something that will grow and that will not lock you into one type of device.

I have to note that with the tools we make at Fundamental Objects, that we are not really affected either way. (We have both browser-based and APP versions for most of the mobile platforms). So whether users want either type -- or even both -- we are set. So the point of this article as it affects us is not to push one way or the other -- but to choose the one that is best for ABM and the ABM's users.

What is ABM to do?

So, what kinds of things should a building manager look for when purchasing software and devices?

[an error occurred while processing this directive] Here are some things to look out for, or at least to consider when making hardware/software decisions for mobile devices:

• Flexibility. Features are great, but features (and needs) change. Try to think through what you will need in the longer run, and if the tools you are buying will be able to adapt to add those things in.
  

• Cross Platform. Does the tool/software/device that you want to bring have support for more than one of the vendor platforms? For example, if you have Blackberrys in use from the corporate email push, and your users are adding in a lot of iPhones or Android smartphones -- does the tool work on both of these platforms?
  

• APP AND Browser. If software, does the vendor offer both app and browser versions? Do you have the need to use this software on both desktops and mobile devices? (Think reporting, for example ...).
  

• Feature Support. If you are looking at a particular feature that interests your users or management -- is that feature supported across the various platforms? For example, if you are looking at QRCoding for marking inventory; or at RFID tags for tracking items into/out of/or around your buildings, does more than the underlying platforms support this? (This is to keep you from being "Blackberried".)
  

Other information

Microsoft Shuts Down Windows Mobile 6.x Marketplace Today

RIM Collapsing? BlackBerry Sales Drop 43% in a Quarter

Mobile OS Market Trends

foAudits, mobile energy audits

About the Author

Bill Shadish has been working with (ok, and evangelizing) mobile energy audits for commercial and residential applications since 1998. He created and still manages foAudits, the very first mobile audit platform; and has written over 250 articles for both print and online readers.

You can reach Bill at http://foAudits.com?screen=contact.

 

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]