By their very nature salespeople are talkers, and techies are doers. This is not a rant along the lines of “All salespeople should burn in hell”, and actually it’s not really all that much about salespeople either. But like it or not – when someone is trying to sell an MDM solution to you they’ll often start by sending a sales guy over to you. (Indeed you as a techie may not even be present at the initial meetings. And yes, I am making assumptions  as to my audience.) You may not be the one with a business need for these products so that’s ok, but you may end up supporting and/or implementing these solutions. This will not be the ultimate “buyer’s guide”, and I will keep it product neutral, and rather try to highlight some things you should keep in mind regarding MDM from an enterprise perspective. Given the fact I have been turning out a few guides based around Microsoft SCMDM maybe you think this is the answer I’ll provide to all your questions, but as much as I enjoy digging into SCMDM it is not a product for everyone at the moment

I’ve had the pleasure, (and sometimes pain), test-driving a number of mobile middleware (PIM & MDM) solutions the last couple of years. Some have been really good, while others have been less good. Now it may sound silly and obvious, but the first thing you need to define is what you want to do with a mobile solution. Are you primarily interested in pushing out PIM data (e-mail, calendar, etc) to devices, or are you looking into deploying Line of Business applications? Or maybe you’d like to start with PIM to get a feel for mobility, and move on to more elaborate scenarios later on?

Just about every solution available can do the basics in some form – disable camera, distribute files, collect inventory. The details are different, but the concept is the same. And in the bigger picture – I really don’t care about knowing all these details when I try to look at it from a higher level perspective.

So what do I care about?
Scalability for one.
What do I mean by saying “scalability”?
I believe in two meanings of scalability. There’s the “hard” side of it, which is all about numbers: “how many devices can one server support”, “how much RAM does a server need”, “how do I ensure redundancy”…

Then there’s the “soft” side of it; “how do I manage 50 devices”, “how do I manage 5000 devices”, “how do I deploy the client component”…

Looking into these two facets of scalability brings up even more questions, but the point of this whole exercise is getting you to ask yourself these questions and trying to work out the answers. (And sometimes prodding a sales guy in the process.) I have however not defined yet what I mean by “Enterprise”. If you have 50 devices to manage, it most likely does not qualify as “Enterprise”, and many of these concerns will not apply to you. If you have 10000 devices that probably qualifies as “Enterprise”. A precise number cannot be affixed to the “Enterprise” label, but I believe you should start at least thinking about a few of these issues already at 3-500 devices.

Hardware is cheap these days. If you buy a server today, it will support 64-bits, it will be multi-core, and it will not have less than 4GB of RAM. That does not mean you should blindly accept “hefty” hardware requirements. Let’s look at some of these components.

CPU does not really matter all that much. MDM should not require “special” processing, so any CPU on the market should do. (You should probably opt for a balance between power and price here.)

64-bits is not always a choice. If a given MDM solution supports 64-bit – go for it. If it only supports 32-bit ask if it will run on 64-bit OS, and what the plans are for supporting 64-bit. I accept the fact that not everybody has had time to port their codebase yet, but it should be on their roadmap. If they try to pass off 64-bits as something you don’t need – be afraid. Be very afraid…

Hard drive should not be a concern, but the key to determining this is the database storage. If the DB is put on the same server box you should most likely keep it on a separate RAID.

RAM… Saved the best for last didn’t I This depends on what kind of MDM solution you look into getting. If it’s a solution doing both PIM and DM it’s perfectly acceptable that this requires more memory pr client. If it’s only DM the footprint pr client should be low. Also keep in mind that with 32-bit you’ll land somewhere between 3-4 GB max in the server. (No, do not bring up the PAE card.) But even with 64-bit the gain above 8GB is limited. The vendor should be able to say something like 4GB & 1 server = 2000 users, or some other randomly chosen number. (And I don’t mean the vendor should choose a number at random… you know what I mean.)

What numbers of devices pr server would I accept? With PIM 1000-2000. Only DM – at least 4-5000 (depending on some aspects covered in the next section). With LOB applications involved – harder to provide a generic number. (If the LOB apps don’t go anywhere near the DM servers it should not make an impact.) And as you probably understand already – don’t confuse the ability of a server to manage a large number of devices with the need for redundancy

An interesting scaling factor on the hardware side that not every vendor cites is the number of concurrent connections handled. Note that this is not the same as the number of devices managed. The network card, and the operating systems insert some constraints. With Windows Server 2003 you are not able to run 10000 concurrent sessions. Depending on how much processing a single connection requires you’re more likely looking at somewhere between 500-1000. And this is the point where you should ask how policies/settings/applications are distributed. If it’s “immediately” it’s some sort of push mechanism, which means you always have a lot of devices connected. Potentially meaning less scalability. (Being able to push for instance a kill instantly is not the same thing as initiating full-blown DM sessions through push.) How big an impact this causes depends on architectural decisions as well – is there a front-end server handling the connections, with a back-end server doing the processing?  The other alternative is scheduled connections which means there is some mechanism causing the client to trigger a connection at a predefined interval to the server. This should cause less strain on the server, but it does not help if it is a hard-coded schedule. If you have 5000 devices connecting in at midnight sharp, the server will probably not be able to accept all the connections. So you should have a mechanism that makes sure different devices connect in at different times even though they are on the same schedule.

So, are there any consequences of not having the above in mind when choosing an MDM solution, and scaling it? If you’re lucky you’ll notice from logs and performance monitors that there’s a bottleneck and/or issue, and you just add another box, or upgrade your existing. If you’re unlucky you run into an MDM admin’s worst nightmare; the server is not able to process a connecting device correctly. Something is corrupted on the client, the client never connects back in, and “goes dark”. Suddenly you have 100 managed devices becoming unmanaged, and both you and the user are blissfully unaware of it. Better yet, maybe you are aware of it, but have no clue as to how to make it managed again. And yes, I have seen this happen… (And no, I will not provide product names, or further details.) There are actually solutions to this problem as well in a mature MDM solution – ask the sales guy how to get out of this “situation”, and see if he is more than a talker and actually deserves your money

Well, that’s all for now folks. I know I said there was a soft side to the scalability concern, and I know there are more aspects to knowing an enterprise product when you see one. Those may show up in a future post.