关注IBM的CBM业务组件模型已经很久了，可以看到在系统内SOA化的时候业务组件识别是一个很重要的步骤，系统内的SOA化遵循的方法是流程和功能域->业务组件->业务用例->服务识别的方法和步骤。业务组件之间本身是高内聚，松耦合的一系列业务活动的一个集合体，具有明确的业务含义并实现业务价值，业务组件之间的交互通过服务的方式进行交互使业务组件之间进一步解耦。同时业务组件是一个个可以独立部署的单元或小应用。

　　业务组件比技术组件的粒度更大，也可能比常说的模块的粒度大。对于UI组件，数据访问组件，流程组件，报表组件等我不想将其划入到业务组件的范畴，业务组件不同于技术组件，业务组件有明确的业务含义，在业务组件的识别的时候我们更加关注的是流程和业务功能域，而不是底层的实现细节。

　　对于一个应用系统内的分层，个人考虑是转化为业务系统->业务组件->模块->SCA组件这样的层次，这样考虑的意义是将业务组件可以作为可以独立运行的业务子系统。这会为我们后续的快速的服务集成和应用组装奠定基础。业务组件本身关注的是组件最终向用户提供的业务能力，这个业务能力可以通过业务服务的方式提供出来，也可以通过UI组件服务的方式提供出来。

　　传统的技术组件不会太关注业务，一般采用横向的分层方法，如数据层组件，业务层组件，展现层组件。而业务组件关注业务，采用的纵向分层的方法，关注的是业务系统里面实现的具体的业务域。

　　对于业务组件的识别，我们讲一定要围绕实际业务系统所涉及的真实业务操作和流程。举例拿采购管理来说，我们可以参考业务部门本身岗位或科室的划分，如可能分为招投标科，供应商管理科，采购科等，这些科室划分本身就是业务积累的产物，是有一定参考和借鉴价值的；其次我们可以直接问业务人员，企业的采购范围工作具体涉及到哪几类的工作，有没有企业相关的业务规范和流程可以参考；最后还是需要从流程分析入手，采购管理端到端全流程是如何的，当我们分析端到端全流程的时候，可能就能识别出流程的关键阶段，如采购需求，招投标，订单签订，订单执行这些大的阶段，那么这些大的阶段都可能是待选的业务组件。

　　对于企业现在任何一种类型的业务，业界基本都有可以参考和借鉴的模型，电信领域有eTOM专属模型，eTOM模型本身也分级，模型的最后一级本身就是完全可以参考的业务组件。如果说到具体的业务域也相同，研发领域有IPD,PACE,CMMI相关模型可以参考；供应链领域有SCOR模型可以参考；这些模型本身就有具体的业务架构，这些架构也是我们寻找业务组件的参考。

　　如果是已有的业务系统，完全可以根据现有业务系统的子系统或模块的分析，来讨论和识别业务组件，毕竟对于系统模块本身在划分的时候仍然是遵循了高内聚和送耦合的原则。对于已有业务系统的改造，完全可以将业务系统的业务模块进行进一步的组合或拆分为整理为业务组件。

　　前面讲的是由顶向下的识别业务组件的方法，另外一种方法还是由下而上通过聚合而形成业务组件的方法。在这种方法的时候，我们需要通过业务流程分析或业务调研，将业务系统说涉及的所有业务活动和业务数据都列举出来，然后采用U/C矩阵的方法来分析业务活动和业务数据之间的关系，根据高内聚，松耦合的方法来确认哪些业务活动应该归类到一起，将其定义为一个含多个核心业务活动的业务组件。这种分析和识别业务组件的方法最仔细，工作量也比较大，但是这种方法更加符合科学的识别方法，保证了业务组件识别的准确性。

　　业务组件是高内聚的一类业务活动的集合体，它更加偏向于一个业务流程的组合。所以高端流程->业务组件->底层流程->用例->服务。业务组件粒度如何把握是另外一个关键问题，首先业务组件是一个粗粒度的东西，业务组件本身粒度和我们管理的水平和精细化粒度关系很大。业务组件粒度需要考虑业务组件本身是可以独立运行和部署的，是可以复用的单位，是容易管理的单位；业务组件的粒度大小没有一成不变的度量标准，而是根据管理的需要和可复用的需要。

　　举例来说供应商管理可以是一个业务组件，但是供应商管理里面又设计到基础数据管理，供应商认证，供应商关系维持，供应商考核等几个业务域。那是否该进一步细分到下一层的业务组件。这要考虑两个方面的内容，一个是再拆分后是否仍然可以保持各个业务组件的高内聚和松耦合，其次拆分是否为了复用？如企业业务系统或组件会经常使用到供应商考核业务组件的内容，而不需要供应商管理其它业务内容，如果不拆分可能会导致业务组件粒度粗而无法复用，或者是为了复用大致大量不需要的业务能力外露等问题。

　　业务组件化是一个趋势，通过业务组件化我的期望是慢慢淡化业务系统的概念，将业务系统下沉到业务组件的颗粒度。业务组件本身就是可以独立运行和管理的小业务应用，小业务应用通过服务集成和应用集成，组装来形成满足业务人员使用的业务系统。业务组件之间的交互完全通过服务的方式通过soa总线进行交互。