|[an error occurred while processing this directive]|
SAP and Esri Collaborate on Enterprise Services
Since 1996, SAP and Esri have concurrently been both customers and partners of each other. Esri runs its business on SAP software, and SAP uses Esri components in its software. Together they have sold their integrated technology to many leading organizations in utilities, local and national government agencies, and businesses of all types. As a partner, Esri has helped SAP understand and define various GIS integration scenarios and approaches as technologies have evolved. Today, the emergence of the Web and its associated standards, together with the development of enterprise platforms from application suites, has created an environment where new applications can be easily created from the shared services of other applications in a loosely coupled, standards-based, and system-independent environment.
The ArcGIS platform enables the development of GIS visualization and geoprocessing services that can be easily used by other platforms, such as SAP NetWeaver, to create composite applications for a wide variety of industries and application areas. This article will discuss who uses GIS with SAP software today, the evolution of integration objectives and approaches, the emergence of composite applications, and what SAP and Esri are doing to take advantage of the new services-oriented world.
Who Uses GIS with SAP Software?
Organizations that integrate GIS with SAP software today include
All of these organizations have several things in common:
For most of these organizations, SAP is the repository and "go-to" system for all business data. Even where other specialized systems or applications exist, they are often tapped for data that gets added to the SAP repository for broad access and use by various SAP tools and components. Some of these specialized systems, such as GIS, are tasked with providing more than simple data feeds to a central repository of data. A GIS is an enterprise system in its own right, managing a broad set of spatial transactions in the same manner SAP manages nonspatial business transactions and must be integrated with SAP applications in more of a real-time, peer-to-peer scenario.
Evolution of Integration Objectives and Approach
Early integration efforts were narrowly focused and project specific, often arising because attribute data used in the GIS was moved into SAP applications, such as asset and work management. Getting to the data in SAP required the use of various proprietary SAP APIs, typically for read-only access to SAP data. These early applications were GIS-centric and primarily meant to reconnect GIS users to their relocated data sources.
Over time, GIS users were granted more rights to the SAP data, including the ability to create, change, and delete SAP data linked to GIS features, and SAP users were provided GIS views of their data and the ability to launch business process transactions from them, such as creating a work order. Java and .NET developers created integrated capabilities from scratch, building custom applications using simple and free connectors to meet narrow business requirements.
Most of these integrated applications barely scratch the surface of what is possible, displaying simple maps with little functionality beyond basic map navigation; feature selection; and the ability to execute simple, singular transactions. And because they are project specific, not much attention is given to how they fit within the broader IT landscape or system architecture. Reuse of code is typically not an integration design goal.
Once GIS is deployed, however, users soon discover that it can enhance business processes broadly across the enterprise and that simple access to SAP data for ad hoc mapping projects or simple transaction execution is not enough. They need access to real-time data coupled with advanced GIS visualization and geoprocessing functions composed into a task-oriented integration scenario. The integration needs to orchestrate several GIS and non-GIS transactions via two-way interaction embedded directly into the operational and analytic applications and processes that drive the business.
Today, more and more non-GIS users want access to GIS capabilities. Rather than using stand-alone GIS applications that require setup and training, business users want to leverage embedded GIS functionality as an integral part of their SAP application without shifting application contexts when moving from SAP-centric views to GIS views or from operational processes to analytical ones. GIS becomes assimilated by the primary SAP applications that users employ to do their jobs, and they may not even realize that they're using distinct GIS tools. This operationalization of GIS is the next wave in enterprise GIS integration.
To implement operational GIS pervasively across the enterprise, project-based point-to-point integration approaches must be replaced by flexible, reusable integration components that merge SAP and GIS transactions into task-level enterprise services. Users and applications tap into these services to deliver information and insights on demand, transforming SAP and GIS applications from stand-alone products to reusable, shared enterprise services that make integrated applications easier to build and use. These services become vehicles to launch operational processes and tasks from within a user's primary application, whether SAP, GIS, or a portal or dashboard to monitor key business events, trigger alerts and workflows, or execute tasks within operational applications.
The technology to implement composite applications is provided by both SAP and Esri in their respective platforms. Both companies embraced Web services and loosely coupled systems early on, support service-oriented architecture (SOA) standards, and provide coarse-grained and fine-grained services, as well as traditional object-level APIs, for developers who may know little about GIS or SAP or who may be experts in either application and need to create custom services. While much of the basic functionality of these applications has already been exposed as services, services to build and expose coarse-grained components for supporting specific business processes, roles, and tasks are in the early stages of development. Customers must still write custom code to orchestrate basic services or develop new ones.
As it turns out, orchestrating services or even writing custom services is the easy part. Far more difficult is understanding specific business processes well enough to define a set of supporting services that can be flexibly used to model not only the basic process but also the process variations customers employ to gain competitive advantage. To address this demanding task, Esri and SAP have again partnered to help define and deliver services for specific industry and cross-industry business processes, roles, and tasks.
SAP Labs in Palo Alto, California, initiated project Sagres in 2005 to identify areas within SAP that could be significantly enhanced through the better use or integration of GIS capabilities. SAP teamed with Esri and Esri Business Partner CyberTech Systems of Oak Brook, Illinois, on the project for their experience in GIS and SAP integration. A broad initial review involving SAP and Esri solution managers, as well as customers, resulted in more than 200 scenarios where GIS could add some value, and the most promising ones were grouped into the areas of geo-enterprise asset management (Geo EAM) and customer relationship management (CRM).
Since most of the existing integration scenarios involved Enterprise Asset Management, and both solution managers and customers saw great value in enhancing EAM business processes with GIS, Sagres focused first on identifying and understanding EAM business processes, roles, and specific tasks. More than 100 users were interviewed, half of them in their workplace performing their daily tasks, resulting in more than 60 individual use cases. A subset of use cases was selected to be prototyped and piloted at customer sites to validate the use cases; identify existing or new services needed; orchestrate the services into task-oriented, preintegrated components; and use these service components in the context of a composite application implemented using the SAP NetWeaver platform.
Sagres has been a catalyst for defining specific role and task-level services needed for Geo EAM business processes. It has also confirmed that understanding the business requirements and processes is far more difficult than writing integration code in proven technology platforms using industry-standard tools and approaches. This relative ease becomes even more pronounced as Esri technology takes more and more advantage of SAP NetWeaver platform components. ArcGIS Server is already certified to run on SAP NetWeaver Application Server and integrate with SAP NetWeaver Portal, eliminating the need to write code for many administration or user interface integration tasks and delivering visualization and geoprocessing services to SAP NetWeaver Exchange Infrastructure and SAP NetWeaver Master Data Management for orchestration into composite applications and to synchronize data between the two systems.
With a good understanding of Geo EAM processes, roles, and tasks, Sagres is now using the same methodology to understand other application areas that can benefit from GIS integration, including CRM, real estate management, and more. Composite applications are the next wave in GIS/SAP integration because they bring GIS closer to the operations and processes that drive businesses on a daily basis. These composite applications will not replace stand-alone GIS tools. Rather, they will make the functionality offered by them more readily available. By embedding GIS functionality within operational applications and processes that drive the business, these composite applications will make GIS more operational, easier to use, and pervasivekey challenges facing the new generation of enterprise GIS adopters.
For more information, contact Steve Benner, Esri (e-mail: email@example.com).