印度外包IT业务影响SAP？-巨人网络通讯

印度外包IT业务影响SAP？

　　在今天，竞争激烈、变化越来越快的全球化商业环境中，传统企业观受到严重挑战，如何灵活快速适应变化、创新求变，成为企业生存和发展的头等大事。在业务敏捷性的实践中，SOA正成长为IT促进业务提高的转移范式，从设计原则、架构范式以及技术、标准和产品中实践着它面向服务架构的伟大使命。

　　业务敏捷性向业务与IT两个世界发起挑战

　　事实上，许多企业都无法实现“业务敏捷”。他们的工作人员各自行动，计算机系统又相互隔离，不能协同工作：一方面是由IT部门负责的信息系统是，另外一方面则是调整IT系统所需要必要时间和成本。受这二者的制约，企业变化要么时机已逝，要么得不偿失。因此，业务方作为利润中心，总是抱怨IT每年都要花很多钱，不仅不能获得良好的投资回报，也不能帮助建立战略性的竞争优势。而IT方作为成本中心，往往怨恨自己没有得到应有的重视，资金不够、加班加点。这种现象的出现也就不足为奇。

　　到底应如何看待IT与业务之间的关系?

　　首先，业务活动是由业务人员和信息系统共同完成的，业务人员执行人工活动，比如拜访客户、输入订单和客户资料、做出商务决策等等，而信息系统执行各种自动化活动，包括商业逻辑、业务规则、管理业务数据，提供界面连接人员和信息系统。所以IT是业务的一个重要组成部分。

　　其次，业务方决定人工活动和自动化活动的需求，管理人工活动，但是他们往往不具备必要的技术能力来建立、维护和运营那些支持自动化活动的信息系统，这些工作被委托给自己的IT部门或者外包。所以IT要服务于企业战略，为业务建立竞争优势，帮助业务快速应变和创新求变。

　　可见，业务敏捷性首先需要的是一个灵活的业务模式(Business Model)，业务自身不灵活，想改变却心有余而力不足，IT 再能干也是干着急。其次，需要IT的敏捷性，也就是说一个当业务改变的时候，那些自动化活动说变就变，随业务的变化而变化，花的时间少，花的人力物力也少。这种IT的灵活性，对IT的所有方面都提出了挑战，从架构、方法论、技术、产品，到过程、成熟度和管控。最后，还需要IT与业务这对“冤家”之间的有效沟通与亲密合作。

　　这很不容易，业务与IT来自两个不同的世界，看世界的方式不同，所使用的“语言”也不同。大多数时候，业务不愿意花足够的时间在 IT 上，反过来，IT也不愿意花足够的时间去理解业务。他们把更多的心思放在技术上，有时候甚至为技术而技术，忘了IT是为业务和战略服务的。因此，业务敏捷性同时向业务和IT两个世界发起挑战，沟通和协调成为必然。

　　SOA畅行业务与IT两个世界

　　业务架构描述业务世界：从业务领域、业务组件、业务对象，到业务服务、业务流程、业务规则……IT架构描述IT世界：从应用、数据、集成、安全、基础设施(包括服务器、存储、网络)，到IT运营，全面覆盖……两个“世界”共同服务于企业，而如何实现两个世界协作则成为企业战略目标实现的关键!

　　SOA正是沟通两个“世界”使命的承担者，它提出了架构管控的概念，从角色、活动、职责，到协作、审批和监管的框架，保证有一个游戏规则来让这些东西真正地服务于企业的战略和目标。

　　然而，大多数企业对自己的业务模型仍停留在自发状态，缺乏业务方面的严谨企业架构实践，更谈不上业务与IT的沟通，这直接带来两个问题：

　　一是业务优化、应变和创新缺乏形式化和数字化的基础，很容易靠感觉办事。这种“拍脑袋”应变策略，往往带来很多问题，有些时候，这些问题的原因被强加到IT的头上，而使IT承担了不应承担的责任。

　　二是业务和IT之间缺乏“可追溯性”(Tracability)。在将业务的需求映射到IT的时候，使用模糊的自然语言，容易造成翻译后的失真和变形。同时，细粒度的操作层次所定义的需求，受到变化的冲击大而快。这最终导致业务和IT在进行需求映射，尤其是在需求发生变化时，很难保证好的可追溯性，从而导致业务的需求无法准确地映射到IT，业务需求的变化很难被快速地定位到IT。

　　传统模式需要引入新的IT架构范式和抽象层次，从而为企业的业务活动和流程提供多系统相互协作的IT支持，SOA则恰好扮演了这个角色。

　　SOA为业务与IT两个世界带来什么?

　　SOA究竟在实现业务和IT两个世界的沟通中体现了怎样的价值?笔者认为：

　　① SOA在业务与IT之间增加了一个新的抽象层次，就是“业务层次上的契约”，用来描述不同的业务组件(或者业务对象)之间交互的接口。这就是SOA通常所说的“服务”。

　　其中包括功能接口、服务质量约定(Service Level Agreement)和业务策略等。它们是用于组件化地对业务建模，通常其粒度比技术层次上的对象或者组件接口要粗，而业务流程就是通过将这些服务编排在一起得到的。当业务流程发生变化时，有些变化通过改变服务的配置(如业务策略)来完成，有些变化通过重新组装已有服务来完成，有些变化要用到现有服务之外的业务功能，则需要外购或者开发少量新服务，然后重新组装。

　　业务组件化建模所得到的服务模型，解耦了业务架构和IT架构，提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性，即在服务定义不变的情况下，业务和IT可以独立地演变，带来很好的灵活性。

　　② SOA建立了一个新的集成架构，负责将遗留系统和新建的系统连通起来，让不同技术世界的服务组件可以相互以Web服务接口为中介来松散耦合地交互。

　　这牵涉到各种协议、API、消息格式的转换、服务端点的发现和绑定、消息的路由、服务质量的保证、服务策略的实施等等。SOA继承了过去EAI (Enterprise Application Integration)和MOM(Message Oriented Middleware)的最佳实践，比如“企业服务总线”(Enterprise Service Bus，ESB)作为一种架构风格元素，用于在分布式环境下提供松散耦合的集成基础，但是SOA使用了Web服务，建立在标准和开放技术的基础上，而不是私有的技术、标准和方式。新的集成架构还引入Service Registry，ESB与之合作提供服务的动态发现和绑定。ESB的实现通常会利用已有的消息中间件。

　　③ SOA通常会创建一个数据服务层，集成EII(Enterprise Information Integration)的技术和最佳实践。

　　这个集成架构，要确保所有服务和应用在开发之时，能够跟其他的应用和服务集成，不管它们今天是否存在，互联互通、相互集成、“开发即集成”是SOA对技术层面的基本要求。

　　值得提醒的是，SOA一个很重要的设计原则ESB是基于“服务”的分布式集成，很多基于“细粒度”的接口和消息集成，并不符合SOA的设计原则，也将导致可能的性能问题。

　　④ 在应用架构方面，新的SOA技术和标准，比如SCA/SDO允许你采用平台和语言相关的方式实现，但是组件实现的服务接口则是标准化的。

　　复合应用(Composite Application)建立在其他应用的基础上，通过将来自Portal应用的人工活动、B2B的合作伙伴应用、数据服务和本地业务服务来快速形成新应用。基于BPEL等标准的流程引擎，使用“声明式”的方式来将服务编排在一起，在复合应用中起着重要的作用。这些都是在已有的应用平台上增加而来，比如IBM的WebSphere Process Server支持SCA/SDO和BPEL，它是在IBM的J2EE服务器WebSphere Application Server的基础上实现的。

　　我们前面所设计的服务，实现它们的IT组件就表现为一些SCA组件，或者EJB、POJO组件，而业务流程则在IT层次上实现为BPEL或者一些SCA组件。这些服务和流程都有自己基于标准的形式化描述，保存在服务注册库(Service Registry)中。

　　⑤ SOA Governance被用来在整个服务的生命中期中，将来自业务和IT的人协调起来，让他们各司其职，有章可循，相互协作。

　　在实现层面，这通常需要借助于Service Registry来管理服务的生命周期，同时，我们需要扩展现有的管理产品，从基础设施、应用和组件的管理，延伸到服务、流程和业务活动和业务绩效的管理。在这个基础上，建立数字化的服务和流程优化策略，从而使得IT可以主动地向业务提供业务优化和调整的支持。

　　辨明SOA认识的四个误区

　　简单的说，SOA的产生遵循了这样的逻辑主线：业务敏捷性需要一个灵活的业务模型，业务模型需要一个灵活的IT来支持。同时，良好的业务建模，IT与业务之间的对齐和互动变得很重要，所以基于企业架构的实践，横贯业务和技术的SOA管控被用来保证SOA转型的成功。

　　一个灵活的IT需要遵循必要的设计原则，比如关注点分离、松散耦合，而这些设计原则结合具体技术形式体现在IT架构中，将会形成自己的架构风格，这当然也由一些架构元素支撑，比如ESB，服务注册库等。这些架构元素多多少少都能够从过去的IT当中找到些影子，但是，它们使用新技术，建构在开放标准和技术的基础上，融合和继承了过去的实践成果，也同时容易产生误解：

　　误解一：SOA = ESB

　　ESB只是SOA架构中的一个元素，负责转换、路由和服务质量等。看待SOA，应该从业务、技术、管控等不同的角度来看待。

　　误解二：SOA = Web Service

　　Web Service通常指基于SOAP/HTTP的Web服务，这些服务是实现SOA中所定义服务的一种技术形式。Web Service提供了分布式环境下卓越的互操作能力。