An emerging trend of the last few years is that companies of all sizes are hanging onto their financial and ERP software solutions for longer. Whereas replacement cycles used to be anywhere between 3 and 5 years, it is not uncommon for organisations to hold onto their systems for seven or more years.
The trend partly reflects the convergence in functionality and capability between systems, so that there are fewer opportunities for gaining a competitive edge by swapping between one financial system and another. Secondly, technology is less of a driver for change as consolidation of the marketplace has reduced the choices on offer and open standards have promoted increased interoperability between suppliers' systems.
This is particularly true in the mid-market, where solutions from many software vendors reside on a Microsoft platform for both operating systems and databases. For example, there are thousands of solutions, ranging from accounting and CRM (customer relationship management) to budgeting and reporting that work in a Microsoft environment. Companies that have added piece-meal to their solutions, or consciously followed a 'best of breed' approach to systems development have the advantage of a uniform platform to help them integrate different parts of their systems.
But according to Rob Steele, Product Director of IRIS Enterprise Software and co-founder of the mid-range accounting system, Exchequer, integration is not necessarily as straightforward as it first appears. He told FSN, " Many of the companies we talk to are potentially being misled by IT managers and consultants who have failed to grasp that a common database, in particular Microsoft SQL, is not the key to integration. Integrating two systems is a delicate process and despite the hype surrounding SQL, other technologies play a crucial role in delivering a fully integrated solution."
Ian Caswell, Managing Director of Sapphire Systems, a leading SunSystems and SAP reseller agrees. Commenting to FSN he said, "We sometimes find ourselves competing in bids where the potential customer and other resellers completely fail to recognise the true cost and complexity of integrating systems. It's a gross oversimplification to suggest that just because both systems are Microsoft based that they will be easy to implement."
According to Steele, there are three main elements to a software application. Firstly, the user interface which controls how the application looks, feels and functions, secondly, the business rules which determines how it computes and lastly, the underlying data – which in most cases in entered by the users.
"When we talk about integration, we are really talking about data integration. In other words, we want to enter the data once and for the system integration to ensure that data is entered into all the relevant systems automatically," says Steele.
However, in order to integrate one system with another, there need to be common standards in place. The software market has matured quickly enough for a number of such standards to have been in place for many years. For example, an early (and rather crude) form of integration was the CSV (comma separated values) method, whereby a simple text file containing data in a certain order could be exported and imported from different systems. This is still in use today, but is usually used for one-off non-automated integration, such as initial data migration from an old system to a new system.
These days it is more common for many software applications to use the same underlying database. Whilst this has some benefits in terms of speed of integration, it is also open to potentially disastrous consequences. "Any programmer trying to integrate two different applications simply by exploring the data tables and updating whatever they see fit is likely to have disastrous consequences," Steele told FSN. "In most cases, it is not simply a case of updating the same field of data in two systems. What you have to take into account are all the business rules, validations and checks that are made within each application whenever that field or record is changed."
Clearly, successful integration requires the developer to have a complete understanding of the entire logic and processes within each application. This, says Steele, is highly unlikely. "It is far more likely that the developer will fail to update all the required records, or will fail to make all the necessary validations of codes and calculations, which will lead to inaccuracies, imbalances and corruption in data," he remarked. Furthermore, any upgrade to the business rules in the core system will usually require the integration to be re-written and therefore re-tested, a time-wasting and costly exercise.
According to Dave Turner , global marketing director at CODA, it is not only resellers that take shortcuts. "We have been surprised at the extent to which some of the largest systems integrators have been guilty of ignoring published API's (Application Programming Interfaces) and directly poking around in databases. It means that the customer is locked into that supplier when it comes to upgrades," he told FSN. It also explains why CODA is so enthusiastic about web services. Tim Tribe, product manager at CODA added, "Web services provides a degree of platform and vendor independence, reducing the complexity of interfacing systems."
Upgrades are indeed a major problem and Sapphire Systems, for example, have developed a specialised mapping and synchronisation tool which Ian Caswell says has saved time on many major projects. He told FSN, "Integration is tough and version 'lock-in' is a serious problem. It often requires you to work collaboratively with several suppliers and it can be challenging to keep the applications in step if one product develops a bug and needs to be upgraded."
Despite the clear challenges, IRIS Enterprise Software's Steele considers that Integration actually isn't rocket science. "It is very simple to get data from one database to another, regardless of whether they are the same database product or not. The essential ingredient in successful fault-free integration is the accessibility and adherence to the Business Rules," he says. Tim Tribe of CODA agrees, "Integration isn't technically complex it just needs to be done properly through published APIs."
Any professional software author should have the business rules clearly identified within their application, but these are usually only accessible from another module written by the same author – problems arise when the payroll is developed by a different company, who do not have access to the source code and therefore cannot follow all of the business rules. That is unless they follow similar development standards such as, COM (Common Object Model), launched by Microsoft, several years ago. This technology allows software authors to effectively make their business rules available for use by the outside world in the form of a software developer's toolkit.
This not only means that the business rules are followed without fail every time, but because COM is checking the business rules within the source code itself, it is completely future-proof as well. Therefore any upgrades to the core source code will automatically affect any data entering the system, regardless of whether it is being manually entered or imported through integration with an external system.
"Any modern application can use COM, it is not restricted to Microsoft databases or development languages. COM is fundamentally designed to allow applications to talk to each other in a controlled manor, adhering to all the validations and business rules built into those applications. Developers' toolkits which use COM are therefore database and language independent, future-proof against upgrades and provide freedom of choice to use the right best-of-breed applications, with the right database for the business needs," says Steele.
The problem is that system integrators take short cuts and create interfaces between systems that ignore some or all of the validations and have to be re-written each time the core systems are upgraded. "Companies need to ask their IT Consultants and Managers whether COM technology is being used to ensure that they are not being misled," says Steele.
Integration can be expensive and could be an ongoing cost. "The cost of integration can be a very significant part of the cost of acquiring a new system but is often overlooked. It's why for example, that SAP argues in favour of an ERP system rather than a best of breed solution," says Caswell.
Whilst some unscrupulous dealers and consultants may suggest that the answer to 'integration' lies in a SQL server box, there is clearly a great deal more to the issue. It is not the database alone that makes a difference. There are a variety of different databases which when combined with COM technology can deliver the level of integration that many mid-market companies are looking for. But if you are seeking to avoid unexpected project costs, you ignore integration issues at your peril.
