CRM Definition Language

After working with SalesForce and now SugarCRM for several months I have experienced the growing pains that come from reaching the bleeding edge of functionality needs yet again.

One thing that hit me recently is the idea of separating the CRM application from the application's presentation space. I began thinking that CRM designers shouldn't need to specify the data layer, nor the presentation layer during the application design phase. Sugar does a pretty good job with abstracting away the database maintenance, however it comes at a significant cost. Most of the default objects in Sugar cannot be replicated in the included module builder nor studio. This specifically includes advanced object relationships and the transfer of ownership between parent data types.

This level of functionality requires a good deal of custom coding, which would be fine except the coding must be done to the database queries, vardefs and viewdefs and application front end code. So I ask myself, why include functionalities in the first place that aren't available when building a new custom module?

I looked at several other CRM options like vTiger and openCRX, but it still seems they all suffer from a similar issue. The underlying issue is application portability and the separation of CRM data and application.

I think there needs to be a shift in the design methodologies for CRM and other relationship management applications. The design shift should be towards application independence and an open CRM specification.

The specification would be an open standard for the definition of an applications data and functionality relationships. The application would then exist in the specification only, and would allow the rendering application to handle the construction of data structures, GUI design, interaction between users, application and data.

Ideally an application's specification would be represented in a simple XML document. The design could be done by hand or by an application and then published to the service provider or front end application. The front end application would consume the specification and generate the appropriate database schema and structure and corresponding GUI elements.

I have begun to outline the functionality of my .01 version of the specification in and eventually I hope to publish it and see if anyone has some valuable feedback or if it could possibly scratch a few itches.