SharePoint Again!

SharePoint is a huge success story for Microsoft. No other product from their stack in recent history had evoked such overwhelming responses from users worldwide. It solves the problem it was created to solve exceptionally well. Move content away from shared folders. Along come the cool collaboration features – shared document libraries, calendars, meeting sites, tasks, announcements, workflows etc. etc. WSS by itself gives an organization enough features to build a highly collaborative Intranet. And that too for free!

Upgrade to MOSS and you get browser based InfoPath forms, advanced search capabilities, IRM (Information Rights Management), Records Management Analytics and far too many more features. To be honest, the list is comparable to any leading ECM/BPM product out there. It is a salesman’s delight. It ticks at least as much features as a FileNet or a Documentum in an ECM/BPM questionnaire. And it costs way lower than what an IBM or EMC would quote for a similar set of requirements. Great stuff!

Unfortunately, the devil is in the details. SharePoint thrives in a very simplistic world. One can build a simple form based workflow in minutes with SharePoint and InfoPath. The catch here is that the workflow has to be simple (I mean very simple) and linear. What one need to do is to build a simple form template in InfoPath and publish to a document/form library in SharePoint and create a workflow using SharePoint Designer (This is also free!)

But real life is not that simple. If one has to build an expense approval workflow that resembles reality, life gets complicated (I mean very complicated). Let us look at a sample scenario like the one below:
- User fills an expense report form
- Attaches supporting documents
- On submit of the form, it is sent to the user’s manager for approval
- The manager updates some of the form information, adds/modifies the attachments, and approves/rejects the form with comments

To make the solution easier, let us assume that MOSS and InfoPath are used. Even then, to create the workflow one needs good amount of SharePoint and InfoPath programming knowledge. As far as I know, you can’t get this done without writing .Net code or using third party components.

One of the issues that the programmer would stumble upon is with attachments. InfoPath forms embed the attachment files inside the form making them inaccessible to SharePoint workflows. So, some amount of InfoPath code has to be written to extract the attachments and save them to SharePoint document libraries. The workflow has to be created with Visual Studio by a programmer and not with SharePoint Designer by an analyst since custom programming is involved. The other major issue is creating workflow tasks for the user’s manager. Finding the user’s manager from Active Directory will need some code effort. And the most important of them all, propagating the form information to the workflow task would require abundant amounts of thoughts, patience, and creativity. Only expert programmers can handle it.

So, it is not easy to implement a very simple real life scenario in SharePoint. But it is not impossible. Using SharePoint for ECM/BPM needs will require skilled implementers. That’s all! Let us hope that Microsoft will make SharePoint 2010 a better ECM/BPM platform.

IT Services 2.0 (Part II of II)

Service 2.0 is all about the service provider getting oriented towards the customers’ business success.  So, the service basket should consist of items that are easily understood and adapted by most stakeholders at the customer organization. 

The Ingredients

I would broadly organize the ingredients into four categories:

• Building repeatable solutions
• Leverage SaaS
• Ketchup applications
• Consulting services

Repeatable solutions

The talk around repeatable solutions is not new. I know that every service provider talked about it in the past, are talking now, and will talk in the future. There are some good examples of such solutions out there. Ideally, these solution offerings should package technology, domain knowledge, and best practice usage in a healthy mix. Going forward, the vendors will increasingly interact with the business stake holders as against just the IT personnel. The pattern of the discussions will revolve more around the business benefits than just the IT skills. So, it is imperative that the vendors talk and preferably demonstrate solutions that could impress the business stakeholders. For example, selling the concepts of mortgage workflow solutions or accounts payables automation solutions will be more acceptable than the effort to impress upon the capabilities of a FileNet, Documentum or Lombardi. The technology names can be used to drive positioning advantages, but what needs to be sold is a solution for a business problem. 

SaaS

In the recent years SaaS as a delivery model gained tremendous momentum. The smaller to medium organizations embraced SaaS a lot more than their bigger counterparts. As a delivery model SaaS is here to stay, but I am not fully convinced that it will totally replace the conventional IT infrastructure in enterprises. It makes sense for some service providers to invest in a SaaS infrastructure of their own and use it as a delivery channel as well as a pre-sales tool. The benefits of SaaS as a solution delivery channel are widely discussed and accepted. As a pre-sales tool, this model holds tremendous potential as well. A potential customer of an enterprise solution can experience a solution before actually deciding on investing on the infrastructure. And this is not merely being on the other side of the table during a vendor demo, but by signing up for the service on a pilot basis for as much time as s/he wishes. This way, having a SaaS infrastructure actually locks the customer in and obviously the vendor does not have to worry about a prolonged sales cycle.

Ketchup Applications

Ketchups are consumed along with a main course dish and are used to make the consumption process better. In the software world as well, ketchup applications can be used to enhance the functionality and usability of enterprise software products. For example, a web based process analyzer reports viewer for FileNet, a scanning plug-in for Alfresco, or a TIFF viewer with annotation capabilities for SharePoint can add tremendous value to these platforms. Service 2.0 vendors can package reusable solution code into such ketchup applications to speedup implementation timeframe, gain competitive advantages during the sales process, and fill a lot of gaps that the enterprise product vendors left out. Ketchup applications can be licensed to customers along with a service assignment or separately allowing the vendor to bring in revenues independent of the service contract.

Consulting

Service 2.0 companies could focus a lot of building the technology and domain expertise and using it for consulting assignments. Technology consulting is mostly about understanding the customer’s business and coming up with a strategy for information technology applications. Many organizations engage consultants to understand and document their pain points and come up with high level solution strategies. In today’s world it is difficult to zero-in on a particular technology or vendor to solve a set of business problems. Many times customers decide on technologies or vendors based on criteria other than the best suited ones. This could be because they could get biased by vendors or pressure groups. Sometimes the required levels of competence may not exist in the customer organization to take technology decisions. Service 2.0 vendors could provide consulting services to their customers in understanding the strengths and weaknesses of technologies when it comes to solving the business problem in hand. These services will assist its customers in choosing optimal software application solutions for their business needs.

A SharePoint Affair

It was love at first sight! Way back in 2004, when I first came across SharePoint, the techie inside me loved it. It had almost all the features to make you drool. It definitely was the best thing ever after iodized salt.

To me, SharePoint is WSS (Windows SharePoint Services) since I was looking everything from a content/document management angle. The portal is good and extremely useful, but I couldn’t understand why Microsoft would give away 80% of the features free (WSS) and charge only for the portal application (SPS). I didn’t scratch my head too much on the business acumen of Steve Ballmer and Co., and decided to see if I could commercialize document management on WSS.

I was absolutely convinced that WSS and SPS are great tools for the knowledge industry. The thrust of the SharePoint platform was on collaboration, and it often meets the expectations of such a requirement. But it required sheer determination and creative thinking to give a facelift to such a product to suit the requirements of a transactional business. 

The business motivations of such an adventure were simple. The idea was to get small and medium businesses on to a very cost effective document management system. WSS was a free download on to a Windows 2003 server and the only investment for the customer would be the server. If the volumes were nominal, MSDE would do the database job. It would definitely be the killer app.

What additions will make WSS a document management system? The ability to bind documents together in a folder, access control at the folder and document level, ability to attach metadata at folder and document levels, a TIFF viewer, and an imaging front-end would do the job, according to the thought process at that time. The initial technical discussions were about what WSS offered and what were to be built on top of it to achieve the features mentioned above. The freebies were sites, lists, integrated authentication, version control, document libraries, metadata definition, access control at document library level etc. The folder concept in WSS 2.0 was a joke and had to be custom built again, and access control was available only at the document library or list level and not at the individual row and column level.

Peeling the technical layers of the SharePoint onion was a revelation and the enthusiasm started treading in the opposite direction as and when more and more of the technology was excavated. The biggest disappointment was the performance of the system. We had to rely heavily on CAML based queries and it didn’t quite meet the expectations of performance. After a while it seemed quite unviable to go ahead with the adventure and we decided to pull the plug.

Still I kept a close watch on the SharePoint developments. WSS 3.0 has many welcome additions, but it seems to me that it remains a tough soil to grow a transactional document management system. But at the same time WSS and MOSS have endeared themselves to the technology enthusiasts, analysts and the collaboration clientele mainly from the knowledge industry.