In an article entitled, A Brief History of LBS and How OpenLS Fits Into the New Value Chain, I presented two architecture models or implementation strategies for location-based services within wireless carrier networks. Phase I LBS architecture models are early-generation approaches. This model assumes all spatially enabled applications residing outside the network firewall in the IP domain exploit the wireless network as a resource from which to collect location information and subsequently disseminate spatially processed wireless data. Phase II architecture models are fundamentally different in that they assume all spatially-enabling technology (MPC/GMLC, LES, and GIS) and the applications built with them are central to a wireless carrier's location-based systems.
With the Phase II LBS architecture model, wireless carriers own everything and make location-enabling technologies available to mass market, enterprise, and government application developers within the wireless application ecosystem. In this model, carriers manage their own applications, which they attempt to position as generic, one-size-fits-all, location-based solutions equally suited to mass market, enterprise, and government use. Some have argued that this approach is doomed and sets up wireless carriers and the LBS industry to fail (see It's the Applications, Stupid!, Williams 2003). An interesting thought exercise might be to compare the Phase II LBS models to the approaches of two major Internet service providers.
In the Internet world, Phase II LBS models may conceivably be analogous with how AOL positions itself, while Phase I models might be more similar to how UUnet (now MCI) positions itself in the marketplace. AOL offers not only connectivity and transport service through its own leased infrastructure, but also offers content and applications to its subscriber base. Conversely, MCI is just a data pipe available at wholesale. The AOL model may arguably be more attractive to consumers than the MCI model, but MCI's approach provides the same data transport services for those not concerned with flashy application offerings from AOL. The same can be argued in the wireless world with regard to Phase I and II LBS architecture models.
The Dumb Pipe Approach
The enterprise and government supergroup horizontals within the wireless
LBS application ecosystem represent the most immediate revenue-generating
potential for wireless carriers according to a recent Frost & Sullivan
study, North American Location-based Services Markets. While there
is potential for the Phase II LBS model to succeed for the mass market,
wireless carriers should exercise caution with this approach when addressing
enterprise and government LBS requirements. The premise that one-size-fits-all,
generic LBS applications will adequately meet the needs of enterprises
and governments is a fallacy, founded on false hopes.
Enterprises and governments have a long history of building their own location-based applications. In fact, enterprises and governments used conventional GPS, GIS, and wireless enabling technologies for their own applications long before the term "location-based services" was trendy. There are hundreds, if not thousands, of mature enterprise and government GIS applications currently serving geographic information and services to mobile users using the wireless network as a data pipe. Many of these applications are designed to serve a specific departmental function.
Enterprise and government corporate cultures consist of many disparate departments sometimes working independently of each other on different tasks. As such, interdepartmental data and application integration is sometimes difficult, and each isolated, disparate department may potentially develop independent compartmentalized systems that are not integral to the corporate system interoperability of the organization as a whole. Enterprises and governments have succeeded in synchronizing and homogenizing the synergetic efforts of each department by establishing corporate databases that organize various sets of department-specific information into holistically coherent data repositories. However, they have yet to develop generic GIS applications that suit the needs of the organization as a whole. It's common to find many applications that assume a niche focus for a specific department, though all are accessing a centralized spatial data repository.
Enterprise and government databases are proprietary in most cases, and
the information is considered sensitive. A wireless carrier will
never be allowed to host the data or the application, nor would they likely
have any interest in doing so. In these situations, I would argue
that the Phase I LBS model, which for the purposes of this article I call
the "dumb pipe approach," makes sense for everyone. In this model,
the enterprise or government agency owns its GIS application while carriers
provide location data and transport capabilities? no more, no less (see
Figure 1).
Figure 1: Dumb Pipe Approach
Again, this model is similar to MCI's approach. Like MCI, the wireless carrier functions as a pipe and provides two crucial features for the location-based application? access to handset location as well as capabilities to transport and deliver geographic information to enterprise and government mobile end users. So while it's not as flashy as the "I own it all" AOL model, it will work, and there is a demand for it. It's unlikely that wireless carriers will take full advantage of the enterprise and government market potential unless they consider Phase I LBS as an alternative, less flashy model with more advantages for enterprise and government users.
The Systems Integrator Role
It's natural for the seasoned wireless professional to question this
model and think to themselves, "This dumb pipe model means I have to do
custom integration for each LBS application." This is true and is
identifiably the only shortcoming of the model. However, there are
two alternatives a wireless carrier can explore. First is through
open Parlay/OSA and web Services APIs, which will enable enterprises and
governments to access network systems for application development.Alternatively,
carriers may explore a relationship with a systems integrator to handle
much of the integration work. While Parlay/OSA and Web services APIs
can conceivably streamline and speed up integration challenges, I would
argue that a systems integrator is still needed to fully integrate existing
enterprises and government systems with a carrier's wireless network (Figure
2).
Figure 2: Enterprise and Government Systems Integration With
Carrier Systems
The LBS industry as a whole has had a tendency to ignore the critical
role of a systems integrator. If the industry hopes to see enterprise
and government applications take -off, as Frost & Sullivan are optimistically
predicting, I'm confident that we will have to fill this void and adopt
the dumb pipe model.
Conclusion
The dumb pipe model is elegantly simplistic. There are hundreds of thousands of enterprise and government GIS applications, and their managers and owners would be more than willing to buy a phone that they can use as a location transceiver and spatial data receiver. Wireless carriers could entertain the possibility that their network can provide benefit to GIS application developers who already know what they are doing when it comes to enterprise and government applications. There is no need to reinvent the wheel.