SOA 的优点、缺点与糟糕之处
简介
IT 战略能够反映出 IT 部门如何来支持企业战略的交付。从根本上来说，这意味着组织需要让他们的 IT 部门高效地进行日常运营并且支持快速、成本低廉地进行新产品和服务的运营。面向服务的体系架构（SOA）在这方面有优势，但并不是十全十美。
下表突出了对 SOA 良好、不良与糟糕的业务影响描述的示例。
SOA 的良好业务影响 SOA 的不良业务影响 SOA 糟糕的业务影响 敏捷性 - SOA 支持更加快速组织结构的改变 - 在每个 转变并不容易 - 转化和组地开发业务流程以及更加轻SOA 的中心都有一个卓越织成为以服务为中心并不松地对业务流程进行改变。中心（COE）。COE 就是一容易。过渡到 SOA 的特点它可以使组织更迅速地适应个控制 SOA 技术开发以及是演变而不是。以孤岛他们业务环境的改变。这就向组织的其他人员提供专的传统形式创建的组织需转化成为实际的市场优势，业知识的新实体。SOA COE 要改变它们的结构，以充分因为它能够使产品和服务比是对任何组织来说都是新利用成为以服务为中心的竞争对手更快速地推向市增加的，并且由此推出，当优势。这种转变是复杂的、场。 它实力雄厚并且在这里所昂贵的，而且从来不缺少这做的决定会影响组织的其种变革的反对者。 他人员时，它的引入可能会导致冲突。 一致性 - 业务与 IT 之间组织权力结构的改变 将服务文化改变 - SOA 不仅仅代更加紧密的合作关系抛开了的所有权和控制权放到业务表着技术的改变。伴随着这阻碍 IT 实现业务需求的传领域中，会改变组织中的权力种改革产生了一个组织的统障碍。业务领域中的服务结构。这样做通常会遭遇来自文化变革，因为它成为了价足迹是一项业务功能，并且那些有维持现状的人的值的驱动。组织必须明白敏用业务术语对其进行了描阻力。 述。它实现的细节是隐藏的。 捷意味着什么以及如何充分开发其自身的敏捷性。糟糕的事实是，这是最难学习的课程之一。 业务流程的改进 - 一般而业务面临的新挑战 - 业务必 言，任何 SOA 与业务流程的须给予 IT 更多的指导。业务再次思考都是相关的。这种线必须对服务及增强行使所业务流程重构对优化组织运有权并对其负责，从而启动开营业务的方式而言是一次机发与变化周期，因为它们将推会。良好的重构工作能够使动这一进程。这不是一种典型业务的运营效率得到显著提的由业务线进行补充的作用，高。 这将会导致不合适的改变。 灵活性 - 在 SOA 中坚持良IT 在变得更简单之前会越来技术本身不会体现价值 - 好的软件工程实践能够提高 越复杂 - 利用一套如业务流专注于基础架构和技术的 IT 对业务需求的响应。缩短程执行引擎和 ESB 的技术来SOA 是很可能失败的。SOA 了产品和服务的上市时间，实现 SOA。把这种技术添加到 举措是建立在比以往更快降低了开发与改变流程的成IT 规划中并不会让它更加简速更低成本地提供业务价本。 单，即使当它的优势远远超过值的承诺之上的。一种过于了它的成本。然而，IT 规划重视技术的 SOA 是不可能更复杂并不意味着它就不能实现该承诺的，因为它们不以更简单的形式出现。这种服会显示出业务人员希望看务的推出让 IT 的复杂性成到的价值。灵活性只有在加为秘密。这些服务的消费者不速运营性业务需求，或者通需要知道服务内部是如何运过支持业务的合理性来降行的。结果，任何发生在后端低操作系统成本时才会 被的的合理化操作，都可以隐藏认为是业务价值。以技术为在服务界面之后。 中心的举措一般不会这样做。 数据统一 - 服务接口可提没有数据视图 - 服务的标准可能无法实现统一 - 使数供统一数据特征的机会，以接口需要统一的数据视图。这据的所有特点一致几乎不使服务接口使用遵照统一的种统一视图通常不存在，并且太可能实现。除了上述问题数据模型的数据。统一在这设法开发统一视图时往往会之外，与 “脏数据” 相关里的意思是通用： 结构 - 元素之间的结构关系是相同的，因此例如地址一贯地包含门牌号、街道、城市、地区和邮政编码。 语义 - 语义是指含义以及数据的使用。数据必须有统一的含义，并且必须以不会产生歧义的方式使用。例如客户的概念可能会在网站上遇到，与帐户所有者形成对比。 格式 - 数据的表现方式很重要。DDMMYYYY 格式的日期不能与 MMDDYYYY 格式混淆。 类型 - 类型是由数据的表现形式以及一套可以执行的行为决定的。 时间 - 时间指的是属性更新的时候。在某些情况下属性会在前端系统进行实时更新。然而一些属性只在定期的批处理时进行更新。 生命周期 - 在什么情况下将数据添加到数据库中，什么时候进行更新，以及什么时候、以什么方式最终从数据库中删除发现组织中的视图非常不同。 的问题也总是存在。处理一致性是设计服务接口面临的巨大挑战之一。尴尬的事实是建立统一的服务接口是一件非常困难的事情。 数据。 运行监控 - 用于支持 SOA 监控复杂性 - 开发一个针对 的技术和原理使对业务流程组织目标提供反馈的业务流的监控更加轻松。这种监控程监控模型是一项需要专业类型支持来自日常运行的反技能的重要工作。 馈。该反馈可用来衡量组织对其战略目标的实现情况如何。 传统的业务流程（BP）与表现逻辑都写入了包含业务逻辑的相同程序。所能希望的最好结果就是至少将不同逻辑类型组合在一起，但是即使这一点也往往难以实现，其结果是很难监控逻辑范畴。例如业务流程只能作为应用程序的一部分来监控，因为它不能被分离出来。 SOA 通常伴随着业务流程执行引擎。这种技术的引入可促进业务流程逻辑被分配到一个点上。在一个点上拥有 BP 使 BP 监控成为可能，而无需在应用逻辑中使用 BP 逻辑。这不是 SOA 的专有技术，但是用于支持 SOA 与来自 SOA 良好软件工程实践规则的技术能够使该技术在 SOA 中更加轻松地得以实现。 利用操作平台 - SOA 使用操技术不匹配 - 在某些情况下可能需要做出改变 - 在某作平台为服务提供业务功并不能轻松地对操作平台进些情况下可能需要改变操能。这意味着对现有系统的行重新打包，原因是业务功能作平台。当需要在 ERP 中投资可通过将其重新包装到结构与需求不匹配。例如，如作出改变时，供应商非常不服务中来使用。 果一个添加新客户的事务在情愿做出改变。如果组织决姓名和地址添加到客户数据定在内部作出变革，服务资库之后有一个提交点，并且在金必须考虑维护成本。 安全数据被添加之后有第二个提交点，那么这两种操作将紧密链接。 结束语
欲使 SOA 获得成功，业务与 IT 必须与他们的目标和目的保持一致。 IT 推动的 SOA 失败的原因是它们被理解为技术的变化，并不对业务产生直接利益。SOA 案例必须加强组织现有的目标和战略，并且将超越以 IT 为中心的方法。这代表了一种文化变革，变革后由业务期望值推动 IT 优先级，再加上业务与 IT 之间的合作文化，就为成功奠定了坚实的基础。
