There are many different flavors of business software on the market today.
If you have an ERP (Enterprise Resource Planning) you can stop reading this article now. In theory, you have very little need for an interface because your ERP does it all. Examples of this type of software are SAP, People Soft, JD Edwards. On the other hand, if you have a best of breed system, it might require interfacing to another best of breed system to accomplish all the tasks at hand for your company. OK, if you have an ERP, you may find it doesn’t fully meet your needs, so you can read on too.
Since we are discussing interfacing, let’s first define what an interface is or is not. Customer’s often come to me and ask if we have an “interface” to load data from their legacy system to their new software system. This is not an interface. There’s no point in writing an interface that gets used once and gets tossed out. This is a “one-time, data transfer”. This is generally done using a database tool, not programming code.
Interfacing, generally means that we want to move data between two foreign systems on a regular, on-going basis.
Batch or Real-time?
Most interfaces in the past were done by a batch method. This meant that the data in the source system, usually many records in a set, was bundled together in a “batch” and sent to the target system or receiving system. This could be done by a human initiating the process or by an automated process. This method was generally done at a quiet time when the systems are not being taxed by users, so generally at night.
Today, we are moving more toward the real-time method. This means the data is sent from the source system as it becomes available. For example, a spare part might be received in the source software system automatically triggering an interface that sends the transaction to the target finance software system. This method keeps data more current rather than waiting for a batch of data to load at a later time. The advantages are many. Information becomes more timely and relevant and the chance of data being re-keyed by humans who can make mistakes is eliminated. By sending single transactions, it also becomes much easier to debug when a problem occurs.
Front end or back end?
In the old days, we wrote interfaces that took data directly from the source database and then put the data directly into the target database. This meant that the source system would have to develop an interface program that “understood” all the data requirements of the target system. This method was dangerous because the source system programmer was generally not familiar with the target system’s database.
Today we use a method that involves web services. Web services are programs that run “in front” of each system that is being interfaced. These web services take the place of the old interface program. The cloud interface is not written to the database but rather to a service that is used to send data from the source or to accept data in the target system. The service in the target system enforces the rules of the target system, thereby rejecting any bad data. The source service is used to extract and send the data from the source system to the target system based on a certain set of rules defined by the user.
The new method of using services to move data is what makes up the pieces of the “Cloud”. Imagine many systems, running in the Cloud, all interfaced and talking to one another.
You can think of the “new” cloud interface method the same as you think about money and banks. In the old days when we had a bill to pay, we went to the bank and took out paper money. We then took the money and delivered it to the store, got the goods and paid for them with cash. This old process meant that we had to take the chance of losing the money while on route, not efficient or safe.
Today’s interfacing is more like direct deposit. You set up an interface between two products and the data is seamlessly moved to the other product just the same as your pay being directly inserted into your bank account. This method removes responsibility from the end-user to move the data/money. It now becomes the responsibility of the software supplier, who acts just like a bank. It also puts the onus on the expert, the software supplier, to manage the transactions, rather than local staff who don’t necessarily do this all day long, for a living.
The real leverage for the customer comes when all software systems run in the Cloud, managed by the software supplier, and they all have frontward facing interface services to send and accept data in a universal format. Companies will greatly reduce their hardware requirement going forward and servers will no longer be required at the end user’s site for programs. IT staff will be greatly reduced. Don’t worry if you’re the IT staff though, you’ll still have a job at the data center or server farm.
