Advantages of BPM/Workflow and Selection Criteria

Advantages of Business Process Management or Workflow
There are countless advantages to using BPM / Workflow, but here is a list of the most immediate advantages:

* Reduce Cycle Times
* Better Process Visibility
* Increased Accountability
* Smoother task orchestration and hand offs
* Process Standardization
* SOX Compliance


What processes should be selected?

There are many ways to select a process improvement project. First and foremost you need to select a process that is clearly defined and repeatable. If you have to build support for ambiguity and exceptions you will be left with a process that is difficult to use and maintain which will likely lead to a failed adoption. Another consideration is to select a process that uses people to rout and keep track of where a process is at. That orchestration can be difficult to maintain manually and normally does not give the other participants visibility in the current state of an individual request.

I then look for processes that are regulated such as purchase requests, common financial transactions, or IT account provisioning.

You can measure it using traditional Return on Investment (ROI) models, or you can take a more holistic approach and select your projects based on a broad range of criteria including Business Objectives, User Adaptability, and Technology Capabilities. While ROI is very important I think it can be misleading with BPM projects because it fails to include many of the soft return values for things like Process Visibility, Accountability, and less human bottlenecks in the process orchestration.

UserProfileServices Web Service and Adding Links to SharePoint Profile

I really like the MyLinks feature in MOSS. Its one of the Personalization features that really comes in handy for me as I sign into different computers around campus giving demos or presentations. A few weeks ago I posted an article about a t-sql query I have for listing out all of the MyLinks stored in the Shared Service Provider’s database. [Blog Post – Sharepoint MyLinks Listing.html] Up until very recently I hadn’t found a way to programatically add links, but that changed while I was doing some work developing a custom web part that interacts with the User Profiles. One little web service call opened up a whole new group of possabilities.

Userprofileservice – http:///_vti_bin/userprofileservice.asmx

On top of all of the regular methods available for interacting with the user’s profile, it also includes a simple method for adding a link.

UserProfiles.AddLink(AccountName, Title, URL, Group, Privacy Level)

This would make it possible to move links from one SSP to another in the case where you need to rebuild it, or in large deployments with multiple SSPs this can be used for synchronizing links between SSPs.

Another interesting use would be to develop a web part or user control that would let users add links from within a page. Many don’t think about the feature since the MyLinks menu is in the upper right corner of the screen. The user control would let users also link to items from other applications outside of the SharePoint farm. While this isn’t as feature rich as a tool like Delicious, it is useful and secure for internal data.

The SharePoint Cloud

This week while discussing some open development projects the conversation turned towards some architectural topics and what the purpose of SharePoint is. I feel confident in saying that SharePoint can be used for so many different things. It got me to thinking though, what if it were treated as an early cloud platform? The more I thought about it, the more it made sense.

Imagine a large complex organization with a central IT group that provides services to the different business units.

Independently Deployed Apps
Independently deployed applications would include custom development or packaged software applications. There could be many dozens of web, app, and database servers scattered throughout a data center. Each system is managed independently, potentially by different groups.

Setting up or deploying a new application could take weeks as servers are deployed, software is installed, and access rights are given. If the load of an application is too much then it needs to be reviewed to see if another system can be added for load balancing; hopefully its stateless. This can be a very difficult process with custom applications, and impossible with some packaged applications. Since storage is managed independently each system has to be reviewed or monitored separately.

Many companies operate like this to some degree. It can be very expensive to manage which is what brought on the Virtual Server revolution. Virtual servers reduce hardware, but in most environments they do not reduce the number of systems on the network.

SharePoint as a Cloud
SharePoint deployments can be setup to handle 1000s of Site Collections, and provisioning can be automated. Storage can be handled centrally and allocated as needed with support for quotas and standardized usage reports. There are some great mechanisms in place to easily add a new web front end quickly allowing you to scale out a farm to handle higher user loads with the use of a load balancer. Using virtual server technology this can also be automated. There are also administrator tools that make deploying components, site definitions and other solutions relatively easy.

Developing on the SharePoint platform can be a transition, even for .NET developers, but with the addition of the Business Data Catalog, InfoPath Forms Services and the Workflow capabilities there really is a rich feature set to work from. When compared to the two previous versions, I think the current version (WSS 3.0/MOSS) has made development a bit easier since its based on ASP.NET and exposes a familiar object model.

One of the recent developments I find interesting is the technique of using JQuery to interact with SharePoint’s API or any other web service without the need for server code. This can simplify development and project deployment efforts quite a bit, while delivering the same robust functionality.

While developing and delivering applications on top of SharePoint platform may sound far fetched to some, there are already a number of companies delivering vertical solutions and application frameworks including Open Text, Quest Software, and KnowledgeLake.

While the future promise of the cloud is to move that infrastructure and management of those servers outside the walls of your enterprise, I think many of these same concepts can be applied inside those walls now using SharePoint. This could bring easier maintenance, administration, and a substantial cost savings.

Planning for Separate Site Collections

When planning out the site structure of a new SharePoint system, here are five things I take into consideration. Taking these into account during your planning phase will hopefully reduce the amount of rework needed as your system evolves.

Amount of data

If you are expecting a large data set, perhaps you are scanning all supplier invoices and using SharePoint for Content Management, its important to consider the size of a Site Collection and the underlying Content Database from an Administration standpoint. Larger Site Collections and Content DBs require more care and attention along with a more advanced skill set. There have been a number of discussions on what the guidelines are, but I aim to keep Content DBs under 40Gb unless there is a real exception. In this case, the size of the data over rules any of the other answers.

For site collections I expect to grow large, I set them up in a dedicated Content DB right from the start. This saves the trouble having to move it to a different content DB later which can take some time with large sites.

Type and Purpose of the Sites

In a small to mid-sized organization I typically treat sites that support Intranet or department level collaboration a little different than cross-functional or project type sites. Its easy to define the groups around the functional areas and you can reuse those groups in other sites where there is overlap.

In larger organizations sites typically require more isolation. There may be a some interaction between the groups, but not within divisions. In this case the Site collections can be structured to support the organizational boundaries.

Groups Definition and Membership

Groups are defined within the site collection container. If you setup a group called “Management” in Site Collection A, it wouldn’t be available to Site Collection B unless its setup separately. It may not sound like a big deal, but it gets very tedious when you have to manage the same group in multiple places. To make matters worse administrators often take for granted who is in the group based on the name. When setting Site Permissions a group’s members is not directly visible.


Navigation

WSS and MOSS have some good out of the box navigation systems. They are limited though when it comes to trying to tie together multiple Site Collections. There are solutions like defining custom providers but then you are introducing sophisticated customizations that not every company can support. A last ditch option is to manually link to sites and resources but then everything becomes much more difficult to manage.

If it is important to have a consistent horizontal navigation scheme, look to keep as much as possible within a limited number of site collections.

Aggregating or Reusing Data

One of SharePoint’s greatest values is in its ability to support syndication and aggregation of content to deliver it where the users need it. You can aggregate the content using tools like the Content Query Web Part or DataViews. These techniques get a little more complicated when content is in different site collections. Custom code or third party tools are then required to accomplish bring things together.

Feedback?
Agree? Disagree? Let me know, I would love to hear your feedback.

SharePoint MyLinks Listing

MyLinks is an important MOSS feature that is well used in many organizations. Unfortuantely many administrators incorrectly believe that the data is stored in the MySite collections when its actually stored in the Shared Service Provider as part of the user’s shared profile. That is what allows the data to be shared between the different site collections and web apps.

I have on occassion, more than I would care to admit, had to recreate the Shared Service Provider to repair search related issues. Creating a new SSP means that this profile data will be wiped out. In this case I think its a good proactive step to pull a list of the links that are being used. Reviewing the list not only gives the administrator a good idea of how the feature is being used, but it would then be possible to supply the users with a list of the links that need to be setup when the maintenance is complete.

The following script can be used to gather the data. The UserLinks and UserProfile_Full tables are in the Shared Service Provider database.

Select Prof.NTName, Prof.PreferredName, Prof.Email, Link.GroupTitle, Link.Title, Link.URL
From UserLinks Link inner join UserProfile_Full Prof on UL.recordId = Prof.recordID
order by Prof.ntname

Generally speaking it is a bad idea to accomplish something by directly accessing the database. Any changes should definitely be made by the API or through the Web Services supplied. There are a few special cases though where the API doesn’t really help you. One such exception is reviewing this MyLinks data.

SharePoint Requirements

Defining requirements for a SharePoint related project is a very important exercise. Seemingly small changes to the requirements can mean the difference between one with a low level of effort and one with a lot of customization and coding required. Project sponsors new to the platform may also have misconceptions about what can be done, or at least what can be done easily.

Paul Galvin recently posted his presentation from the SharePoint Best Practices session on Defining “Great” SharePoint Requirements.

Anyone with plans for future projects or implementations should check this out.

MS SharePoint Conference 2009

The SharePoint Conference 2009 was officially announced this week. It will take place in Las Vegas from Oct 19-22 and is sure to be a great event. It looks like this year’s event will focus on the upcoming release, but I’m sure there will be value for current users as well.

Last year’s conference was incredible and offered content to management, admins, developers and end users.

Official Website: http://www.mssharepointconference.com/Pages/default.aspx

%d bloggers like this: