A Workflow-as-a-Service Platform using SilverLight

SnapFlow, a new Workflow-as-a-Service platform, launched its beta program a couple of weeks ago. The platform is built on a Microsoft stack as Gopinath Dhanakodi, VP of Engineering, explains:

When we set out to build SnapFlow in 2008, we picked C# for business layer and SQL Server 2005 for the backend, after briefly considering flex. 

Factors that were considered in their decision of using SilverLight over Flash included:

• Integration to business logic layer
• Time to build
• Learning curve
• Expertise
• Deployment
• Feature set
• Customer Adoption
• Cost

SnapFlow had initially chosen Flash but after a few weeks into the development of their prototype:

[They] were quite disappointed with the progress [they] made. The user interface looked clunky and every simple change was taking a longtime.

At that point they investigated SilverLight in greater details and:

Within a month the team made great progress even though most of our developers were not UI experts. Our team was able to learn and build a fairly sophisticated prototype without any support. 

The Pros include:

• [The] team was able to quickly come up to speed
• [The] progress on the front end twice as fast as flash
• The time based animation.

• The overall integrated design and development environment

The Cons:

• Finding help whenever [they] came across issues.
• Silverlight didn’t have lot of advanced controls
• Lack of support for test automation tools

• Silverlight 2 migration from Silverlight 2 beta brought another unexpected challenge

Gopinath concludes:

We are an early adopter and face many of the standard challenges, that just comes with the territory. Overall we are very happy with the decision we made and I would recommend Silverlight, especially if you have .NET expertise.

InfoQ spoke briefly with their CEO, Samad Wahedi, about the general philosophy of this new PaaS:

We are different from the current Platform-as-a-Service providers. Our main goal is to make workflow as simple as powerpoint. Our target user is Andy the Sales Guy. He is 30 Years old. Works within a small geographically dispersed sales team of 30 members, working for a much larger firm of 500 employees. Has a face book account and is very familiar with the office suite of products.

We decided to start from scratch and question everything. How does Andy think, what would make sense to him, how does he work, what are the problems he is trying to solve and how would he go about solving them… SnapFlow was born.

With that in mind, SnapFlow does not use any of the traditional BPM standards (BPMN or BPEL). Samad explains:

Andy our Sales guys is not a professional process engineer, hence we did not design around BPMN.

The workflow model is centered on activities and actions. The actions decide which activity comes next. This model removes the need from Swim Lanes as users and roles are associated to each activity.

We will continue to build for Andy but we do recognize that we will need to expose more complex capabilities. Our goal is to hide these features from Andy, yet expose it to the power users. This is a challenging balance to achieve, but I believe we are up to the task.

SnapFlow is the first PaaS built on Microsoft technologies and comes fully equipped with Web-based form and workflow designers. It does not use Azure yet, of course, but it provides a good view of what a .NET PaaS would look like. Tim Heuer, SilverLight Program Manager, wrote recently about SnapFlow. His post features a 3 min demo of the product. He notes:

What is cool in one of the features is that once you, the creator of the workflow, are complete, you can then deploy that workflow into your web site or other portal (the demonstration shows using Sharepoint for example). So you could develop a workflow for gathering some data from your web site, and embed the generated Silverlight application on your site with absolutely no coding required on your part.

As the industry is still unsure about how to design BPMN moving forward, let alone define a precise articulation between BPMN and BPEL, SnapFlow seems to be reopening the question of whether it is time to explore alternative BPM models that can bring more users into the design process, not just BPM analysts? It also asks the question whether PaaS should be designed for professional developers which can deploy their solutions on EC2 or Azure Windows Services, or if PaaS should rather focus on more casual users which need to build simple solutions quickly, often for a one-off project? What do you think?