其实感觉此篇文章的内容和标题并不十分吻合，但是想不到更好的标题了...
我在2001年毕业之初开始接触Workflow，那个时候是在江西南昌的一家小公司参与政府OA项目的开发，项目组由某NB人士设计了一套数据字典，并开发了一些页面来配置所谓的流程节点共有多少，节点的关系如何(当然没有可视化界面来配置)，就是这样一套东西开始认识Workflow。之后2003年从该公司出来的一个朋友在北京由当时业界小有名气的小马哥带领研发J2EE平台的国产工作流产品，这就是东方易维的Workflow产品，此时已经感觉对工作流的认识已经和国际接轨了，因为据说此产品的架构如何如何先进，研发组成员如何如何NB，在随后的1年时间中，也看到了其他几个创业公司在Workflow领域尝试研发自有产品而进行创业，但是均以失败告终，我心目中也以为Workfow已经灭亡了。再往后到了2004年年底，我所在的微软阵营开始了workflow的风潮，K2产品正是在这个时间进入了中国市场，我碰巧成了中国第二个接受K2产品培训的人，一直到现在都与Workflow走在一起。
由于工作角色的缘故，经常需要寻找新的角度来向客户介绍K2产品，说的难听点：就是要学习利用IT行业内的各种新的概念来忽悠客户，必要时还组团忽悠。对于大型企业来说，近几年最火的IT行业新概念莫过于SOA了(个人从2003年开始就接触SOA这个概念了，一直不明白为什么这么多年过去了IT行业还能持续炒作这个概念)，站在微软阵营来审视SOA总是感觉高度不够，总是感觉需要仰视才行(作为专家在战术上能够提高层次，但是在战略上总是体会不到俯视的感觉)，中国人古语说：知己知彼百战百胜，所以我的角度也只有从了解IBM、Oracle对SOA的阐述开始了：
SOA的实施提倡IT与业务目标的对齐，SOA对业务的影响可以分为以下几类：
- 敏捷性
- 好处：通过更加快速的支持更加灵活的业务流程交付，IT部门为企业提供更好的适应性来应对业务环境的变化，从而形成企业竞争力。快速和灵活其实是矛盾的，但是基于K2产品的流程解决方案同样推崇快速的交付和流程的灵活性，因此企业在应用K2产品时要注意在这两个矛盾点的统一，或者说要建立快速和灵活是矛盾的这个观点来进行实施，从而提高项目实施的成功率
- 坏处：SOA的实施通常会引入一个新实体--卓越中心(center of Excellence,简称COE)，它为企业其他部门提供技术专家。当涉及到COE的资源分配以及要做出关系整个企业的决定时，会引起COE与其他部门的冲突。我所站的层次还没有让我看到卓越中心这样的一种模式，但是理解起来COE不就是企业的IT部门吗？服务可以委派给业务部门自行管理，但是最后的管理操作终究是IT部门的员工在执行，我想这里体现的其实还是灵活性。
- 尴尬：传统上以竖井方式组织的企业可能需要改变其组织结构才能完全享受到面向服务的优势。这种转变复杂且昂贵，并且阻力重重。企业的决策人、企业的CTO、IT架构师必须明白企业变得敏捷意味着什么，以及如何让企业能更好的利用敏捷，尴尬的是这是最难学到的经验。竖井方式的组织、扁平化得组织、矩阵组织，这些概念的正确理解对于我来说又成了一个问题，不过好消息是：基于K2实施流程解决方案从底层来讲是吻合微软平台的SOA框架的，而由于实施范围、程度的分隔，解决方案的实施无需经历这种巨大转变，或者说可以分割这种转变
- 业务流程改进
- 好处：SOA的实施通常包含某些程度的业务流程的重新设计以求带来提升业务操作效率的机会。换个方式来思考：独立实施流程改进，既能吻合整体的SOA架构、又能逐步使企业享受SOA面向服务的优势。之所以能这样思考，原因是SOA的实施总是会依赖于一组技术的，如业务流程的执行引擎以及企业服务总线，而这两项技术都是K2产品的核心竞争力
- 坏处：业务流程的重新设计牵涉层面广，涉及到多层面的利益关系。流程不是IT技术领域的事情，企业决策人、企业的CTO必须理解到项目的核心价值在于对业务流程的重新设计带来的效率提升而不是操作自动化带来的效率提升
- 数据统一性
- 好处：可互操作的服务的引入为创建统一的企业数据模型带来了机会
- 尴尬：这样的统一数据模型往往是不存在的，开发这样的数据模型的结果通常是暴露出企业内部的数据是如何分歧的现状。我不理解的是既然是这个结论，为什么SOA还在鼓吹这方面的特性呢？
- 利用运行系统
- 好处：多数情况下，SOA能利用现有运行系统来实现服务的业务功能，这对于企业意味着现有系统的投资可以得到保护
- 坏处：现有系统并不容易被再包装成服务。即便是简单的如费用报销这样的流程也会涉及到这个问题，如HR系统的集成、财务系统的集成。K2产品提供的SmartObject机制正是用来解决这类问题的