The Blessing & Curse of SharePoint's "Grandma's Attic" - Part 3






Part 1 of this blog series analyzed the runaway success and genesis of Microsoft SharePoint or Microsoft Office SharePoint Server (MOSS). The article outlined the main reasons for the collaborative product’s widespread use and then analyzed its evolution.

Part 2 talked about SharePoint’s typical proven use case scenarios as well as about the product’s shortcomings and points of concern. Due to its workflow management and document management system (DMS) capabilities companies often attempt to use SharePoint as a full-fledged business process management (BPM) platform, but how successfully?



Is SharePoint a Proper BPM Platform?

Some business processes are well suited for process mapping and modeling in SharePoint’s workflow engine (especially if bolstered by Microsft Visio’s diagramming visualization features), such as routine and goal-oriented processes, processes reliant on concrete and unchanging rules, and processes that are not dependent on run-time human judgments. Many informal processes are still done via emails, which, as said in Part 2, is a cumbersome and ineffective content management system. One should thus at least initially consider SharePoint as a replacement for email-based processes that are ubiquitous, intra-enterprise (local), standards-based, and have low barriers to usage.

Microsoft Windows Workflow Foundation (WF)-based SharePoint is useful for project management, document-based collaboration, and internal reporting. If the goal is to reduce the time and the number of steps involved in moving documents and forms sequentially, for simple task assignments between people (e.g., absence request and vacation schedule management), then enterprises can use a process template from SharePoint and modify it fairly easily using Office SharePoint Designer. SharePoint works well with the following Microsoft tools: Office, Outlook/Exchange, InfoPath, Lync, .NET Framework, and .NET-based BPM systems.

Some case management scenarios could benefit from recent SharePoint enhancements, such as in the areas of social computing and collaboration, rich Internet applications (RIAs), connected services, crowdsourcing, Twitter and other social network connectors, information tagging, wikis, etc. There are some content-intensive processes that will eventually come to SharePoint due to its document and records management capabilities, such as loan origination, litigation support, claims processing, interactive marketing, employee self-service, regulatory compliance, contract management, correspondence management, and so on and so forth.

These processes have long been automated in financial services and healthcare organizations. SharePoint has been proven to be a solid solution where there is a need for an audit trail amongst a high number of approvers, although with a local impact (within a single department and/or enterprise).

But not all processes can be mapped easily, such as involved negotiations and collaborations, where participants (so-called “knowledge workers”) are actively controlling the process and affecting process flow on a case-by-case basis. Such processes are often dynamic and unpredictable, but still require process automation.

Another major limitation of SharePoint has been the lack of a nifty visual user interface (UI) for its workflow engine. Microsoft needs to overcome this limitation in the near future, perhaps by more natively embedding Visio into SharePoint, to ensure strong adoption by teams that want to configure workflows and model processes easily, with little or no IT staff intervention.

Gartner’s 2009 report estimates that between 80 to 90 percent of all company processes are “knowledge worker” processes. In these processes, documents are produced as an end-result of the process and might contain varied information, which is not a good fit for SharePoint. SharePoint is also inadequate for high case volumes, a high number of process initiators, and intra-enterprise, where database integration and downstream data requirements are prevalent.

Despite a number of new capabilities applicable to case management in SharePoint 2010, most case management applications utilizing SharePoint will still require a proper case management BPM platform tightly integrated with SharePoint for appropriate process management, user experience, task management, and auditing. Figure 1 illustrates how SharePoint’s workflow stacks up against full-fledged BPM platforms. In addition, the blog posts from Chris Adams of Ultimus and Jim Sinur of Gartner talk about how far SharePoint can really go when it comes to BPM.

sp-and-bpm-scorecard.png


Figure 1


Third-Party Help Often Necessary

As said in Part 1, SharePoint has shown significant value in many enterprises by offering team Web sites and intranets for group-oriented collaboration. Another "sweet spot" for SharePoint has been its document management system (DMS), which has become a document versioning standard in many companies.

Still, for transactional processes and inter-application data and processes integration companies might want to use Microsoft BizTalk Server as an enterprise service bus (ESB). On its own, SharePoint often needs integration to other portals, lightweight directory access protocol (LDAP) directories, and other DMS and BPM systems. As mentioned in Part 2, security, auditability, and system management capabilities are also suspect in heterogeneous inter-enterprise environments.

Indeed, many of SharePoint’s shortcomings in terms of BPM, business intelligence (BI), and social platform capabilities may require developers or independent software vendors (ISVs) to build out these capabilities. SharePoint supports several development tools for building enterprise applications on its foundation, including Visual Studio for high-end development and FrontPage for rapid Web page design and development.

Many partners have stepped up to supplement SharePoint's capabilities, to plug known issues or functional gaps, and to build vertical solutions on top of SharePoint. There have been a slew of BPM applications built on SharePoint products and technologies as these resources have become more widely known and used. Figure 2 below shows how Ultimus BPM Suite [evaluate this product] uses SharePoint and how exactly it is augmenting SharePoint for a full-fledged BPM use.

sp-and-bpm.png


Figure 2


Other viable .NET BPM suite options include AgilePoint, Deltascheme, K2, Nintex, Global 360, cShare, AuraPortal, and W4.  As for full-fledged enterprise content management (ECM) platform options after the discontinuation of Microsoft Interactive Media Manager (IMM) in 2009, Open Text offers a number of SharePoint-based content products for legal, case management, and life science companies, as CSC FirstPoint is doing for life sciences. For a better idea on SharePoint’s popularity amongst ISV’s, here is the long list of exhibitors at the SharePoint Technology Conference in Boston in June 2011.

Recommendations

At this stage, as a “Jack of all trades, master of none” toolset, SharePoint cannot really provide BPM, ECM, BI, and social networking infrastructure on its own. SharePoint is an excellent solution for document management (except for production imaging and document composition), application portals, ad-hoc internal team collaboration, and simple document-based workflows (but not for more complex and dynamic workflows). To give devil its due, Microsoft SharePoint’s set of functionality in an infrastructure approach has changed the way that organizations are thinking about content management, portal, and collaboration (to at least “wean themselves off the email treadmill”).

However, companies must balance the breadth and depth of particular SharePoint functionality with the options offered by alternative third-party applications (many of which may have functionality that is much deeper or more tailored for a particular industry than SharePoint). Companies should check out the available third-party tools for SharePoint if they want to add some sophisticated BPM or ECM capabilities to their SharePoint implementation while spending their SharePoint development effort on something that the tool does well. They should do that with flexibility, security, and federation in mind, rather than pursuing a vast (and suboptimal) monolithic infrastructure.

Depending on the company’s process needs, either a SharePoint workflow or a BPM platform may be the best choice.  It is important to choose the right tool for the job. Companies should do their homework to understand the difference between mere workflow engines and BPM suites, and match the benefits of each platform against their process needs.

The devil is always in the details, and companies should clearly delineate where SharePoint should or should not be used. In many areas they will need to further customize and develop SharePoint’s capabilities, but should that be done in-house or with help from (astute and pricey) professional service firms? They should think thoroughly about how deeply they will customize as they risk rebuilding and new development undertakings as new SharePoint releases come out.

In some cases, adding these hefty development times and costs for new functionality and vertical requirements on top of a SharePoint environment may ironically negate the benefits that many organizations were seeking when they chose SharePoint in the first place: simplicity and low cost. In contrast, best-of-breed ECM and BPM systems have proven themselves over two decades for delivering highly scalable and complex business applications. Moreover, migrating content from SharePoint to other ECM applications or vice versa is neither easy nor cheap. While ECM and BPM vendors might tout their integration with SharePoint, often times it is just replicating files at a later stage rather than real-time synchronous updates. Anyone’s integration claims must be able to demonstrate "one version of the truth."

Chris Adams, Vice President of Product and Technology at Ultimus, provided the following closing comments from what he sees with his customers:
"SharePoint adoption inside a company requires a SharePoint “evangelist”.  This evangelist plays of the role of ensuring SharePoint is part of all IT projects (in some fashion or another).  I have seen that if there is no evangelist, then workers will rely on what they already know to work, such as emails, Excel, etc. I have seen this “evangelist” role performed either by a CIO who has the authority to impact/shape all IT projects or an IT manager who receives business requests and then chooses to use SharePoint to craft the solution.

Lastly, at the executive level, executives want fast and EASY ways to complete their work (I stress EASY here).  I have seen IT solutions built off of SharePoint be rejected at the executive level (either because the Web sites were too complex to use or the info in SharePoint was too hard to find).  Despite the fact that SharePoint is arguably today’s “chicken soup” to problems, unless used in the correct way, SharePoint technologies can hinder conducting business.  This point is true for all apps in general, but is also true for SharePoint."

Having recently attended the SPTechCon multi-day event in Boston with a rich array of speakers, topics, and SharePoint enthusiasts and sponsoring vendors, I am sure that this series has only scratched the surface on what SharePoint is (not). Dear readers, what are your views, comments, and opinions about Microsoft’s process and content collaboration platform strategy? Should companies rely more on Microsoft or pursue other technology avenues as required? Your experiences with the above-mentioned vendors and their enterprise solutions are also welcome.

 
comments powered by Disqus