The
Dumb Pipe has Graduated, and it has a PhD
A bit more than a year ago in another Directions Magazine article entitled Mobilizing Existing Users of Geographic Information - The Dumb Pipe Approach for LBS, I wrote about an LBS value-chain debacle that had little hope of realizing a fruitful future unless industry players matured to focus solely on individual core competencies.Shakeout is a must in any dynamically evolving market.I still contend that it's impractical for any one entity to handle all specialties and institute a business model that seeks to own all components of the LBS value-chain.When I wrote the Dumb Pipe piece, I was irritated by a lack of market development, so I criticized LBS business models, citing that most involved needed mind shift and systemic change if we were to fully fulfill wireless location-based bliss in the small- to medium-sized and larger enterprise IT marketplace.I've since been schooled - and how!
Indeed, I have learned exciting developments are well underway that enable wireless carriers to intelligently expose telecom network capabilities to the larger enterprise IT community through service delivery frameworks and Web services.When combined with other GeoSpatial Web services through a common IT middleware bridge, enterprise IT developers have access to everything they need to develop location-based applications.This approach is not dumb; it's intelligent, mature, and encourages each specialist value-chain enabler to focus on core competencies with the shared goal of best supporting the IT community.
Smart Communities, Smart Pipes, Smart Business
So, how are wireless providers able to expose telecom network capabilities and what does this mean to the average IT developer? The Parlay Group deserves a lot of credit for realizing the concept.The Parlay Group is a multidisciplinary organization with member constituents representing a veteran group of experienced telecom and IT professionals. Parlay Group members contribute mature thought leadership, look at all the pieces and parts in Telecom and IT, and focus mission vision on defining Web services specifications designed to extend next generation wireless network capabilities to the larger IT world.It seems Parlay has found a sweet spot as well - trends indicate that "there is a demand for enterprise applications to exploit the capabilities of the telecom network," according to Gartner.
One of The Parlay Group's missions is simple - develop standard SOAP/XML Web services specifications that provide an abstraction layer for IT developers to code against Telecom network elements.Parlay provides a way to open the Telecom network in ways not available before.Previously, developers were forced to develop one-off hacked applications that interfaced directly to intelligent network (IN) elements like an MPC/GMLC, SMSC, MMSC, WAP-GW, etc., through proprietary telecom protocols not well known within the IT community.Parlay assumes most IT developers don't care to know about Telecom protocols in each of these specialized IN elements.Therefore, from inception, Parlay's goal was to provide the additional abstraction layer designed specifically for IT developers. Atop a control plane, Parlay Gateway resides an additional layer and suite of Telecom Web service SOAP/XML APIs for presence, location, messaging, and call routing - among others.
Telecom Web Services and GeoSpatial Web Services within Common IT
When one thinks about combining Telecom Web Services with GeoSpatial Web Services, along with other IT systems, the possibilities are endless and not limited to any one industry vertical.For example, imagine a local HVAC (Heating, Ventilation, and Air-Conditioning) provider in your region.They have customers who may occasionally report heating and A/C problems that require field visits to correct a malfunction.Let's imagine the HVAC customer issues a customer service request over the phone through a call center or on the HVACs customer Web portal.The customer would likely inform the HVAC company of the problem, describe the nature of the issue, provide their address, etc.Once the HVAC's CRM/ERP system receives the customer service request, the CRM/ERP system would typically create a trouble-ticket work order record for the customer and the customer's address.The address needs to be geocoded.
At this point, the HVAC's IT application would likely initiate a GeoSpatial Web services request to Geocode the customers address.Once the address is geocoded, the HVAC's IT application would likely need to determine if there is an available field worker to respond to the work order and correct the issue.This is when the IT application would initiate a Telecom web services Presence request to see which workers are available.Upon determining which workers are available, the IT application would then logically make a Location request to locate the closest available field worker(s) to respond to the customer service request work order.
Upon locating field workers within a given Proximity of the customers address, perhaps worker locations are displayed in the back office dispatcher Mapping console.In an automated scenario, the IT application could automatically detect the nearest available worker, where upon the application could trigger a message to be sent to the mobile worker.This process would use the Messaging web service to send short and multimedia messages to the field workers phone.The message could feasibly include the work order number, the nature of the problem report, the customer's address, Maps, and Routing Directions from the worker's current location to the customer's address.
Once the field worker arrives at the customer address, perhaps the field worker's phone sends a Message to the back office to automatically inform the dispatcher that he/she has arrived at the customer site.The notification could be handled by a Geofence if the customer's address is defined by a polygon.Also, when the field worker departs the customers address, another alert Message could be triggered based on a Geofence, (i.e.a point-in-polygon operation; a geographic zone (polygon) defined around a point or area of interest; used specifically within mobile tracking systems to trigger outbound or inbound alerts/messages when mobile stations enter or depart a geographic zone), and delivered to the back office to notify the dispatcher that the field worker has departed the site.For post-processing, location-stamped arrival and departure time record logs could be used for internal employee timesheet auditing.The log records could also be used to resolve customer disputes, proving or disproving if field workers were onsite at hours reported by the employee or the customer.
Click image for larger view.
The HVAC example is one applying combined use of Telecom Web services and GeoSpatial web services within an enterprise IT environment.All three systems contribute special functionality all working together harmoniously in an IT framework to solve specific business mobility problems.The HVAC field-force automation example can be extended to any business that has standard IT, geospatial technology, and access to Telecom Web services.But wait, there's that frustrating issue again - access.
IT Leaders Bring It All Together
Over the last couple years at this forum, there has been discussion, debate, and advertorials describing how to acquire mobile location data from wireless carriers.However, the above Telecom Web services overview clearly illustrates that there's more to a location-based application than location alone.Indeed, mobile location is one feature of the Telecom network, but as described with the HVAC use-case example, additional Telecom Web services are equally critical for an IT application to fully exploit Telecom network capabilities.So, what about these additional Telecom Web services beyond location, and how can they be accessed by IT developers?
I've discovered at least one commercially available IT product that allows developers to access all Telecom Web services supported by Parlay - IBM WebSphere Studio Application Developer (WSAD).WSAD is pre-integrated with Parlay-based Telecom Web services APIs as well as GeoSpatial Web services APIs.WSAD provides IT developers with a common development environment to build J2EE location-based applications....Use this common J2EE development environment, deploy it on J2EE IT infrastructure, and you now have a complete and common development and runtime package to telecom-enable your IT systems.A bonus is that J2EE infrastructure is also integrated with other open IT systems like Web Portals, CRM, and ERP - all through the same service-oriented architectures and delivery frameworks that Telecom Web services and GeoSpatial Web services are built upon.
Click image for larger view.
For the enterprise CIO, a
common middleware enterprise service
bus (ESB) supporting Web services delivery frameworks is promising
because it means
the core IT system has increased systems shelf-life, there is less IT
silo overhead,
and there is support for open environments
needed to extend the whole corporate IT system as business challenges
or
opportunities are encountered.For the enterprise developer, the
architecture,
and its supporting pick-and-choose toolbox means they can access
a plethora of different specialized Web services for application
development.
Pre-integrated Packages for IT Developers
Again, common developer environments or SDKs help developers build and deploy location-based applications (for sale or internal use) all within one consolidated environment.Within this architecture, developers don't necessarily have to maintain each special system themselves.Also, each specialty Web service is simple to use - particularly the GeoSpatial and Telecom portions.For these Web services, developers can feel comfortable knowing their application needs are being served by the core competencies of service providers who deliver on-demand information as needed.This allows developers to focus on the main processes and business logic of the application, rather than on the intricacies of specialty systems that augment the whole.
While Telecom Web services and GeoSpatial Web services WSDLs are easy to use natively, a common SDK like WSAD makes it easier.With WSAD, developers' plug-in pre-integrated Parlay Telecom Web services WSDL snippets into a coding studio where they sketch an application such as the one below.
Click image for larger view.
The same is true for the GeoSpatial Web services WSDL snippets (shown below).
Click image for larger view.
The result is simple - a Telecom Web services SOAP call for Location whereby the application subsequently makes a GeoSpatial Web services Map call.Viola - within minutes, the developer has built a nice "phone finder" location-based application.
Click image for larger view.
This is a rather unimaginative example of combining Telecom Web services with GeoSpatial Web services, but it is used here to demonstrate the idea of accessing multiple Web services within one common development environment.I'll leave the creativity and application ideas to developers!
Core Competence Collaboration
I previously argued that in order for LBS to take off in the larger IT world, those involved in the LBS value chain needed to focus on core competencies rather than trying to serve every specialty through closed silos.First, wireless carriers are best at managing communications infrastructure, handling voice and data traffic that goes across it, and managing subscribers and bills in massive quantities.With Parlay, carriers now have the capability to be equally good at offering new application-level services to secure a new breed of customer that not only needs wireless voice and data, but one that also requires access to Telecom network resources for advanced IT application development. Second, IT vendors are best at integrating disparate business processes and systems across the enterprise to support partners, suppliers, and customers.IT middleware bridges bring all specialty systems together thereby allowing other value-chain players to focus on a single integration point rather than many. Finally, GeoSpatial vendors are best at building and managing spatial databases, offering engines to process spatial data, and providing options to deliver spatial information across multiple channels to enhance location-based communications, operations, and corporate decision making.
All three specialized systems are smart and strong individually, but smarter and stronger when combined.Shared knowledge often breeds genius; genius in turn generates discovery, opportunity, and growth.The Pipe has matured; the Pipe has graduated!
A bit more than a year ago in another Directions Magazine article entitled Mobilizing Existing Users of Geographic Information - The Dumb Pipe Approach for LBS, I wrote about an LBS value-chain debacle that had little hope of realizing a fruitful future unless industry players matured to focus solely on individual core competencies.Shakeout is a must in any dynamically evolving market.I still contend that it's impractical for any one entity to handle all specialties and institute a business model that seeks to own all components of the LBS value-chain.When I wrote the Dumb Pipe piece, I was irritated by a lack of market development, so I criticized LBS business models, citing that most involved needed mind shift and systemic change if we were to fully fulfill wireless location-based bliss in the small- to medium-sized and larger enterprise IT marketplace.I've since been schooled - and how!
Indeed, I have learned exciting developments are well underway that enable wireless carriers to intelligently expose telecom network capabilities to the larger enterprise IT community through service delivery frameworks and Web services.When combined with other GeoSpatial Web services through a common IT middleware bridge, enterprise IT developers have access to everything they need to develop location-based applications.This approach is not dumb; it's intelligent, mature, and encourages each specialist value-chain enabler to focus on core competencies with the shared goal of best supporting the IT community.
Smart Communities, Smart Pipes, Smart Business
So, how are wireless providers able to expose telecom network capabilities and what does this mean to the average IT developer? The Parlay Group deserves a lot of credit for realizing the concept.The Parlay Group is a multidisciplinary organization with member constituents representing a veteran group of experienced telecom and IT professionals. Parlay Group members contribute mature thought leadership, look at all the pieces and parts in Telecom and IT, and focus mission vision on defining Web services specifications designed to extend next generation wireless network capabilities to the larger IT world.It seems Parlay has found a sweet spot as well - trends indicate that "there is a demand for enterprise applications to exploit the capabilities of the telecom network," according to Gartner.
One of The Parlay Group's missions is simple - develop standard SOAP/XML Web services specifications that provide an abstraction layer for IT developers to code against Telecom network elements.Parlay provides a way to open the Telecom network in ways not available before.Previously, developers were forced to develop one-off hacked applications that interfaced directly to intelligent network (IN) elements like an MPC/GMLC, SMSC, MMSC, WAP-GW, etc., through proprietary telecom protocols not well known within the IT community.Parlay assumes most IT developers don't care to know about Telecom protocols in each of these specialized IN elements.Therefore, from inception, Parlay's goal was to provide the additional abstraction layer designed specifically for IT developers. Atop a control plane, Parlay Gateway resides an additional layer and suite of Telecom Web service SOAP/XML APIs for presence, location, messaging, and call routing - among others.
- The Presence Web service allows an IT application to determine if a phone is on, off, in a voice session, or in a data session.
- The Location Web service allows an IT application to request the latitude/longitude coordinates of a phone.
- The Messaging Web service allows an IT application to send short and multimedia messages to a phone.
- The Call Routing Web service allows an IT application to intelligently route a voice call to the closest available phone.
Telecom Web Services and GeoSpatial Web Services within Common IT
When one thinks about combining Telecom Web Services with GeoSpatial Web Services, along with other IT systems, the possibilities are endless and not limited to any one industry vertical.For example, imagine a local HVAC (Heating, Ventilation, and Air-Conditioning) provider in your region.They have customers who may occasionally report heating and A/C problems that require field visits to correct a malfunction.Let's imagine the HVAC customer issues a customer service request over the phone through a call center or on the HVACs customer Web portal.The customer would likely inform the HVAC company of the problem, describe the nature of the issue, provide their address, etc.Once the HVAC's CRM/ERP system receives the customer service request, the CRM/ERP system would typically create a trouble-ticket work order record for the customer and the customer's address.The address needs to be geocoded.
At this point, the HVAC's IT application would likely initiate a GeoSpatial Web services request to Geocode the customers address.Once the address is geocoded, the HVAC's IT application would likely need to determine if there is an available field worker to respond to the work order and correct the issue.This is when the IT application would initiate a Telecom web services Presence request to see which workers are available.Upon determining which workers are available, the IT application would then logically make a Location request to locate the closest available field worker(s) to respond to the customer service request work order.
Upon locating field workers within a given Proximity of the customers address, perhaps worker locations are displayed in the back office dispatcher Mapping console.In an automated scenario, the IT application could automatically detect the nearest available worker, where upon the application could trigger a message to be sent to the mobile worker.This process would use the Messaging web service to send short and multimedia messages to the field workers phone.The message could feasibly include the work order number, the nature of the problem report, the customer's address, Maps, and Routing Directions from the worker's current location to the customer's address.
Once the field worker arrives at the customer address, perhaps the field worker's phone sends a Message to the back office to automatically inform the dispatcher that he/she has arrived at the customer site.The notification could be handled by a Geofence if the customer's address is defined by a polygon.Also, when the field worker departs the customers address, another alert Message could be triggered based on a Geofence, (i.e.a point-in-polygon operation; a geographic zone (polygon) defined around a point or area of interest; used specifically within mobile tracking systems to trigger outbound or inbound alerts/messages when mobile stations enter or depart a geographic zone), and delivered to the back office to notify the dispatcher that the field worker has departed the site.For post-processing, location-stamped arrival and departure time record logs could be used for internal employee timesheet auditing.The log records could also be used to resolve customer disputes, proving or disproving if field workers were onsite at hours reported by the employee or the customer.
Click image for larger view.
The HVAC example is one applying combined use of Telecom Web services and GeoSpatial web services within an enterprise IT environment.All three systems contribute special functionality all working together harmoniously in an IT framework to solve specific business mobility problems.The HVAC field-force automation example can be extended to any business that has standard IT, geospatial technology, and access to Telecom Web services.But wait, there's that frustrating issue again - access.
IT Leaders Bring It All Together
Over the last couple years at this forum, there has been discussion, debate, and advertorials describing how to acquire mobile location data from wireless carriers.However, the above Telecom Web services overview clearly illustrates that there's more to a location-based application than location alone.Indeed, mobile location is one feature of the Telecom network, but as described with the HVAC use-case example, additional Telecom Web services are equally critical for an IT application to fully exploit Telecom network capabilities.So, what about these additional Telecom Web services beyond location, and how can they be accessed by IT developers?
I've discovered at least one commercially available IT product that allows developers to access all Telecom Web services supported by Parlay - IBM WebSphere Studio Application Developer (WSAD).WSAD is pre-integrated with Parlay-based Telecom Web services APIs as well as GeoSpatial Web services APIs.WSAD provides IT developers with a common development environment to build J2EE location-based applications....Use this common J2EE development environment, deploy it on J2EE IT infrastructure, and you now have a complete and common development and runtime package to telecom-enable your IT systems.A bonus is that J2EE infrastructure is also integrated with other open IT systems like Web Portals, CRM, and ERP - all through the same service-oriented architectures and delivery frameworks that Telecom Web services and GeoSpatial Web services are built upon.
Click image for larger view.
Pre-integrated Packages for IT Developers
Again, common developer environments or SDKs help developers build and deploy location-based applications (for sale or internal use) all within one consolidated environment.Within this architecture, developers don't necessarily have to maintain each special system themselves.Also, each specialty Web service is simple to use - particularly the GeoSpatial and Telecom portions.For these Web services, developers can feel comfortable knowing their application needs are being served by the core competencies of service providers who deliver on-demand information as needed.This allows developers to focus on the main processes and business logic of the application, rather than on the intricacies of specialty systems that augment the whole.
While Telecom Web services and GeoSpatial Web services WSDLs are easy to use natively, a common SDK like WSAD makes it easier.With WSAD, developers' plug-in pre-integrated Parlay Telecom Web services WSDL snippets into a coding studio where they sketch an application such as the one below.
Click image for larger view.
The same is true for the GeoSpatial Web services WSDL snippets (shown below).
Click image for larger view.
The result is simple - a Telecom Web services SOAP call for Location whereby the application subsequently makes a GeoSpatial Web services Map call.Viola - within minutes, the developer has built a nice "phone finder" location-based application.
Click image for larger view.
This is a rather unimaginative example of combining Telecom Web services with GeoSpatial Web services, but it is used here to demonstrate the idea of accessing multiple Web services within one common development environment.I'll leave the creativity and application ideas to developers!
Core Competence Collaboration
I previously argued that in order for LBS to take off in the larger IT world, those involved in the LBS value chain needed to focus on core competencies rather than trying to serve every specialty through closed silos.First, wireless carriers are best at managing communications infrastructure, handling voice and data traffic that goes across it, and managing subscribers and bills in massive quantities.With Parlay, carriers now have the capability to be equally good at offering new application-level services to secure a new breed of customer that not only needs wireless voice and data, but one that also requires access to Telecom network resources for advanced IT application development. Second, IT vendors are best at integrating disparate business processes and systems across the enterprise to support partners, suppliers, and customers.IT middleware bridges bring all specialty systems together thereby allowing other value-chain players to focus on a single integration point rather than many. Finally, GeoSpatial vendors are best at building and managing spatial databases, offering engines to process spatial data, and providing options to deliver spatial information across multiple channels to enhance location-based communications, operations, and corporate decision making.
All three specialized systems are smart and strong individually, but smarter and stronger when combined.Shared knowledge often breeds genius; genius in turn generates discovery, opportunity, and growth.The Pipe has matured; the Pipe has graduated!
From Our Homepage
Saying Farewell to an Amazing Journey
Communicating with Maps
Is There a GIS Career Ladder?
What does it mean to be geospatially smart? Series
Ways Real Estate and Property Developers Utilize Melissa GeoData for Data-Driven Decisions
Unlocking Value From Daily Satellite Imagery and Insights
Maximizing the Value of Your Address Data with Geo Addressing
How Indoor Mapping Enhances the Security of Smart Buildings
Look Ahead: AI, Location Intelligence and Efficiency
Collaboration Takes on Sea Level Rise & Dynamic Technology Environments
Brownies for Brownfields
Has Everything Been Mapped Already?
How Is Data Literacy Changing in an Artificial Intelligence Landscape
Portfolios for GIS Professionals: More Than Just Maps
How to Create a Distance Matrix in QGIS - A Step-by-Step Guide
7 Ideas for Bringing GIS into the K-12 Classroom
The Geography of Movement