Question

I am thinking about some issues which may match the term software integration best.

Assume there is a machine running an operating system and some programms A, B and C. Now all programms somehow store data on the filesystem. Lets say A uses Apache Derby, B uses PostgreSQL and B uses XML files.

Now there are three ways to store data. The obvious question is: Why not use just one way of storing data for all programms?

At first someone could say: There is no way to configure the way of storing data for most programms. It is build into the programms itself. Its a developer decission, based on the requirements of the software.

This may be right, but I don’t think that most programms has special requirements on how to store data. There is only a minority of programms which needs a specific way of storing data. All developers of the majority of software may agree to one specific way of storing data, e.g. PostgreSQL. Now the administrator could install PostgreSQL and all the programms could use it together.

This could be even more flexibel. I don’t know if there is something similar for native programms, but for Java programms you can use something like JDO to store the data. JDO is a standardized persistence framework, which is datastore agnostic. It is possible to use RDBMS, XML, object bases datastores or whatever. The programm is almost 100% independent from the way of storing data! You can configure the way the programm uses to store data through a configuration file.

If all programms would use JDO, all programms could be configured to use the same datastore, without beeing fixed to a special one. This would simplify the software landscape on such a machine.

This is not limited to datastores. There maybe other redundant software on this system, which is even more integrated into the software and may not be configured from outside, because lack of abstraction.

Are there any known approaches to integrate all the different software in a more homogeneous way?

Thanks in advance

Answer 1

It’s been tried.

It has, in fact, been tried over and over again.

But to make it work you have to

1. Anticipate all possible use cases. Because if you don’t someone will roll their own rather than wait for you to add a new feature to meet their need.
2. Handle all those use cases with maximal efficiency. Because if you don’t, someone will roll their own rather than wait for you to fix a corner case that they need but runs slowly in your implementation.
3. Control the platform, or included everybody in the process (and keep them happy!). Because if you don’t people will roll their own in search of a competitive advantage.

Do you begin to see the scale of the undertaking? Do you see how slow it would be compated to progress in IT?

In fact, it is pretty hard to do this just in one medium sized project.