For what purpose was enterprise push email designed?
February 6, 2013 2:01 PM Subscribe
Would you agree that enterprise push email technology was primarily designed to push email from a single enterprise mailbox (unless you happen to work for multiple enterprises)?
At my place of employment we run Exchange and most folks with mobile devices have separate, dedicated "mobile mailboxes" that are dedicated to mobile use. They essentially use their devices as pagers. This is typical across the medical staff and prior to the push-email setup, the medical staff used alpha-pagers, so this is a logical continuation of that setup. They want to be woken up in the middle of the night if it's important, but they don't want every email flowing into their phone.
As of late, most new managers that start in the organization immediately request the ability to synchronize with their primary mailbox, often eschewing the use of a separate dedicated mailbox. Our sysadmin finds this unfathomable.
I would argue that this is the most common "use case" of enterprise push email: retrieving any message you wish, getting notified of new email messages in your single solitary mailbox. I think it's beyond debate and feel sheepish posting this, but it's hard to find supporting evidence of what I think is a pretty obvious conclusion: of course this is what BlackBerry Enterprise Server was designed to do, along with other technologies like Good and ActiveSync, and most users are interested in retrieving all of their corporate email. I personally do this, using rules to move the less-important email to other folders so I don't get notified when they arrive.
Our sysadmin is adamant that this is foolish, I suspect because he personally doesn't like this approach himself, and because "we've always done it the other way." These might be uncharitable interpretations but I just don't get it.
I think he's behind the times and he's literally accused me of "thinking I'm god" when I explained that this technology was really intended for syncing with a "primary mailbox" and not some extra dumping ground.
To be honest I want something to be able to point at, and I think the internet might benefit from this thread if future people in my role are forced to question their sanity about such a simple concept.
posted by aydeejones to computers & internet (7 answers total)
Within the framework of your organization, you need to do the following:
1. Identify who is responsible for defining and implementing IT projects
2. Identify the business value of the use case you have identified
3. Work with the person or group identified in step (1) to plan out the implementation of step (2)
4. Step back and let it happen.
A "sysadmin" should be someone who implements IT policy, not the person who determines it. If your IT group is small enough, you might have only one person that wears all these hats. In that case, you need to approach your "sysadmin" not on the basis of system administration, but on the basis of solving this problem.
It may be the case that it is cost-prohibitive to implement the change you want. But you need to approach the problem from a planning perspective, rather than some kind of abstract philosophy argument combined with name calling. If you dig deep enough, I can almost guarantee you that any "enterprise" product was designed to make the company designing it a shit-ton of money while poorly appropriating some more idealistic design.
posted by b1tr0t at 2:10 PM on February 6 [1 favorite]