I’ve been looking through old articles from about fifteen years ago to find the exact example but my memory will have to suffice. Years ago there was an advertisement for one of the large systemhouses (we’d call them integrators today) whose slogan was “It’s better to look integrated than be integrated.” We laughed about it at the time but, amazingly to me, there is a certain amount of logic in the silly phrase.
Recently we entertained a software integrator who was looking to provide a “complete project management solution” to his client. He was looking for “a seamlessly integrated solution”; something many of us in the industry have heard the request for in the past. Once we had sat down I had to ask what exactly he meant by integrated and whether his client in fact wanted that.
The answer wasn’t as quick in coming as my question has been and it serves to illustrate that what we’re asked for by clients and staff alike can often be interpreted very differently.
In this case we were looking at several timesheet solutions which would integrate with Microsoft’s Project Server. In one case, the timesheet interface was embedded into the Microsoft Project web interface and had its data directly linked into Project’s. However, this selection had very little ability to link to a finance system. In the second case, the interface was again embedded into the Project Web interface and the data linked directly to Project Server but the interface to the Finance system was at arm’s length through a transaction file. In the final product, the interface was completely separate from Project’s but the data highly integrated to both Project Server and the Finance system using SQL triggers
Once we had categorized the selections this way, our first question to the consultant was, ‘What did the client want?’ The answer would require a couple of days of communication to get from the client.
When we think of integrating the functionality of multiple products together to form a single technical solution, it’s worthwhile to divide up the analysis into a couple of areas.
First off is almost always the data. The products can look like they’re part of the same solution but if the data can’t interrelate in some way; you have to think seriously about what you’re delivering. Creating a flow diagram, first of the data, then of the workflow is often an important step here.
Next, think about the functionality itself. Does this blend of two products overlap functionality or actually deliver something that can’t be done by one product or the other. In our situation with timesheets, this issue is common. There are so many different types of timesheet systems; each with its own perspective, that you have to be very clear about what business problem the client will solve using a particular timesheet selection. This challenge is compounded by the fact that most timesheet interfaces look very similar.
Finally, look at the interface. If the user will have to move from one type of interface to a very different type of interface with each function, you have to consider the mindset shift required to go from one thing to another. Sometimes, just looking very different can it hard for a user to consider that the underlying data is, in fact, related.
Take a bit of time with each perspective. First impressions are sometimes off-base. For example, in our situation, the consultant was absolutely certain that the ability of the timesheet to integrate the data at a very intimate level in real time was a must. In fact, when the client was told that we had the ability to move data into their ERP system in real time, they were very upset. The Finance Department told us that it had taken such a significant effort to stabilize the ERP system that they had no intention of “pushing” data into it from an outside source regardless of how safe it appeared. A transaction file that they could import on a scheduled basis made them much more comfortable. They said they’d rather “look integrated, than be integrated”.
