Do not get me wrong, I love SharePoint but I am always objective for my end users and tell the truth about SharePoint. Things that can be done with SharePoint and things were SharePoint is not designed for.
What do you tell your customer about SharePoint and when would you endorse or reject it?
I only address this question after gathering the outcomes that the client is trying to gain by a solution. Then I walk through why SharePoint isn’t a good fit for their needs. For instance, we told a recent client SharePoint wasn’t a good fit because:
- They didn’t need the ability to improve team collaboration by utilizing a team calendar, track tasks or improve communication via announcements.
- They didn’t need to manage documents (meaning utilize check in/out, versioning, retention schedules or to classify documents with metadata) – they only needed to store documents as attachments.
- They were not looking to utilize a content management system – build a wiki, a knowledge base, or Intranet
- They were not needing to automate a business process by building a workflow, where business users could easily modify business rules as the process changes
- They were not looking to enable dynamic ad-hoc creation of teams to work through problems, or easily find experts across the organization, or engage in quick online conversations (social)
- They were not looking to utilize a common company-wide taxonomy to classify information
What they were looking for was a transaction based system to bring visibility into the ideation process and which projects to invest in. They have two boards that meet monthly to determine which projects to invest in – their process is well establish and functions. They just need better visibility into the pipeline of ideas and the ability to track progress along the entire lifecycle of a project (from idea to completion).
Their data model was complex – meaning you would have to customize SharePoint’s UI a great deal with JavaScript and build numerous lists to support it, because of many-to-many relationships, cascading relationships, item level permissions, and column level permissions.
And the amount of transactions would be troublesome over time, requiring additional training and maintenance to ensure list views do not exceed the 5,000 item limit.
I basically get an understanding of what they hope to gain from a solution, then discuss what SharePoint does well, and if you are not needing any of those features, then SharePoint is not a good fit for that solution.
I cannot think that any bank in its right mind should utilize SharePoint for transactional systems. While SharePoint is considered a platform and very powerful, it’s also many layers above what a purely designed banking transactional system is and how it would interact with its database. SharePoint has limitations with regard to line numbers and eventually speed, so in my opinion designing a bank app directly on top of SQL with .NET or another framework would be a better route.
I was also trying to understand this about 3 years back and found some blogs mentioning that SharePoint is not a good candidate to develop Transactional Systems.Â
Does anyone know of any Bank which is using SharePoint for the day-to-day customer transaction?
IMO SharePoint will never replace the existing products/applications compeltely. But it will be used as a One Place content management portal, with capabilities to connect to external systems and show the data within it.
