Integration of Applications MIS3502: Application Integration and Evaluation Paul Weinberg Adapted from material by Arnold Kurtz, David Schuff, and Paul Weinberg

The Challenges of Legacy Systems Most organizations (and business units) develop their own custom information systems These systems need to be connected when Business buy other businesses Business units merge Organizational structure changes

Legacy Systems Issues Technical – How do we hook these things together? Different systems may have conflicting data values and formats Personnel – How do we find people skilled in older technologies (i.e., COBOL)? Documentation may be out of date or non- existent

A Key Legacy Systems Challenge: Integration Sales Accounting Production Marketing Human Resources data decisions Strategy Tactics Operations

Processes and data What are some key processes in each of these business units Sales Accounting/Finance Production Marketing Human Resources What is the data captured by those processes? Is there common data across processes?

Types of integration Within a department Within an organization (across departments) Within an industry (across organizations) Within the supply chain (across industries) Single view of data Standard messaging What’s the difference between these two?

Single view of data Scenario: The sales process The process of selling a product involves Checking inventory Delivering the goods Creating an invoice The process of accounting involves Collecting payment Updating accounts

Single view of data (continued) “Two system” solution Sales and accounting keep separate databases Each customer has a record in each database What problems can arise? “Single system” solution There is a single customer record That record is used for both the sales and accounting functions What are the advantages of this? What are the problems that can arise?

Accounting DB Levels of Integration Sales DB Accounting DB Sales system Accounting system Sales and Accounting System Sales DB Sales and Accounting System Sales and Accounting DB Scenario 1 Scenario 2 Scenario 3 What happens when you share data across companies? What are the issues with a single database?

Single-View Example: Enterprise Resource Planning “Ground up” integration of business processes A single application ties together multiple business functions Accounting, purchasing, HR Applies “best practices” to these processes Examples: SAP, Peoplesoft (Oracle)

Things made easier by ERP Allows for “perpetual accounting” (real- time) Instead of periodic accounting Provides mechanisms for control Data validation Role assignment Process checks (big orders must be approved by two people)

Enterprise Resource Planning Architecturally… The ERP system contains the central database Business units utilize the central system All must conform to the data and procedural standards of the application Configuration is notoriously difficult Implementations are notoriously complex Why would a company want to do this? Who might resist? Why?

Standard messaging Scenario: The supply chain A large retailer (Wal-Mart) wants to Maintain optimal inventory levels Order from multiple vendors Dynamically adjust product mix A vendor (Proctor and Gamble) wants to Service multiple suppliers Maintain service level

The Need for Standard Messaging Philadelphia San Francisco Pittsburgh Order information Widget Supplier (Widgets ‘R Us!) Division 1 Division 2 Division 3 Each may have their data in a different format! Options: 1) Conversion 2) Standards 3) Combination of both

Web Services – An Emerging Standard o Promises a new level of interoperability o A Web service is a software application identified by a URL, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols. Source: World Wide Web Consortium

What’s a Web Service? “Wrapping up” application functionality (as an object) and running it on a server Allowing people to access that object by Sending information (inputs) Receiving information (outputs) Big Idea: Anyone can write an application to communicate directly with a web service No intermediate application (i.e., web page) is necessary

A Web Service is not a Web Site User Google.com (the site) Google Search Engine (the service) Application Google Search (the service) Using a web site Using a web service interacts with interacts directly with without human intervention

What’s different about Web Services? They are based on open standards Application developers don’t need special expertise to use a web service Use “web protocols” HTTP (Hypertext Transfer Protocol) Handle the transportation of data Request web services like we request web pages XML (Extensible Markup Language) Formatting of messages Structuring data so that it adheres to a standard format

What’s different about Web Services? Instead of sending proprietary messages between clients and servers, it sends messages in a standard format Even EDI is more rigid than XML Messages sent in plain (encrypted) text, making them easy to send to and receive from a web server Any business can communicate with any other business For example, XML is an example of an open standard

Web Services and Distributed Objects Web Services are implemented through distributed objects which communicate using standard messaging protocols There are standards for Sending and receiving data Locating objects across the Internet Describing a distributed object’s functionality

What if all don’t use the standard message? Then they don’t! XML gives an easy way to define messages, but it can’t make you comply Adhering to the standard is a business issue, not a technology issue Businesses can still choose to send and receive nonstandard messages But if no one follows it, the standard is pointless!

Traditional Approach versus Standard Messaging Traditional/Legacy Send nonstandard messages Nonstandard metadata Use non-Internet based technologies Self-contained (designed to share information within systems) Standard Messaging Send standard messages Standard metadata Use “Internet- friendly” technologies Designed to share information across systems