Many GIS programs stem from the need to solve specific
business problems. However, in most businesses the benefits and
applications of location-aware technology stretch into numerous
operational areas. In spite of this, GIS programs rarely plan
effectively for expanding organizational adoption beyond their
initiative's initial scope. Employing a Service-Oriented Architecture
(SOA) approach to GIS development, specifically exposing your GIS
capabilities as Web services, will allow you to create a flexible and
extensible GIS that can quickly respond to changing and future
organizational needs.
Fortunately, most GIS software vendors already offer some level of support for exposing GIS capabilities as Web services, either out-of-the-box or with minimal customization. While this significantly decreases the technical challenges associated with this approach, there are still numerous organizational and communication considerations to keep in mind.
Jargon-Free Definitions
Defining SOA is not as simple as it may seem. There are as many definitions of SOA as there are IT vendors and service providers. One of the definitions we favor is:
"SOA is the underlying structure supporting communications between services." (www.techtarget.com)
There is nothing technology-specific in this definition. It is helpful to view SOA in this way to avoid getting caught up in the technical jargon. Therefore, taking an SOA approach simply means that one goal of your system is to provide an underlying structure that will allow your GIS services to communicate with other services.
For example, you may want an address-location service to communicate with a marketing service so that your organization can target its direct mail campaigns to addresses within a specific geographic region. You probably have some form of this communication in place already - although it is most likely driven by emails or phone calls from marketing to your GIS group, as opposed to being driven by a Web based system.
That brings us to the next term: Web services.
A Web service is any service that is made available from a Web server for users or other Web-connected programs. For example, Google Maps represents a Web service that makes available an "address location" service.
Getting beyond the technical jargon associated with SOA and understanding the practical application of relevant SOA concepts can be tricky. However, we have found that by adhering to four simple steps you can greatly enhance your chances of deploying a highly valuable, highly extensible, Web-services-based GIS.
As with any large information system program, you will need to engage many areas of the organization to ensure your program delivers real value to the business. An appropriate starting point is conducting interviews with key stakeholders across your organization's operating units to learn about their biggest problems. This will help you identify your organization's most critical issues and discover new uses for your GIS beyond those initially defined.
Engaging the entire business also means engaging your IT organization (if your GIS and IT departments are different). This is particularly important when employing an SOA approach, as your IT group may already have an established service governance structure to which all Web service initiatives must adhere.
When informing the business of your service-oriented approach you should exercise caution as the term SOA can have both negative and positive connotations. You may be met with skepticism by those who view SOA as a buzz word with little substance. You may also be met with unbridled enthusiasm by those who believe it is the solution to all IT problems. Keep in mind, though, that the latter is not necessarily better, as having a knowledgeable skeptic involved in your program has its advantages. Regardless of how you think the business will receive the news, if you are not an expert in SOA make sure you have a partner who is.
When discussing your approach with the rest of the business, make sure you are open to discussing all of its issues. This is not to say that you should allow your project scope to get out of control, but a thorough understanding of what the business really wants will help you see the bigger picture, even if you cannot address all the issues right away. You should consider not only the services that other departments want you to provide but also the services provided by other departments. This will allow you to get a feel for potential future cross-service communication needs.
Define your services
Now that you have engaged the business and captured all the various business services that relate to (or may someday relate to) GIS, you can go about the task of identifying which services your program will deliver. Before you delve into the technology aspects of SOA, you must determine the specific subset of business services that your GIS program plans to expose as Web services. Some examples might be geo-tagging, map presentation, address location and address cleansing. It seems simple enough, but there is a tendency to over complicate the issue by worrying too much about the technology. To simplify the process, consider the following:
For the latter, if, from time-to-time, you receive requests to identify the location of existing and potential customers, then you need to determine whether the volume and value of these requests warrants a technology solution or if the current person-to-person communication method is sufficient.
By clearly defining a subset of services that provide value to the business and fall squarely into the realm of GIS you can confidently embark on the development and exposure of your GIS capabilities as Web-services.
Expose your services
Once you have your GIS services defined, you need to allocate them across the key applications you intend to build; prioritization is a must. Building a few key applications that provide immediate and sustainable benefit to the business will give you more time to focus on maintaining a high quality system structure and data set. By highlighting your most used or valuable GIS features, you can peak interest and garner support for the ongoing aspects of your program while still providing immediate value to the business.
You should develop your key applications using an SOA that allows you to expose a core set of GIS services. This has a number of intrinsic benefits. Integration expenses associated with your GIS will be greatly reduced if your services are based on open standards – as most Web services are - and your organization's greater IT environment can leverage those services – as most IT environments can. The continually evolving needs of the business will also benefit from the ability to reuse existing services to create new or composite services.
Exposed services mean that anyone in your organization can use your core GIS services in any number of ways. For example, a marketing department could apply location-aware technology to consumer data to identify and focus on geographic regions with the highest propensity to buy.
Communicate and collaborate
It is critical to let the business know what services are available and how it can use them. To this end, your GIS program plan should include the development of robust documentation and associated communications.
Create "GIS service rulebooks" for both the layperson and developer that explain how to use and interact with your services. For the layperson, this may be something as simple as a brief description of each service along with current and potential uses. For the developer, the rulebook should be more detailed and should be written by someone close to the software development process. This developer rulebook should contain the data and service contracts as well as any relevant syntax or standards for using a service. If your enterprise already has a defined SOA governance structure, it is likely it will have an electronic service registry that requires this sort of information.
Communicate with other departments to let them know what is available, how it can be used and what your team can do to help.
Some potential uses that you may wish to communicate could grow from the initial phases of your program planning. For example, applications that you dropped from your GIS program due to budgetary or schedule constraints may be good items for another, non-GIS department to pick up. However, without the proper guidance, it is unlikely that these new applications will ever come to fruition. This is where collaboration comes into play. Although you may not lead the development of department-specific applications, you should still plan to be actively engaged in their development. Whether it's providing SME support to third-party developers or providing access to GIS service testing environments, the key is to actively engage and collaborate with your internal clients.
Conclusion
Many stumbling blocks associated with GIS programs can be avoided through proper communications across the organization. This is true of any large system implementation regardless of the development approach used. An SOA approach can expand the benefits of proper communication by allowing more streamlined communications between systems, as well as people and processes. By engaging all operational groups from the outset, defining and exposing your GIS services, and communicating your results, you will greatly improve your program's chances for both immediate and long-term success.
Fortunately, most GIS software vendors already offer some level of support for exposing GIS capabilities as Web services, either out-of-the-box or with minimal customization. While this significantly decreases the technical challenges associated with this approach, there are still numerous organizational and communication considerations to keep in mind.
Jargon-Free Definitions
Defining SOA is not as simple as it may seem. There are as many definitions of SOA as there are IT vendors and service providers. One of the definitions we favor is:
"SOA is the underlying structure supporting communications between services." (www.techtarget.com)
There is nothing technology-specific in this definition. It is helpful to view SOA in this way to avoid getting caught up in the technical jargon. Therefore, taking an SOA approach simply means that one goal of your system is to provide an underlying structure that will allow your GIS services to communicate with other services.
For example, you may want an address-location service to communicate with a marketing service so that your organization can target its direct mail campaigns to addresses within a specific geographic region. You probably have some form of this communication in place already - although it is most likely driven by emails or phone calls from marketing to your GIS group, as opposed to being driven by a Web based system.
That brings us to the next term: Web services.
A Web service is any service that is made available from a Web server for users or other Web-connected programs. For example, Google Maps represents a Web service that makes available an "address location" service.
Getting beyond the technical jargon associated with SOA and understanding the practical application of relevant SOA concepts can be tricky. However, we have found that by adhering to four simple steps you can greatly enhance your chances of deploying a highly valuable, highly extensible, Web-services-based GIS.
- Engage the entire business from the beginning.
- Define business services first, then translate them into potential Web services.
- Develop and expose your services through "showcase" applications.
- Communicate and collaborate to extend your GIS's capabilities.
As with any large information system program, you will need to engage many areas of the organization to ensure your program delivers real value to the business. An appropriate starting point is conducting interviews with key stakeholders across your organization's operating units to learn about their biggest problems. This will help you identify your organization's most critical issues and discover new uses for your GIS beyond those initially defined.
Engaging the entire business also means engaging your IT organization (if your GIS and IT departments are different). This is particularly important when employing an SOA approach, as your IT group may already have an established service governance structure to which all Web service initiatives must adhere.
When informing the business of your service-oriented approach you should exercise caution as the term SOA can have both negative and positive connotations. You may be met with skepticism by those who view SOA as a buzz word with little substance. You may also be met with unbridled enthusiasm by those who believe it is the solution to all IT problems. Keep in mind, though, that the latter is not necessarily better, as having a knowledgeable skeptic involved in your program has its advantages. Regardless of how you think the business will receive the news, if you are not an expert in SOA make sure you have a partner who is.
When discussing your approach with the rest of the business, make sure you are open to discussing all of its issues. This is not to say that you should allow your project scope to get out of control, but a thorough understanding of what the business really wants will help you see the bigger picture, even if you cannot address all the issues right away. You should consider not only the services that other departments want you to provide but also the services provided by other departments. This will allow you to get a feel for potential future cross-service communication needs.
Define your services
Now that you have engaged the business and captured all the various business services that relate to (or may someday relate to) GIS, you can go about the task of identifying which services your program will deliver. Before you delve into the technology aspects of SOA, you must determine the specific subset of business services that your GIS program plans to expose as Web services. Some examples might be geo-tagging, map presentation, address location and address cleansing. It seems simple enough, but there is a tendency to over complicate the issue by worrying too much about the technology. To simplify the process, consider the following:
- What tasks does your GIS team perform in the course of their normal business operations?
- What sorts of requests do you receive on an ad hoc or limited basis?
For the latter, if, from time-to-time, you receive requests to identify the location of existing and potential customers, then you need to determine whether the volume and value of these requests warrants a technology solution or if the current person-to-person communication method is sufficient.
By clearly defining a subset of services that provide value to the business and fall squarely into the realm of GIS you can confidently embark on the development and exposure of your GIS capabilities as Web-services.
Expose your services
Once you have your GIS services defined, you need to allocate them across the key applications you intend to build; prioritization is a must. Building a few key applications that provide immediate and sustainable benefit to the business will give you more time to focus on maintaining a high quality system structure and data set. By highlighting your most used or valuable GIS features, you can peak interest and garner support for the ongoing aspects of your program while still providing immediate value to the business.
You should develop your key applications using an SOA that allows you to expose a core set of GIS services. This has a number of intrinsic benefits. Integration expenses associated with your GIS will be greatly reduced if your services are based on open standards – as most Web services are - and your organization's greater IT environment can leverage those services – as most IT environments can. The continually evolving needs of the business will also benefit from the ability to reuse existing services to create new or composite services.
Exposed services mean that anyone in your organization can use your core GIS services in any number of ways. For example, a marketing department could apply location-aware technology to consumer data to identify and focus on geographic regions with the highest propensity to buy.
Communicate and collaborate
It is critical to let the business know what services are available and how it can use them. To this end, your GIS program plan should include the development of robust documentation and associated communications.
Create "GIS service rulebooks" for both the layperson and developer that explain how to use and interact with your services. For the layperson, this may be something as simple as a brief description of each service along with current and potential uses. For the developer, the rulebook should be more detailed and should be written by someone close to the software development process. This developer rulebook should contain the data and service contracts as well as any relevant syntax or standards for using a service. If your enterprise already has a defined SOA governance structure, it is likely it will have an electronic service registry that requires this sort of information.
Communicate with other departments to let them know what is available, how it can be used and what your team can do to help.
Some potential uses that you may wish to communicate could grow from the initial phases of your program planning. For example, applications that you dropped from your GIS program due to budgetary or schedule constraints may be good items for another, non-GIS department to pick up. However, without the proper guidance, it is unlikely that these new applications will ever come to fruition. This is where collaboration comes into play. Although you may not lead the development of department-specific applications, you should still plan to be actively engaged in their development. Whether it's providing SME support to third-party developers or providing access to GIS service testing environments, the key is to actively engage and collaborate with your internal clients.
Conclusion
Many stumbling blocks associated with GIS programs can be avoided through proper communications across the organization. This is true of any large system implementation regardless of the development approach used. An SOA approach can expand the benefits of proper communication by allowing more streamlined communications between systems, as well as people and processes. By engaging all operational groups from the outset, defining and exposing your GIS services, and communicating your results, you will greatly improve your program's chances for both immediate and long-term success.
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