Application Integration: The Future of Technology in Business

Transcription

1 Application Integration: The Future of Technology in Business ISLANDS OF DATA Over the last twenty years, the trend for businesses has been to base application development on need a new application is built whenever a new business need arises. Creating applications to solve short-term issues is often necessary to accommodate the speed with which businesses are affected. Most businesses have a multitude of applications running, whether on desktops or on servers. From spreadsheets and desktop databases to accounting and business-specific software, company data can be found in a variety of forms. However, placing information at numerous locations and within various applications can cause companies to face overall architectural issues later on. A veritable data diaspora is created, ultimately resulting in inefficient business processes and an overall decrease in productivity. In tough times, business professionals need to focus in on those customers with whom they do the best business. The process of focusing in on these customers may involve intense data mining and analysis, but if a data diaspora exists, identifying the right individuals is difficult, time-consuming, and costly. For example, a small business recently wanted to find out information on its customers and discovered that the relevant data was stored in over ten different applications. Although this business was not a large enterprise, the rapid nature of growth in the 90s forced it to develop numerous applications to solve immediate issues, adding to the "islands of data" (Figure 1) dilemma prevalent in virtually every organization. Figure 1: Islands of Data Resulting from a Data Diaspora ISLANDS OF APPLICATIONS We have discussed issues of data integration and the often negative effects that "islands of data" can have on a business s productivity. However, some major, if not more important aspects of application integration are the different pieces of code that process the data. Each application works on data separately. Consequently, core functionality can be duplicated across many different applications, causing an unnecessary inefficiency. Moreover, when a business s policies or strategies change, adapting different applications to reflect these changes is an overwhelming task; worse yet, a business may find itself applying old business rules to new data (Figure 2). Figure 2: Islands of Applications Working on Data Separately In the past, attempts were made to build a universal "monster" application that would solve this problem of "islands of applications." But this of course failed, as any new additional functionality took too long to implement in such a large application, and businesses couldn t wait for the functionality to be added. Once again, new applications were created to handle new business issues for the "short term," and all of these short-term solutions ultimately became permanent solutions, only adding to the original problem. Application integration is, in essence, the solution to all of these issues. With application integration, applications "talk" to each other, reusing each other s data as well as application functionality. Critical functionality doesn t have to be duplicated when a crucial business 1

2 Application Integration: The Future of Technology in Business function is required, and other applications can call the "designated driver" application for that function when needed. In addition, when a change is made to business policy, only the "designated driver" needs to be changed with all of the other business applications being able to take advantage of this change. HISTORY OF APPLICATION INTEGRATION The need for application integration has been around for as long as businesses have been developing applications. Ways of coping with this need have varied, and can be categorized into four main approaches: 1. The Manual Approach The most primitive and most costly approach to application integration is the Manual approach (Figure 3). In this case, reports are printed and then re-entered manually into a different application. Despite being the most costly and time-consuming approach, this approach is the most prevalent in businesses today. Figure 3: The Manual Approach Figure 4: The Import/Export Approach 3. The Primitive Data Structure Access Approach A major step was made when database companies offered data structure access to the underlying databases (Figure 5).This allowed real-time access to data. Standards such as ODBC allowed access to the data from both server and desktop applications. The big advantage of course was that data could be read at any time and was guaranteed to be accurate. The big disadvantages were that there was no application sharing, and all the applications wishing to access the data needed to duplicate functionality. Any change in the data structure (e.g. adding a new address field) required that all applications accessing the data structure be modified to take advantage of this addition. Also, since many applications have strict integrity rules, such as accounting applications, allowing other applications to change data at the lowest level without any of the standard checks that the original application would normally perform, could cause serious data integrity issues. One of the biggest benefits of primitive data structure access was that users could do ad-hoc queries from products such as Microsoft Excel. However, this benefit was negated by the fact that users had to learn how programmers design data structures, and had to be retrained if any changes to the structures occurred. 2. The Import/Export Approach In this approach, data is exported by being operatordriven or by being automatically exported by the software, transferred, and then imported into another application (Figure 4). Of course one of the biggest disadvantages of this approach is the static nature of the data. Any changes made after the export are not apparent until another export is done. Consequently, the second application gets only an "approximate" nature of the data. This is obviously not acceptable for real-time transfers. Moreover, there may be issues with the formatting of the data that is exported from one application to another. Frequently different applications have to be written to "massage" the data into a format that the second application can read, thereby adding to the number of applications that have to be maintained. Figure 5: The Primitive Data Structure Approach 4. The Custom Application API Approach As we mentioned previously, serious integrity issues could arise if data was accessed at a low level without paying attention to integrity or business rule issues. To overcome this problem, a number of application vendors such as SAP and PeopleSoft created their own custom APIs to allow other applications to share data and application functionality. The biggest issue was that each API was different and each method of calling it was also different. As these APIs were tightly coupled to specific applications, other application and development 2

3 tool vendors would have had to make major investments to support each application vendor s APIs. While the concept was promising, these APIs never reached their true potential because of the overwhelming lack of acceptance on the parts of other vendors (Figure 6). Figure 6: The Custom API Approach TODAY S APPROACH: WEB SERVICES Web services builds upon the Custom API approach, taking all of its advantages while providing additional benefits (Figure 7).Web services utilize open standards, and are loosely coupled so they are not tied to any one vendor s technology. Web services also allow one application to call another application using standard protocols such as SOAP and XML. This ensures that data integrity is maintained because the "designated driver" application is the only application that touches the data. If the business functionality changes, it only needs to be changed within the "designated driver" application. applications, they can now focus on the functionality of the application and the benefits that it adds rather than the underlying technology. As long as the application is Web service enabled, you will know that the application can integrate with your other applications. To recap, Web services allow real-time access to data, while ensuring data integrity and allowing for the sharing of data as well as the sharing of application logic. 4TH DIMENSION AND APPLICATION INTEGRATION 4th Dimension has always been a leader in application integration. Since the early 90s, 4th Dimension has released integrated word processing, spreadsheet, and drawing applications that allow for the development of complete and integrated applications (Figure 8). Figure 8: Integration Provided through 4D Write, 4D Draw, and 4D View 4th Dimension pioneered enterprise database connectivity with primitive database drivers to Oracle, SQL Server, and all ODBC databases. 4D also published its own primitive database driver called 4D Open, which gave other applications access to 4D-based applications data structures (Figure 9). Figure 7: Web Services Since Web services are loosely coupled, it is much easier for different vendors to support this technology. As most major application vendors and all of the influential development tool vendors now support Web services, application integration will become more prevalent, allowing developers to choose development tools according to what is right for the job rather than settling for a tool simply because it was originally used in the organization. In addition, when businesses are acquiring Figure 9: 4D Server with 4D Open Talking to Oracle and ODBC Databases 4TH DIMENSION 2003 AND APPLICATION INTEGRATION 4th Dimension 2003 introduces a number of new features to enhance application integration. First, 4th Dimension 2003 now supports the import and export of 3

4 Application Integration: The Future of Technology in Business XML data through a manual process or programmatically (Figure 10). XML is fast becoming the standard for transferring data between applications. Figure 10: XML Imported into 4th Dimension In addition, 4th Dimension 2003 supports Web services as both a Client and a Server. This means 4th Dimension 2003 applications can call methods in other applications as well as allowing other applications to call 4th Dimension 2003 applications. For example, a 4th Dimension 2003 application could call a method in SAP while simultaneously allowing a Microsoft Excel application to call one of its own methods (Figure 11). Using 4th Dimension 2003, application logic can be shared with other applications while also allowing 4th Dimension 2003 applications to share logic in other Web service enabled applications, irrespective of how they were developed. In this sense, all the applications in a business can share data as well as application logic. Of course, all of this would mean nothing if Web service enabling applications meant that these applications had to be drastically rewritten. Unfortunately Microsoft, among others, has chosen this approach forcing the massive rewrites of any applications developed in Visual Basic. A recent Gartner Group report discussed how it was going to cost enterprises another 40% - 60% of the original application development cost to rewrite Visual Basic based applications in order to allow them to be Web service enabled using Visual Basic.NET. 4th Dimension 2003 was architected to allow most existing 4th Dimension applications to support Web services without any code changes required. For those that do have to be changed, a single line of code will allow any of their existing logic to be called as a Web service. Allowing 4th Dimension 2003 applications to call other Web service enabled applications is equally easy a wizard guides the developer through the process and generates all the code necessary to call other applications (Figure 13). Figure 11: 4th Dimension 2003 can call a method in SAP while Excel calls one of 4th Dimension s own methods. This means that all applications developed in major programming languages such as C#, Java, 4th Dimension and Visual Basic.NET can all "talk" to each other as if they are one (Figure 12).This fulfills the dream of the single business application without having the inflexibility of not being able to change applications quickly or develop new functionality. It also allows applications to be chosen based on their functionality and not according to the development environment in which they were developed. Figure 13: The 4th Dimension 2003 Web Services Wizard Figure 12: C#, Java, 4th Dimension, VB.NET All "Talking" to Each Other CONCLUSION 4

5 There have been many attempts at application integration, but none of these attempts, however adequate, have allowed for true data and application logic sharing until now. Web services technologies allow this dream to become a reality by giving businesses the opportunity to focus less on technology and more on an application s functionality or on a development tool s ability to accomplish a specific job. 4th Dimension 2003 enables all 4th Dimension applications to become "team players," allowing them to integrate with all other applications so that the best possible business solutions can be achieved, regardless of vendor, programming language, or any other previously limiting factor. Application developers can now choose 4th Dimension as a development tool knowing that the applications developed can integrate with all standards based applications. Similarly, businesses can choose 4th Dimension based applications, knowing that these applications will integrate with any current or future applications in a manner that is both easy and cost-effective. For more information please visit < 5