s developers, we often want to jump right in and start coding; it is our passion, and often our most comfortable way of looking at the projects we deal with. As a project manager, though, I cringe when I see developers on my team start with this code-centric approach to projects (although, in all honesty, I have been guilty of it myself). With certain technologies, however, there are concerns that must be addressed well in advance of implementation, or you run the risk of having issues take over that are outside of our sphere of control.

I noticed this when my company, Cubistix, began working on a project using Microsoft MapPoint Location Server (MLS).

First, let me begin by saying that the code necessary to location-enable your apps with MLS is relatively small. As a service, it is a big black box into which you pass authentication information and parameters, such as a mobile phone number, and it spits back latitude and longitude. The majority of the transaction is hidden from us?a couple of SOAP calls that are generated behind the scenes.

So what are these other issues that we encountered on our way to implementing this new technology from Microsoft? And, of greater importance, what advice can I give to a project manager involved in developing a project with MLS?

Concerns About Supporting Technology
First, aside from the obligatory Internet protocols and cell-phone service, MLS relies on three main technologies in order to run in an optimal fashion: Microsoft Location Server, MapPoint Web Service, and SSL secure connection. Of the three, SSL is probably the most important piece of the puzzle, as MLS will only communicate over a trusted connection. This can be an important point to emphasize to your customer: All information passed to and from MLS is always encrypted, in order to protect the privacy of the subscriber. Only information necessary to perform the request is exchanged, and only the results are returned.

So far, things are pretty straightforward. Sign up for the services, get a root certificate for mls.mycompany.com, and everything is ready to go?you can begin coding.

Well, not just yet.

That is only your side of the equation. The other side is enabling the service on your mobile telecomm carrier’s side. As of the writing of this article, only one provider is available in the US, and one in Canada, though this will change in the coming year if all goes well and carriers see a benefit to providing the service?and Microsoft is working on them to see that. Generating demand to justify this telecomm investment, on the other hand, is up to us in the development community. We do this by creating the applications that our customers need.

From my experience with these and other carriers that are considering offering this service, the process for enabling the tracking of the cell phones (called provisioning) is pretty much the same. It involves contracts signed by both the company and the owner of the cell phone (who may or may not be the same entity) stating that they are allowing the cell phone, and hence the user of the phone, to be tracked using this service. After these agreements are in place, the phones are usually trackable within a few days. Though the service will work with just about any phone manufactured today, it is important that the phone have the 911 chip installed, otherwise it won’t be able to be tracked.

In the Real World: Pechter’s JIT Customer Service
Pechter’s is a 116-year-old baking company located in Harrison, NJ, with over 1200 different bread products, servicing commercial establishments including restaurants, diners, hospitals and schools in the greater New York, New Jersey, Pennsylvania and Delaware areas. The company has 75 delivery routes and $55 million in annual sales. The company has built itself and its reputation on its ability to deliver exemplary customer service; however, the cost of maintaining that level of service was beginning to escalate. We saw MLS as being a great solution to help them maintain and improve their level of service, while also reducing costs.

When my company, Cubistix, agreed to create a Just-In-Time customer service application for Pechter’s, MLS was just entering beta stage. We knew that we would encounter some bumps in the road, as with any product in beta. Steve Lombardi, MapPoint’s Technical Evangelist, and his crew were instrumental in getting us through the setup process, and stepping up whenever we encountered issues outside of our control. We learned a lot during this project, some good, some bad, and some ugly. As with many projects, issues appeared in areas we never anticipated, but with some careful forethought, developers should be able to get avoid them.

The Good: Surprisingly Simple Coding
My team and I were very surprised at the ease of integration with the MLS service. After the initial setup of the server and getting our root certificate squared away, the actual use of the service is simplicity itself. Once these basics were in place, it was a matter of coding a SOAP call to broker a request for location from the phones. We used Visual Studio to code our application, and with a handful of code, we were able to start passing information to and from MLS without any problems. Using simple API calls and a simple connect string that contains our credential information, and number of the phone we wanted to track, we were able to get back the location of trucks in proximity of a customer in need. The architecture is “connect-and-forget,” with any changes being made on the client side through the use of application variables.

Using the GPRS network to track the phone has a couple of advantages over their GPS counterparts. One is that the GPRS cell phone requires less power to sync up with the satellites and thus will last longer on a battery charge. The other is that GPRS networks are more forgiving in environments where clear line-of-sight to the sky can be an issue, such as in large cities, tunnels, and certain types of vehicles like step trucks and tractor trailers.

The Bad: Newbie Providers, Unwarranted Privacy Concerns
Initial setup for the server was difficult due to the lack of documentation in the beta product when we first started implementation; but as I stated earlier, the MapPoint team was very helpful and got us up and running when we ran into issues. The documentation has since been completed and is very thorough, with plenty of code examples to help developers who are working with the service for the first time. I will tell you that it helps to have more than a passing familiarity with setting up SSL certificates, IIS and Active Directory.

Coordination with service providers can be tricky as well. We discovered that the majority of our delay was due to our wireless provider attempting to catch up with what we were doing. In fact, we had our entire project completed before they had their end set up. Again, Microsoft helped to smooth out these issues, but I think that our service provider did not know what to make of MLS or what benefit could be derived from the service. In recent conversations I have had with Sprint, now that they have become familiar with it, they have assured me of their commitment to location-based services. No doubt you will run into carrier issues; but remember that the procedures for provisioning will be similar to what I have mentioned before.

Which leads me to the legal issues associated with the service. I know that prospective clients that we have spoken to are concerned about the ability to track individuals, and the whole Big Brother aspects of the technology. We encountered these issues and concerns when we started our implementation at Pechter’s. The first thing that I assured my clients is that any phone that will be tracked has to have consent in writing from the owner of the phone in order to be tracked. Without this, the wireless provider will not provision the phone for tracking, so the answer is “No, your employer, spouse, friend, etc. cannot track you without your consent. Period.” From the employer side, if you are allocating a phone to your employees specifically for use with MLS, consent can be implicit by accepting the phone or having a clause in the employment agreement.

Of course, since the ability to track no longer works when the phone is shut off, an employee needs only turn off the phone at the end of the business day in order to no longer be tracked.

The Ugly: Accuracy (For Now, Anyway)
We did encounter one particular issue with our application’s operation: the accuracy of the GPRS network. Since location is approximated based on the attenuation of signal between cell towers, there can be several factors that cause the location to be thrown off, including buildings, weather, density of towers in a given location, and power of the phone. The carrier we were using did not make any accuracy guarantees, as Sprint is said to provide, so we were a little surprised at how far off some of our readings were. The worst case resulted in a difference of almost two miles from actual location and reported location.

This was not so bad with our particular application, as we were looking in proximity of a customer rather than trying to pinpoint a driver. The accuracy of these devices will be getting more and more precise as the technology progresses; I am sure location accuracy will soon approximate that of a non WAAS GPS device.

The technology itself is very straightforward, and thanks to Microsoft, it is affordable and easy to use. The determining factor for the success of this product will be the level of commitment from wireless operators to expose their location API to Microsoft.

My advice is not to worry as much about the coding and usage of MLS itself, the setup of the service and calls to the API are relatively straightforward, but rather to look at the managerial and business roadblocks that can crop up. By focusing on these things that are outside of the scope of the development plan, you can save yourself quite a few headaches.