It's generally been the case that any organisation looking to deploy a BlackBerry device fleet will look to deploy a piece of software called a BlackBerry Enterprise Server (BES) on-premises. The BES server acts as a proxy between the Exchange server and the device, shuttling information from the Exchange store (mail, contacts, and calendar primarily) to and from the device.
Thus far I've been describing the old world of BES v5, the current product. In January we should see the next version of this - BlackBerry Enterprise Service 10 (BES 10).
BES 10 will become the new name for BlackBerry Mobile Fusion 6 Server, typically known as just Mobile Fusion. Mobile Fusion is a modular mobile device management (MDM) product. What's going to happen next year is that BES 10 will be used to manage BB10 devices, and will also be able to drive the existing management capability in BES v5. BES v5 will still need to be in there, on your network, as a "broker". Thus if you're looking to operate a mixed fleet of BBOS 7 and older devices together with BB10 devices you'll need both the old and the new pieces of software.
Under the hood, the part of BES 10 that talks to BB10 devices is a little different in that rather than using proprietary hooks and hacks into Exchange as per BES v5 it uses the quasi-open Exchange ActiveSync (EAS) protocol. I say "quasi-open" because EAS understood, supported, and commonly-used, but subject to a commercial license.
This alleviates one of the criticisms of BES v5 - that it's fiddly to configure because it's evolved over time to become a mess of proprietary bits and pieces. BES 10 is much simpler because of this dependency on EAS.
Now that we know what BES 10 is, why is it essential that we have it?
I don't tend to believe that features sell to consumers. Most people don't walk into a retailer and ask for the phone with the greatest technical superiority. Instead, most people get sold something and validate the decision based on what their peers are buying.
With BB10, BlackBerry Balance could be different - it's one of those features that comes along once in a blue-moon that's logical, simple, and more about what the user needs as opposed to what a bunch of technologists think they need.
The idea behind BlackBerry Balance is that your one physical device contains two logical devices - one for "work" and one for "personal". The business provisions the work logical device on the BES 10 and can then do whatever they like in terms of locking that part down. Trying to email draft company accounts to Jane your friend, as opposed to Jane your CFO? The boundary protection features in BlackBerry Balance will stop you doing that. The personal logical device you can do what you want with. So, if you want some downtime to check Facebook, or if you want to send a personal email, flip the device into personal mode and off you go.
(I should say that BlackBerry Balance has been around for a while in PlayBook and BBOS 7. But in BB10 it's much more closely melded into the UX of the operating system than on the previous handsets - whereas previously it was more about boundary protection, as per the example above..)
Why this makes sense is that the proposition is compelling for the majority of the market who don't care what phone they have. That individual can go into a retailer and say "don't mind what I get, but work say if I buy a BB10 I can use it on their network and I don't need to carry two phones". BlackBerry Balance creates a really simple hook on the retail side.
From the other side, it's ridiculous that the other smartphone platforms don't offer this. (For that matter, I've always wondered why the iPad doesn't support multiple user accounts.) BlackBerry Balance solves the BYOD issue with an elegant simplicity that's reminiscent of "Old RIM" - you know, the sort of thing that used to make us buy their solutions back in the mid-2000s.
What's this got to do with BES 10? Simple - BlackBerry Balance is only active on devices that are connected to BES 10. The "work" bit connects to the BES 10, the "personal" bit connects to whatever else you want it to.
Without the BB10 device connecting back through to BES 10 all you have is a device that looks and behaves like a competing smartphone - i.e. nothing special.
I'm a great believer in the curated store model of software distribution. We've had to put up with over 20 years of malware and viruses, actually slapping some controls over that process to protect the general user community has to be a good thing.
But there has to be some softening of that. Companies will want to install their own software that bypasses the store controls - after all, it's their users and their devices. This process of being able to load apps is called sideloading.
(Mary Jo Foley has an article where she explains Windows 8 sideloading. Although that's Windows 8, the same principle applies.)
With BB10, the only way to deliver private, sideloaded apps is via BES 10.
On BBOS7 and earlier versions, users could install apps by via an "over-the-air install". They just opened their browser, put in a URL to a .jad file, and away they went. Blast through the security warnings and on it went.
Back to the curated store world, and that sort of thing is bad news. It makes much more sense to control the catalogue of apps that a user can have centrally. This is one of the key precepts of mobile device management (MDM), and sure enough on BES 10 you can create policies to control device downloads, create whitelists of publicly-available App World apps that the user can install and relevantly to this part of the discussion, and finally the sideloading bit: publishing private apps to distribute within the organisation.
You can turn off the restrictions entirely by enabling "developer mode" on the device but this will open up the device entirely. It's also likely to be a pain to have to do that if you have any number of devices to manage. You can do a similar thing with Android, and I tend to tell my clients to avoid doing it at all costs as it opens up all sorts of security problems.
In summary then, if you don't have BES 10, you don't get to do sideloading.
BlackBerry has a slightly odd setup in that devices don't connect over the public internet as per all the other smartphone platforms. Instead data is routed through a secure, proprietary messaging system. At the device end, the device sends data to the mobile carrier's NOC, where it's sent down specially-commissioned leased-lines into a local RIM data centre. When a BES server boots (v5 or BES 10), it goes over the public internet and into one of these secure data centres as well. (As you'd expect, there's routing between RIM's data centres in case the device isn't local to the BES's chosen data centre.) The two sides join up and the device can reach over the cellular network, into the BES in the private network, and from there into the Exchange server. This model carries forward from BES v5 into BES 10.
What this gives you is a totally unique network structure. More to the point, no one would ever go out of their way to build such a thing now. The RIM design was of an era before the mobile carriers delivered IP connectivity down to every device on the network. Now all of the other mobile platforms (iOS, Android, and Windows Phone particularly) assume that the mobile carrier is giving them a TCP/IP stack to use. RIMs model is very secure, and is a good win if you're one of those organisations that particularly wobbly about security. Connections from the device to the carrier are encrypted and secure. Once in the carrier, traffic then goes through an entirely isolated sub-network within the carriers NOC, and from there down into RIM's NOC via a leased line. The only "public internet" part is from the BES server out to RIM's NOC.
If you don't have BES 10, BB10 will "failover" to using the carrier's TCP/IP stack. From there you'll need to ensure connectivity from the public internet into the EAS end-point exposed by the Exchange server.
Following on from "Reason 3", the genius of the BES design is that because the server is behind your firewall, each BES connected device (whether old-school BES v5 or new BES 10) is also effectively wired in behind your firewall too. This is because of RIM's strange network setup. Logically there's an always-on, point-to-point connection from the device and into the private, on-premises BES.
A perennial problem in building mobile solutions is that the data needs to be exposed out through the firewall. This is typically done by putting a server in a DMZ that external devices connect. Alternatively organisations will setup a VPN and expect device users to dial-in to the network over the internet.
With BES 10 you don't need to do any of that. Provision a device on BES 10 and RIM's network design does all of that heavy-lifting for you. You can configure an HTTP server on your private network and then build an app that connects directly to that server. Publish that app privately through BES 10 - users can then download it and when out of the office and without VPN they can reach directly in, behind the firewall and access that private information.
Whilst I'm sure a good number of sysadmins just did a sharp intake of breath on reading that, personally I really like this. The number of projects where I've had to struggle with an ops team to get a DMZ configured is a larger number than I would care for. So, rather than it being some uncontrolled security vector roaming inside of the private network, ops managers can approach it as a controllable, trustable, security appliance that you can bring to bear on multiple projects.
And the fun part about this one - Apple and Microsoft would probably kill to have this sort of feature on their platform. RIM got there nearly a decade before either of them.
Companies that already deploy BES to support their BlackBerry fleet aren't going to think twice about deploying BES 10. My understanding is that deployment of the product is much easier than the traditionally nightmarish BES v5 product, so actually they may be in for a net win. The fact you need two servers right now I don't think is important - any sysadmin worth their salt is hardly going to break out into a sweat adding an additional server to their management roster.
You should also note that BES 10 supports off-premises, cloud-based email services. (And although organisations might not be pushing the button on that now, those that plan out five-years hence may well be thinking hard about it.) Although BES 10 still has to be installed on-premises, because it's based on EAS and not proprietary magic it can reach out to the hosted Exchange server in the cloud in much the way a normal client might.
The only wrinkle in this picture is that with BES 10 there is no free-usage product as per the Express edition of BES v5. The Express edition was weird in that it supported for thousands of devices whereas you'd expect a free edition to support a handful. My read on this is that having BES as a revenue stream in the glory days was easy, but competition delivered a lot of downward pressure on the price. The Express edition is very common, even in large organisations. But with BB10, those free usage days are gone - each device will need a paid license.
You should note that because BB10 devices can talk to EAS natively you get some MDM features without having a BES 10. (Encryption and remote wipe being the two most obvious). It appears that RIM is thinking that companies that want to stick on a free-tier will go from Express to EAS directly into Exchange.
But if you do that, what you don't get is sideloading, the uniquely secure RIM network, and simplified server publishing. You will also lose most - it not all - of the BlackBerry Balance feature. What you will lose is not clear. RIM may argue that some BlackBerry Balance features like remote wipe and boundary protection are available in EAS. But the whole shebang, the fantastically sellable UX of BlackBerry Balance on the device - I'd expect to lose that with an EAS-only approach without BES.
In summary, without those four features, BB10 offers nothing over and above the iPhone, Windows Phone, or even Android.
What do you think? Post a comment, or talk to me on Twitter: @mbrit.