Is Sharepoint the right platform for large ERP applications?

Question

I have been tasked with developing some large ERP applications (some legacy apps being rewritten and some new apps) in Sharepoint. As I've come up to speed in Sharepoint, I see the value and ease of creating team sites, and the examples I've found online and in books are all tailored to intranet department portals, or simple line-of-business apps for companies that don't have large legacy ERP systems. I have begun to believe that if one is going to create a large application that interfaces to several different legacy systems and spans several departments, that building custom webparts in Sharepoint just isn't the way to go.

Is Sharepoint a viable application framework for creating and hosting large ERP applications?

If so, can anyone please point me to references describing the architecture of such a system?

If not, can anyone please point me to references that I can cite as arguments for not using it?

Answer 1

The MS Dynamics AX system utilizes Sharepoint extensively, in fact there are tool kits that allow users to build web parts and so forth that extract data directly out of the base AX objects. Here is a link that talks a little about the Sharepoint integration AX+SP. Currently there is still a significant portion of AX that does not reside within Sharepoint, but their direction appears to Sharepoint enable a significant portion of the application. I do not think that an entire ERP system could reside within the Sharepoint infrastructure, but from an MVC perspective it could certainly become your View infrastructure. It appears to me that this is the very direction MS is heading, but I'm just making hypothesis on their future plans.

Answer 2

I'm currently deploying a ERP system written in Sharepoint for a client. I've been working on this for about a year now and from what I've seen, Sharepoint introduced as many obstacles as it made things more complicated.

Things made simpler:

• Credentials automatically synced to AD.
• Document handling and versioning out of the box.
• Great Office integration.

Things that sucked:

• You need to learn the Sharepoint way of doing things.
• You have another dependency in your ERP.
• It's pretty clunky.

I would recommend reading Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs before making a decision

Answer 3

I use SharePoint 2007 (MOSS) at work as part of a larger ERP installation. We heavily use the Business Data Catalog to interface with external systems and make their data visible and searchable within our MOSS portal.

In our architecture, CRUD operations on the ERP data are handled in our ERP line of business systems. MOSS and the BDC then pull the data out of the ERP database and display it as datagrids embedded in various portal pages. For example, the HR site has a MOSS page for tracking the current status of pending performance reports.

Another compelling feature of MOSS and the BDC is the ability to expose BDC datasources to the MOSS search service. For example, when a user searches for John Smith using MOSS search, the public ERP record for John Smith is inlined with the search results. Clicking on the link in the search results redirects the user to the right page in our ERP system, rather than taking them to a MOSS page.

We don't use MOSS exclusively as an ERP system, but we do use it as a presentation and reporting layer on top of our ERP system.

Answer 4

Building custom webparts in SharePoint would not be the way to go for complex legacy systems.

SharePoint would still give you a lot of mileage if you created a custom navigation provider for the main navigation (based on an xml file for example). This would allow custom asp.net pages to display "like" they were still part of SharePoint, giving the illusion of one all encompassing app.

I think the only reason people want one huge application has more to do with Information Architecture, look and feel and findability than any technical architecture reasons.

A solution that creates separate websites for appropriate applications that are still skinned and linked into the SharePoint information architecture and still searchable from the main interface could solve the "need" for the "Enterprise" part of ERP, while still creating appropriate solutions for what are really separate applications.

The mental model I use is not so much building the apps "in" SharePoint, but creating a 'window" in SharePoint to expose the app.

Answer 5

As someone who has spent the last 15 years writing ERP applications I would say Sharepoint would be an extremely bad choice upon which to build an ERP product.

• The Sharepoint table structures would be very ineffective for producing reports.
• There is very limited capability for validating data.
• There is no native support that I am aware of for maintaining the integrity of relation ships between documents.

Sharepoint works well as a portal into existing LOB applications, not as a platform to build a data-rich application on top of.