systems int

When it comes to systems integration – keep it simple

Sometime when clients ask us to integrate NetSuite with another package they ask for a tight integration because they believe this will ensure that using the resulting integrated solution will be easier for their users.

For our technical staff it is sometimes tempting to want to undertake a such an integration as it may be more interesting to develop. But from my experience I would always suggest to a client that they keep any integration as simple as possible for a number of reasons.

Firstly the more complex an integration, the more difficult it is to define and design a solution that delivers what users believe they want and what is realistically achievable.

Secondly it follows that it is hard to develop and test and therefore to create a reliable solution. Devising the sort of testing necessary for the users to do is tricky, therefore it is likely that problems will emerge during live running.

Thirdly a more complex integration is more difficult to maintain and any problems in live running may prove hard to analyse and even harder to correct and re-test.

Fourthly a tightly integrated solution (for example where one package is adjusted to use the other package’s product file) may well have problems when either package is updated. At least whenever a new version is introduced, the integrating solution provider will need to consider the potential for issues.

Fifthly the thorny issue of determining the cause of a problem is exacerbated by tight integration. I always think it a good idea for a client to consider who will be responsible for determining what element in the system is causing the problem and have a support contract in place with that party which specifies this role. It is also a good idea to have all other supporting parties agree to respect the ‘problem identifier’ (with all necessary caveats). Many clients do not appreciate that this role is required and can be time consuming. They may be reluctant to pay for such a service, but without it the user client (probably without the necessary technical knowledge or skill) often has to spend time negotiating between suppliers to prove where a problem lies and establish responsibility.

In summary, I suggest that for most integrations the apparent time saved in user tasks by a tight integration is likely to be lost in the time involved in accepting the specifications, testing and accepting the more complex solution plus in time lost due to greater system downtime and discussion with suppliers about problems experienced during live running or when a new version of software is made available.