Gopinath总结到：

  我们是先驱者，遇到了数不胜数的挑战，这些挑战都伴随着领域问题。总而言之，我们对自己的决定感到满意，因此我强烈推荐Silverlight，尤其是你有.NET经验。 

  我们不同于当前的平台即服务（Platform-as-a-Service）供应商。我们主要的目标是让工作流变得像powerpoint一样简单，目标用户是Andy（一个销售人员），他今年30岁，工作在一个分散的拥有30个成员的销售团队中，他们主要为一些更大的公司服务（通常都有500多名员工）。他有一个facebook帐号，对office产品套件非常熟悉。

  我们决定从头开始并对不了解的一切问题追根问底。Andy是怎么想的，对他来说什么东西才有意义，他是如何工作的，他正在解决什么问题，如何解决的等等。就这样，SnapFlow诞生了。

  综上所述，SnapFlow没有使用任何传统的BPM标准（BPMN或BPEL）。

  Samad说到：

  销售员Andy并不是专业的流程工程师，因此我们并没有围绕BPMN进行设计。

  我们的工作流模型以活动（activity）和行为（action）为中心。行为决定了接下来执行哪个活动。该模型并没有使用泳道（Swim Lanes），因为用户与角色都关联到每个活动上了。

  我们将继续根据Andy来构建系统，但同时我们也认识到还需要增加更多复杂的功能。我们的目标是对Andy隐藏这些特性，仅仅将其开放给拥有更高权限的用户。这非常有挑战性，但我相信我们能够搞定。

  SnapFlow是首个构建在微软技术之上的PaaS，同时具备完整的基于Web的表单与工作流设计器。当然它还没有使用Azure，但却向我们展示了.NET PaaS的样子。SilverLight程序经理Tim Heuer最近发表了一些关于SnapFlow的文章，他的文章主要根据产品的一个三分钟演示而来。他说到：

  其中一个很酷的特性就是一旦工作流的创建者创建完毕后，他还可以将该工作流部署到Web站点或是其他portal（比如演示中就使用了Sharepoint）上，这样我们就可以使用工作流从站点上收集一些数据并将Silverlight应用嵌入到站点中，整个过程无需额外的编码。

  业界对如何设计BPMN还不是很清楚，更别提在BPMN和BPEL之间定义精准的清晰度了，SnapFlow似乎重提了这个话题：现在是探索BPM模型替代者的时候么——让更多的用户参与到设计过程，而不仅仅是BPM分析师。它还抛出了这个问题：PaaS的目标是专业的开发者（他们可以将其解决方案部署到EC2或是Azure Windows Services上）还是普通的用户呢（他们需要快速构建简单的应用，通常是一次性的项目）？你怎么看待这个问题？

查看英文原文：A Workflow-as-a-Service Platform using SilverLight