Some time ago, business were missing the components needed to run their business – if they wanted to use Open Source software. That is no longer the case, with SugarCRM, Zimbra, and SequoiaERP.
Accounting (general ledger style stuff, and mroe) is possibly the last big challenges; some partically solutions are out there and SequoiaERP is currently working on it too.
So all is well, right? Hmm…
If we look at the proprietary solutions, we see not just groups of applications, but integrated suites from a single vendor. In fact, many of these suites are actually more like platforms for which third parties can develop extensions.
Contrarily, the above is highly functional and great on their own but what I think might be missing is the integration. A business may care about this, because they are unlikely to want to maintain their customer database in both their CRM and their billing system. From their perspective, that just doesn’t make sense!
So, should the abovementioned vendors aim to implement an entire suite? Well, perhaps some will, but that may not be the optimal solution. What I would like to suggest instead is some kind of common ground for the core information that the apps should share (such as basic customer detals).
A simplistic implementation example would be a database with a few tables that contain this information, that the other apps can then “share” and join against from their own additional tables. I do appreciate that an effective solution may be slightly more elaborate and would amount to some kind of API.
So, I guess that this is a kind of challenge to those people and companies working on these applications – will you go and try to resolve this?
Most integration products I know (MS: bizTalk, Oracle: Interconnect and BPM Process manager) deal with this in an service (or message) oriented manner.
Once you recognize that there is some other system or application that manages and stores your data (especially when it is probable that it will probably always be the case that some other application does it), it makes litte sense to build the interface via direct database access (as you are suggesting, having application peek into a database to join there data).
What does make sense, or at least, it is perceived so at this moment by the big integrators, is to have web services publish data in some generic XML format. (I guess the idea is that a web service is more generic than direct database access).
I admit it’s a bit of a mystery to me how this is going to perform, but the advantage is that the dataprocessing system is separated from the data exchange (and translation/mapping) system.
Thanks for your response.
I wrote that “sharing a db table” was a simplistic example and that an actual implementation would involve some kind of API (analogous to the service oriented architecture you referred to).
I see no reason why the performance should be bad… others do it, so what’s the problem here?
The problem really is that people have different ideas on what (and how) things should be stored.
take for example a ‘customer’
There is no ‘right’ way of storing customer details or what exactly a ‘customer’ is. (is it a account, a person who has a active relationship with you, a company, a street address, or a lead ?)
who controls the information is another issue. do you really want a sales person being able to edit the address where Accounts payable sends the cheque? or for the sales guy to wait until A/P changes it?
who profits from it? why would a oracle or SAP or SequoiaERP build this functionality? to make it easier for you to buy something from someone else instead one of their modules?
to summarize.. it’s a hard problem, and it would decrease vendor lock-in, hence why vendors don’t want to spend time doing it when they could implement other things instead
regards
Ian H
interesting
A vendor might work on this because their customers will insist on it.
The current situation can’t persist. It doesn’t work for a business.
The wisest thing that OpenSource CRM/ERP vendors can do right now is work on this together. They have a common goal and don’t need to compete on that level. The fact that none of them has a complete suite is a major disadvantage when comparing with proprietary solutions.