Bringing information from other departmental systems in to the finance system, in real-time, seems to be nothing more than a dream for most finance professionals. But it needn't be so hard, meet the technology behind true, real-time data sharing.
As a business, your systems will have tons and tons of data stored between them. Whether that's HR, EPOS, CRM, Inventory Management or any other software you are utilising, undoubtedly they all hold data that would be invaluable to overlay with financial information.
But far too often troubles arise trying to access that data in a meaningful way, and incorporate it into financial reporting. And accessing it is only half of the battle. If it takes you days or even weeks to extract, manipulate and upload, you risk making key business decisions on data that's now out-dated!
Interoperability is the technology that allows this information to be shared in an easy and stress-free way so you’ll have accurate, up to date data that you can report on.
There are a number of definitions of interoperability (true, modern data sharing), and as this is the world of IT, some are quite technical and opaque. Most people define it as the ability for two software applications to exchange information in real-time, without human intervention, meaning your finance team will become more efficient. Many definitions also include the ability for this to happen on a transactional basis, in other words, an outcome where system 1 generates a transaction that is immediately sent to system 2 in real-time.
There’s no need for batching things up and waiting for a scheduled transfer to happen at some point in the future. Having said that, there’s no reason why the receiving system can’t batch things up to wait for approval but that’s not a system limitation.
There are three basic methods for getting applications to share information:
This is when data is extracted from System 1 and written to a file that can be transferred to System 2 where it will be read and inserted. Typically the file is a comma-delimited text file of some kind. This method has been used for decades and it has some pretty serious limitations.
Due to human error, a file might not get created or loaded properly, or the transfer is missed one week, or it might get loaded twice by mistake, which is a disaster for finance systems as it’s impossible to simply delete data.
Flat File Transfer can work effectively for a one-off transfer, but what happens when the original data changes? Even something simple like a change of address can be very difficult to deal with.
It’s difficult to ensure that the routine that selects the data in system 1 doesn’t miss something, or use data that’s already been selected before. In short, Flat File Transfer is adequate for one-off jobs like loading setup data, but for ongoing transactional processing, it’s really a non-starter.
This solution was very popular around thirty+ years ago and involved System 1 and System 2 both sharing the same data objects in the database. For example, both systems might share the same Suppliers Table.
Obviously, if there’s only one set of data then it’s always going to be “in step”. Although this may sound simple and even elegant, it has its own problems too.
Both systems need to share the same data structure for them to work. However, in reality, all systems are different in practical terms, and the only situation where they are likely to match is where they’re both from the same supplier. That means clients can become ‘locked in’ to one particular supplier. That’s great news for the supplier, but awful news for the customer.
The second issue is more subtle. If a company is running different systems, for instance in Finance and HR, all may be fine until one of the systems is upgraded. A new HR system may no longer be compatible with the existing system in Finance, so that means that the company is forced to upgrade the latter too. The problem becomes exacerbated when you consider the number of systems that may be running across one organisation. It simply isn’t practical to upgrade all your IT systems in one go.
Organisations can’t easily replace any of their existing elements with a different system. This is why IT suppliers love classic integration so much! One point to note here is how much things have changed since classic integration was first introduced. The world was simply a different place in the 80s. In 1983 disk storage would have cost you around £211,000 per gigabyte (in 1983 prices). But today a gigabyte of storage can be bought for around £0.02 and falling! This opens up more possibilities when it comes to data storage, meaning Integration really is old news now!
That leads on nicely to the third option – Interoperability. In many ways, it’s a very simple idea. You have two separate systems but you keep the data in sync in both systems. Although some of the data is duplicated, this isn’t an issue because, as already mentioned, the price of storage has fallen so much. It avoids all the problems of the other two methods and doesn’t have any unique drawbacks.
Well yes – you’d think so. But many IT suppliers are keen to force customers to buy more of their software products rather than other supplier’s products and have a vested interest in actually preventing interoperability. Stories across the accounting software industry abound of suppliers doing anything they can to prevent the technology from working, using everything from legal threats to software upgrades designed to prevent existing links. However, these suppliers are fighting a losing battle and true Interoperability is here to stay.
As with so many things, a change in the market has driven change everywhere else. Today consumers have mobile, cloud-enabled, remotely synchronising technology that they carry around and use every day. This has had a huge effect on people’s expectations. They know that IT systems can share data as they see it happening in real-time every day. It’s quite normal to open an email from a Microsoft hosted mail server on an Apple device and then click through a link to a Java-based website that asks the device for your location before delivering a localised weather report created on a supercomputer on another continent. Any user can see that these systems can, and DO, interoperate. So anyone who argues that it can’t be done within your finance department probably has a vested interest.
Initially, a holding area is set up in System 1. This is where all the data that’s going to be transferred sits before it goes anywhere else. The data is marked as being a new ‘insert’ into System 2, an ‘update’ to existing data, or a ‘deletion’ of existing data. They also set up a similar receiving area in System 2. This connects with the holding area in System 1, so the data can move across in real-time. If the connection is down then the data can be held for transmission until the connection is restored.
As soon as the data arrives in System 2 it can be processed in much the same way as if it were processed by a real human being. In other words, the functionality for processing transactions sits in the backend database architecture, enabling transactions to occur in exactly the same way. Once the basic framework has been set up, an organisation can do all sorts of things with its data. Process a sales invoice, change a supplier’s address, check that an account code is valid... it can all happen in real-time, transaction by transaction if need be.
Whenever System 1 is upgraded, the holding area stays in place and can still work with the existing version of System 2. And the Systems can be changed or swapped without losing integration. We think standards governing every type of transaction will evolve in the long run, but in the meantime, we make sure the processes that can transform the data are held in the receiving area of System 2.
Writing new transformation modules for new applications is a fairly quick and easy process. In the past, this was all done by database link and trigger technology but nowadays we are seeing it done by ‘web service’ technology. That’s a sure sign that Interoperability’s time has come! Goodbye to re-keying data - that’s so 90s!
We know that Interoperability works a treat, and we have come to expect it from our personal technology, so now want the same thing from our business IT. The reason why many organisations are not yet fully enjoying the benefits is simply down to the fact that they do not realise that it’s an option. Indeed, many providers continue to bombard their customers with jargon and lead them to think that their way is the only way. Every business is different, so it makes sense to choose the software that is genuinely the right choice for your organisation, and be confident in the knowledge it will all “just work!”
bluQube has always been designed with data-sharing in mind. In fact, we're confident bluQube will happily integrate in real-time with any of your business systems. Book a demo for a free consultation and see how bluQube could transform your finance department.
The fintech they don't want you to know about
Everyday examples of interoperability
We use cookies to improve website performance.
