“当前”的代价

    现在实施SOA的人倾向于使用战术性方式和技术解决战略性的架构问题。结果就是产生了一个架构有效却缺乏对企业的整体价值的实例。实际上，问题域能共享信息和服务的程度越高，对企业的价值也就越高。这是我们进行分析的核心。

    当然并不是说企业级的SOA不是由各个项目构成的，也不是说它无法确定许多问题域，只是说我们的最终目标让它对企业和业务有普遍的价值。

    这个架构在在狭义的微架构或微域层次的SOA中通常具有以下属性：

    · 缺乏安全性。

    · 缺乏访问一般服务的扩展性。

    · 缺乏访问通用数据的扩展性。

    · 缺乏共同的技术方法。

    · 缺乏已验证的扩展性。

    · 缺乏共同的SOA治理策略。

    实际上，如果只是SOA的一个实例，那么解决的通常是具体的战术问题，而不是企业的架构问题。这些狭义域是一个好的开始，但是必须对其进行有效组合才能形成企业范围的解决方案，进而满足企业的需求，而不是仅仅满足一个部门或某一方面业务的需求。

    而且，在这些微域中，安全性通常都会放在最后考虑，或者仅仅在某个特殊的范围内执行。而核心服务和核心数据的共同的安全性策略的缺乏会导致企业变得非常脆弱。因此，要把共同的安全性设备放在重要的优先级上考虑，建立跨越整个企业的安全策略。

    除了安全性，还需要有用于处理服务和信息的通用方法。这通常是从当前的信息系统比如ERP、核心数据库、商务智能、或者核心企业系统API中提取出来的。

    因为有如次众多类型的接口，所以在这些接口之间还需要一个中间层。这个中间层可以十分简陋，但是它能在架构中有序地对服务和信息进行管理。换句话说，这个中间层将高度规范化和结构化的信息绑定到抽象模式中，形成对业务系统来说更逻辑化的抽象模式，比如客户数据、定单信息或产品的呈现。

    虽然这种通用设备具有明显的优势，但是如果这种设备无法提供所需的扩展性，那么一切都等于乌有。在单独一个SOA微域里同样的一个服务可能会有四个系统对其进行访问，如果这个服务同时被企业中所有的150个系统同时访问，那么扩展性和可靠性就会成为很大的问题，而且是战术性技术无法处理的问题。虽然SOA提供了更高程度的重用性和敏捷性，但是服务共享必须符合消费者的服务等级协议（SLA）。

    最后，你还得在其中加入SOA治理。虽然传统的运行时和设计时SOA治理技术对于小型域已经足够了，但是企业范围的SOA治理必须能够在高级事务层上同时管理政策和服务，并且要避免成为瓶颈。

    知道了这些缺陷，你就得每年播出一定的款项来处理上面所列的各种侵蚀公司的问题。比如一个具体的企业，可能要在安全性问题上每年花费50万美元，在通用服务的扩展性问题上花费175万美元，等等。

    这些费用是通过分析每个问题再与当前的架构状态进行比较而得出的，前提是架构已经"完美地优化"过了，这样这些问题才算彻底解决。换句话说就是以当前的状态有多糟糕与可以改善得多好进行对比，以及这将花费我们多少成本。或者说对当前架构和技术方案在微域层次上进行的分析是否能够扩展到企业层次上。