Stories of Enterprise Mobile Development
Sometimes when I hear stories of software development, I’m reminded of a scene from Monty Python and the Holy Grail. (NOTE: This is probably not safe to play at work or in front of anyone bothered by fake blood.) The humor in this skit comes from the fact that the black knight is completely unrealistic about the extent of his injuries. For me, the expression “just a flesh wound” is a shortcut for something really painful that you underplay as minor. Now the flip side of this is that many valuable things require a struggle. In many cases, the difference between the two comes down to perspective. So here’s a little story of mobile development that, given a few years to look back on, falls into the category of “just a flesh wound.”
Many Moons Ago
Around eight years ago (before any consumers had an iPhone), I was working on a project to make a BlackBerry app. At that time, BlackBerry was the dominant enterprise mobile solution, and our customers were asking for a mobile experience for our server product. At the time, we didn’t have any BlackBerry coding experience in our internal development staff, so we found an external partner.
As with many projects, the beginning was marked by enthusiasm. We had some nice mockups of the user interface (nice for that point in time, horribly ugly by the standards of today). The initial development work went pretty quickly. The partner kept giving updates on functionality getting completed.
It was when I first installed a beta version of the app that I knew we might be in for some pain. The app didn’t work. After a bit of chatting with the partner, it looked like the missing ingredient was an APN Setting. You see, back at this point in time, some applications required the user to enter a set of information for the app to make certain kinds of connections. I searched the internet for the details required by my carrier (yeah, APN settings were all carrier-specific), navigated through the BlackBerry settings menus, and entered it. Victory! The app worked! But with years of experience working with end users and entering data, I was already feeling a little queasy.
It Took Awhile
Still we pressed ahead with development and got to the point where we could let customers test. The app didn’t work. Had they put in the APN settings? Had they entered them correctly? We confirmed APN settings were not the problem. So what could it be? Well, as it turns out, BlackBerry Enterprise Servers had several settings that controlled how authentication was handled with backend systems. OK – so just change those settings. Not so fast… those settings might affect other things running on the phones… So now we needed to get a customer to try making these changes on a production system that delivered all the mobile email to their executives. Yeah, it took a while.
But after a bit of testing and adjusting, it worked! Well, it worked for some customers. As it turns out, some other customers had implemented extra layers of security and required any app on the phone to send a certificate back to the server to provide two-factor authentication. And the process of making that work required more actions by each end user. At the end of the day, companies and end users mostly didn’t find it worth the effort to go through all the setup.
Moral of the Story
I think there are two takeaways from this story. First, enterprise mobility has come a long way. We learned a lot from this experience and all the work we’ve done in the past eight years. This is why we built Sitrion ONE to handle mobility end-to-end from backend systems through secure access and out to a great mobile experience. Second, it sometimes helps to share these stories. When you hear what others have gone through, it can help you avoid mistakes and put things into perspective.
So whether your mobility journey is a challenging but fruitful struggle, or it’s actually “just a flesh wound,” I’d love to hear about it. Ping me or post your stories in the comments.