要辨别一个产品是否是BPM产品，我们还是得回到方法和架构上来。正本清源，我们得承认这样一个事实：业务驱动架构，架构驱动技术，而不是相反。判断一个产品是不是真正的BPM，应该从源头往下看，看它的设计目的是不是为了解决业务流程管理，看它的架构是不是从业务流程管理方法论当中推导出来的，是不是符合业务流程管理方法规范，其针对的用户是不是业务用户。而不是看它是否包含了BPM的某些技术特征，也不是看它是不是能做到一些BPM声称应该做到的事情。

一方面，技术的堆砌无法形成架构（技术架构必须指向特定的业务领域，解决特定的业务问题），拼凑出来的所谓架构也无法完整的解决业务问题。能够做到某些事情并不表示它就是解决这类问题的恰当的工具！比如，扳手和锤子都可以用来砸钉子，但扳手本身不是锤子，它们被设计为服务于不同的业务领域。另一方面，同样的方法和架构允许不同的实现技术。例如，如果你的架构就是要解决砸钉子的业务问题，由于某种原因无法使用锤子，必要时，你可以把扳手集成进来，作为一种可能的实现技术。

这表示了两层含义。其一，某种技术手段的加入不能决定或改变产品所针对的业务领域，更不能改变产品的本质。上述例子中的架构是为砸钉子设计的，其设计目标并不会因为产品具备了板手的某些特征就变成了修水管的工具。因为扳手在这里明确的指向砸钉子的业务问题，产品会忽略掉其它与砸钉子无关的扳手的其它特征。其二，不能因为某项技术最终解决了某个业务问题，就认为该项技术就是针对该业务问题的正确工具。上述例子中，在解决砸钉子业务问题的工具里，扳手是一种可能的实现办法，但它仍然是扳手，不能够说因为扳手也可以砸钉子了，所以它根本就是锤子。

回到BPM上来，上述的例子想要表达的意思是：如果一个产品的设计理念和相应的架构不是针对BPM的（例如工作流、OA），即使其加入了符合BPM的某些技术实现特征（例如流程监控、流程生命周期管理），它仍然不是一个BPM产品，它只是能够额外做一些BPM所需的功能（上述例子中的扳手）而已；另一方面，如果一个产品的设计理念和相应的架构是针对BPM的，即使其加入了其它一些技术使得它能够支持诸如工作流或OA的应用，它也不会因此就变成工作流或OA产品。它只是扩展了更多的支持而已。

有人要问，我为何要如此纠结和矫情一个产品到底是不是真正的BPM呢？管它什么产品，只要技术上能解决实际问题不就行了吗？我要如此较真的原因在于，业务驱动架构，架构驱动技术，这是一套符合科学方法的体系：首先提出问题，然后分析问题，最后解决问题。从方法到架构到实现，它是一套自洽的、因果的、能自我发展完善的体系。随着问题的深入和变化，整个体系也会随之修改或者进化，但始终是一套完整的处于相应理论指导下的体系，直到该问题不再有价值时被抛弃或者被另一套更好的体系或理论所替代。在整个产品生命周期中，其目标始终清晰、体系始终完整、进化始终有序。所以，如果一个产品是真正的BPM，意味着该产品会随着整个BPM理论和体系进化，获得稳定的、可靠的升级和改进；而如果它只是披着BPM的马甲，通过勉强的定制或拼凑某些技术手段去解决BPM的问题，则意味着该产品无法针对业务流程解决方案提供有效和持久的改进。因为对一个软件来说，如果一个软件设计最初的目标与应用目标不符，而硬逼迫它向应用目标去变更和定制，该软件必然变成打满补丁的袍子和胡乱嫁接的内衣，总有一天它不但再也无法解决这些业务问题，恐怕连它的本职工作都无法再胜任了。

是，还是不是BPM，真的是问题的关键！自底向上的堆砌技术，随波逐流的往架构上随意嫁接技术，见风使舵的把产品改头换面去制造与业务需求的匹配，终究不是长远之计。