One Challenge of CRM (and of any business application) is the distributed nature of data. Data is one of a companies most valuable assets, yet it often exists in application silos throughout a companies IT environment, often leading to data duplication and inconsistency. Over the years, many tools have been created for the migration and integration of data, but they usually involve data comparison and transfer to keep data consistent between systems. As we move towards a more seamless cloud computing environment and a service-oriented architecture, the problem of distributed data must be taken into account.
One of the concepts of service-oriented architecture dictates that applications are created as “services”, which can be subscribed to in small chunks to fit a companies needs. Rather than purchase a whole application suite, a company can simply pick and choose the services that best fit their application strategy, and subscribe to those services and only those services. Services from different vendors become interoperable across the cloud, making application plug-and-play a reality with low up-time high interoperability.
Unfortunately, reality still has a long way to go to catch up to the theory. The SOA model is still in its infancy, and while great strides have been made, there is a long way to go before te benefits of this architecture are fully realized. But what to do with the problem of distributed data? The applications of the future that rely on SOA have to stop the practice of looking at physical data storage as being tied to a specific application or application suite. Rather, applications should be written to allow for user interactions with logical business objects,which are then mapped to data elements in the enterprise that correspond to the logical need.
For example, a new Sales Force Automation implementation will typically have an area for managing company information. Rather than reinventing the wheel and requiring all company information for the CRM to be stored in the CRM’s own database table, the Company Business Object should map to other pre-existing databases that already contain that information. Company Name, billing address, and account balances can all be mapped to the company’s financial system database, while order information can be mapped to the company’s ERP database, and new CRM specific information can be stored in tables local to the CRM system. Rules can be set to manage validation rules between systems, and business logic created to manage the interaction of data between the various services.
The Data Service Model looks at data itself as a series of services, no matter where the data resides and what system it technically “belongs” to. It’s implementation will be critical to the long-term success of SOA and Enterprise 2.0.
Related posts:
Be First To Comment
Leave Your Comments Below