那些不容别人批评自己的工作或偏好某一种技术的人可能会在SOA中遇到不少困难。SOA目标之一就是构建灵活、可维护性好、松耦合、与平台无关的软件。要构建这样一个软件就必须从软件开发转向软件工程。简单来说，我们必须从拖曳的工作方式转向计划建模的工作方式。我们必须能够接受协作、同行审查和治理。如果开发人员不喜欢这些东西，他们要么选择改变，要么选择离开。否则他们将成为巨大隐患，并且一直拖后腿。
好了，现在我们来谈谈开发人员的分类。但是在此之前需要强调一下，这里讨论的是分类，而不是个体。在小型企业里，一个开发人员可能会跨越多个分类。在大型企业中，我们可能会看到非常专业化的开发人员工作在架构中的单独一层。最后声明一点：讨论的默认前提是存在一个架构团队，并且各层中存在一定程度的标准与治理。
UI开发人员
如果公司有能力专门化，那么这会是非常棒的一层。这层的开发人员并不需要非常高深的技术。重要的是他们要明白可用性、UI标准和Web界面的最佳实践。这些人可以从模拟开始，与业务部门或业务分析员合作分析各种情况，最终达到一致的结果。这些开发人员必须能用业务用语和业务部门交流，并且能明白商务用户如何使用网络技术进行交互。
业务过程开发人员
在这个业务过程层中有两种截然不同的类型：一种处理业务过程建模，另一种处理业务过程与底层服务和系统的集成。在某些公司里可能会让一个人完成这两项任务，但是更多情况下这会是两个人的工作，因为这两方面需要不同的技能。负责业务过程建模的人甚至可以不是IT人士。某些公司在业务方面设有专门部门，部门中的人主要负责改善并自动化业务过程。(这种公司都是使用6Six Sigma或全员质量管理的公司。)
业务过程集成是一个技术活，它需要Web服务、REST、JMS队列或其它类似的专业知识。负责集成的人是将业务过程与控制业务服务流程和组合业务应用(通常称为编排)的后端技术联系到一起的人。
业务规则开发人员
这一类型有点模糊，并不是所有架构都有一个具体的业务规则层。某些情况下，这些业务规则是在数据层中进行控制的。对于那些有非常动态的业务规则，特别是以客户为中心并且允许终端用户甚至顾客更新规则的公司来说，提取出一个业务规则层来是很有必要的。如果公司有一个业务规则层，并且使用某个工具来管理业务规则，那么这个公司很可能会需要一个技师来管理这一层，就像数据库维护人员维护数据库层一样。在某些情况下，这份工作也可能交给数据库维护人员来做，当然这是灵活的。
不管由谁来做，他们都必须明白这一层的含义并寻找能让终端用户更快地对业务变化做出反应的办法。比如，一个贷款审批程序需要这样的一个特定状态的业务规则：贷款申请人需要具备多少比例的资产才有可能得到审批。这个比例值经常要根据状态进行改动，所以必须能够尽量快地保持更新。最佳的办法是把IT从这个过程中剔除出去，让某个具有授权的特定的人(或系统)按需对这个值进行更新。不管是谁负责这个业务规则，他都必须能够与业务部门和/或业务分析员共同协作，明白变动的频率、许可权限以及各种业务规则所带来的影响。另外，与此相关的还有大量与创建和管理规则相关的日常支出，负责人必须能够权衡利弊并做出决定。
文章来源于领测软件测试网 https://www.ltesting.net/
