1. Field of the Invention
This invention relates to data conversion and more particularly relates to internet-based data conversion.
2. Description of the Related Art
Modern computer systems vary in their design and architecture, with many different models available to achieve the desired combinations of speed, power and efficiency for any given computer environment. This multitude of different computing environments allows a consumer to select the right computer for a particular job. For instance, an engineering firm might need a computer aided design station, which necessitates a very powerful, fast computer, using the newest and most powerful operating system. Meanwhile, a home user might simply want to connect to the Internet to send and receive email, which does not require the expense of a fast computer, nor the most current operating system. Further, computer professionals have the capability to create proprietary computer devices, structures and systems that may be unique and may be uniquely adapted to a particular user or user set. Thus, the proliferation of different computing environments has been beneficial.
Further, as technology rapidly advances, new devices, structures, and systems are developed and enterprises must make decisions as to when and what to adopt. Therefore, the variability of computer devices, structures, and systems is increased, as each enterprise must look to its own position and needs. Also, as an enterprise may acquire or merge with other enterprises, there may be collected a great variety of computing systems, including many diverse databases. Therefore there may be many reasons for an enterprise to find itself using a variety of systems of varying age and compatibility.
However, there are drawbacks to this multitude of computer systems. Because each computer system, including the operating system, may be designed differently, the way that data is actually stored on each computer system may be different. For instance, a set of data stored by a Cobol program looks very different from the same data stored by Oracle. Further, legacy systems (systems that continue to be used despite poor performance/compatibility with modern systems because of a prohibitive cost/time of redesigning/replacing) may be difficult to work with due to varying standards and/or inconvenient methods of storing data. Therefore, it becomes difficult to synchronize/port data between different computer systems.
Data is generally stored as a series of bytes, words, or double words, depending on the format of the medium holding the data and any format choices made by a storage program. Storage formats vary greatly as any format imaginable may be used. Where data must be transferred from a first format to a second format, it must first be transformed into a format appropriate to the second format. Therefore data is converted, usually by a data conversion program that is “hard-coded,” meaning it has been written expressly to make such a specific conversion.
However, where the data format of the storage medium changes, the “hard-coded” data conversion program must also be changed or rewritten to deal with the new changes. For instance, if the data is the output of a database, and the database is changed to add additional data elements, the “hard-coded” data conversion program must be modified to comprehend and properly convert these new data elements. This process of rewriting and modifying data conversion programs can be tedious, expensive, and time consuming, as the data conversion program must be modified to comprehend the new data format(s) and element(s) and to know how to properly convert the data elements into the correct formats. Maintenance expenses for such proprietary code can be very high. Further, such “hard-coded” programs are useless for any purpose except for that which they have been written. Therefore, different data conversion needs must be met independently and without benefits from previous solutions.
There are data conversion tools configured to automate portions of a data conversion process and configured to be portable across different needs. However, most of these tools use proprietary scripting languages that are interpreted. This results in a slow execution. When handling very large conversions, using the tools instead of hard-coding may result in extra days of downtime processing that may result in downtime costs in the millions of dollars.
Further, the tools may be unable to handle more complex conversions. For example, the tools may be unable to handle very large flat files, or may be incompatible with a custom designed or uncommon database. Also, the tools may be insufficiently powerful and adaptable to convert data to an ideal state as would be desired by an enterprise. Still further, enterprises are required to purchase licenses to the tools for several hundred thousand dollars with maintenance costs typically starting in the tens of thousands of dollars.
For dissimilar computers that are connected by client-server architecture, modifying data conversion programs is especially tedious and time consuming. Many networks have “client-server” architectures that allow many clients to connect to one or more servers. Such architecture brings many benefits, such as centralized control, enhanced interconnectivity, increased flexibility and more user empowerment. Further, because servers are typically much faster, more powerful, and have greater storage space than clients, servers tend to outperform clients, especially when using programs that involve complex calculations or tremendous amounts of data. However, the above listed benefits come at a cost of increased need and complexity of data conversion. Each program, operating system, hardware device, and storage system included within the “client-server” architecture also typically requires some form of data conversion to properly meld with the entire system. As server systems may become quite complex, the data conversion needs and complexities may increase exponentially. Further, as the user base increases, there is an exponential increase in the likelihood over time that user needs will change and necessitate changes in data format or data types.
For example, having airline ticket information stored on a server allows ticketing agencies around the world to determine which seats are open for which flights. These agencies may all be using very different computer systems, but must all be capable of interpreting the data stored and managed by the server. Therefore, when the client (ticketing agency) calls a server (or Application Programming Interface, or API), the server or API will typically return a set of values.
For instance, if the program is returning a list of available seats on an airline flight, the number of seats can vary from zero (the plane is fully booked) to the capacity of the plane (there have been no seats sold). This may be even more complex where the seats are divided into categories such as isle or window seats, first and second-class seats, the type of dinners available, etc. The data conversion program must understand these varying data types and be able to interpret between the client and server. This may be complicated further wherein a component of the system may add security to the data, such as encryption or data boundaries (extraneous data at an end of a data set used to ensure an entire data set is transferred).
When the data format changes, for example adding a new class of seats, a new category such as laptop enabled seats, seats close to emergency exits, special needs seats, etc., then the “hard-coded” data conversion program must be modified to include the new categories. Thus as an enterprise may develop new strategies, needs, equipment, etc., these may have an impact on the data used by the enterprise. Adapting “hard-coded” data conversion programs to these changes can be very costly and complex.
These costs and complexities may be even more pronounced where an enterprise, such as an airline, may merge with another enterprise using a substantially different computing system and set of databases. These costs may be pronounced even further if there are legacy computing systems and sets of data that are difficult to use, such as where the data is stored as a very large flat file of an unknown format or is stored on a mainframe.
Further, current systems and methods of performing data conversion fail to address needs in the business community wherein current methods and systems may require purchasing a very expensive tool, such as but not limited to a conversion suite, may require long term agreements between data conversion providers and data conversion consumers, may require the onsite presence of tools, and/or may be unable to adapt to specific needs of consumers without significantly damaging other business models, thereby restricting data conversion providers to only select groups of consumers.