“死板”的IT系统

    随着信息技术的不断发展，业务部门对信息系统的依赖程度越来越高，信息系统与业务流程的结合越来越紧密。同时，为了适应日益激烈的市场竞争，业务和流程的调整会越来越多，对IT系统的应变能力提出了更高的要求。

    在企业内部，业务部门对现有信息系统的变更要求层出不穷，但IT部门却由于人员和系统等方面的限制响应相对迟缓。往往是头一个请求还没有满足，下一个变更已经提出，IT系统的改进速度远远跟不上变更需求的提出速度。

    面对比蜗牛还要慢的系统改造过程，业务部门不免抱怨连连，而对此，IT部门也是一肚子委屈——系统改造不比新建，除了要考虑对某项功能的新增和修改，还要考虑和评估对其它功能模块、甚至其它系统产生什么程度的影响。

    由于各部门之间的业务相关性，不同IT系统虽然建设时间有早晚、实现技术有不同，但相互之间的关联度并不低。比方说，修改A系统的a功能，很可能会影响到B系统的b功能、C系统的c功能，“牵一发而动全身”，导致其它系统也跟着“被升级”。

    写过程序的人都知道，给软件打一次“补丁”容易，再想“补丁摞补丁”可就难了。不仅如此，一旦IT系统被迫频繁改造，不但会增加系统的复杂度，降低系统的灵活性，也会给后期运维带来更大挑战。

    长此以往，也难怪在业务部门的眼里，不管是IT系统还是IT部门，都变得越来越“死板”了……

    值得借鉴的SOA

    在速度为王的市场竞争中，IT系统对业务的有力支撑为企业赢得了时间，然而灵动不足的IT系统却在“随需应变”的考验中败下阵来。

    没有哪家企业的流程会永远不变，IT系统应对变化时的笨拙和迟缓，让企业大失所望。

    感受到IT系统的高效率之后，企业更加关注IT系统的灵活性和应对变化的能力。但是很多企业的信息化建设没有经过整体规划，在系统设计和实现上很难满足越来越“善变”的业务需求。

    当SOA（面向服务的架构）理念出现后，企业对敏捷和灵活的渴求找到了实现的契机。然而SOA“落地”情况却并不乐观。

    SOA提倡用“服务”来定义不同的业务应用，利用框架实现服务之间的“整合驱动”和“新旧替换”，让IT系统能更好的适应不断变化的业务需要。

    利用中间件实现SOA，必须将现有的应用系统“打包”，包装成一个符合SOA标准的服务之后，才能在框架下整合运行，这对企业而言初期投入的成本过高，并且短期很难看到效益。

    再加上SOA作为一个新的理念，行业标准不成熟，厂商经验缺乏，失败的风险远大于预期收益，因此，“叫好不叫座”也就成了必然。

    打造“灵动”的IT

    提高IT系统的灵活度，必须降低IT系统与业务和流程之间的耦合度，让它们实现“松散耦和”。

    实际上，SOA只是一个设计原则，体现的是不同应用之间“高内聚、低耦合”的特点。我们完全可以借鉴SOA这一设计理念，对信息系统进行适当的改进，降低不同系统间的依赖程度，变相实现“面向服务的架构”。

    那么，如何才能实现不同系统间“高内聚、低耦合”的架构呢？ 这需要从两方面分别考虑，一方面，功能划分相对独立，另一方面，技术实现互不干扰。

    · 功能划分相对独立

    首先，需求分析要“做透”

    业务上的紧密联系决定了系统间的相关性，只有在需求调研阶段把业务部门的需求“吃透”，理解他们希望系统能够达到的最终目标，才能规划和设计出内部流程紧密、外部关联松散的系统架构。

    前期规划到位之后，各系统间的联系通过标准形式实现，即使现有系统要变更或者新系统要开发，都不会再出现那种“你改我改大家改”的混乱局面。

    其次，流程抽象要“封闭”

    无论业务运营还是系统功能，都离不开业务流程的实现。从流程分析和抽象的角度讲，每个系统都把该做的事做好，把业务变动带来的影响控制在系统内部，尽量减少相互间“被动升级”的现象发生。

    实际工作中的很多变更请求都与流程有关，尤其是那些跨越多个部门、涉及多个人员的流程，如果流程抽象不到位，很容易出现人变流程变的现象，给后期的系统运维造成麻烦。

    最后，组件设计要“内聚”

    在系统设计时，把功能相关的组件和方法放在同一个组件里实现，可以有效减少系统变更时需要改动的范围，出现问题时也更容易跟踪和调试。

    另外，尽量将与流程无关的信息与组件分离，比如产品清单、部门列表等，可以从程序中拆离出来，保存在格式文本或者数据表中，以提高组件的业务无关性，增强内聚程度。

    · 技术实现互不干扰

    首先，通用的基础架构

    通过部署统一的基础架构，可将不同业务系统整合为一个功能完整、流程顺畅的“大IT系统”。通过基础架构实现系统流程的整合和驱动，让每个业务系统像模块一样“插”在框架之上。

    基础架构实现了每个应用系统都会用到的诸如身份验证、权限分配、安全保障等基础性功恩，每个应用系统在开发时不需要再关心这些问题，既加快了开发速度，又避免重复造轮子的浪费。

    其次，实现标准化接口

    尽管需求分析过程尽量保持了系统的相对独立性，但是，由于跨部门的流程存在，系统之间不可避免的存在交叉，因此接口在所难免。

    为了降低系统间的耦合程度，在实现系统交互时应尽量采取通用的标准化接口，比如利用XML文件传输数据、通过Biztalk服务抓取接口文件并进行处理、利用数据库的DTS实现后台数据传输，或者为仅需查询数据的其它系统开放具有只读属性的通用视图，都是很方便实用的方法。

    最后，组件和服务模块化

    随着企业信息化建设的逐步推进，很多业务人员都面临让人头痛的窘状，一笔业务从开始到结束，可能要在三、四个系统里走不同的流程，繁琐又效率低下。

    基础架构和标准化接口的实现，使每一个应用系统都可以进行独立的模块式开发。只要遵循相同的开发标准和规范，代码或者组件的重用变得相对容易，组件和服务业可以轻松的部署在任何一台标准服务器上，以实现灵活的面向服务的架构。

    “松散耦合”的魅力

    企业内部的应用系统越来越多，灵活型却越来越差。IT系统像一头身材巨大的大象，再也踩不出灵活的舞步。在这种情况下，降低不同系统间的耦合程度，提高系统内部的聚合程度，是让IT系统摆脱“死板”的帽子，变得更加“灵动”的有效途径。

    不仅如此，“高内聚、低耦合”的IT架构还具有更多独特的魅力。

    首先，帮助企业降低成本

    只要符合相应的标准，任何服务都可以在SOA架构下连通起来。通过系统功能独立、业务流程抽象、基础架构整合、标准化接口等手段，企业可以把过去投资的信息系统重新整合到新的架构下来，等于节省了重新开发的费用。

    其次，实现IT快速响应

    服务的重复使用和再利用，加快了信息系统相应业务变更请求的速度，缩短了过去需要很长时间才能实现的组织流程重组。IT系统变得“灵动”的同时，也使业务部门能更快速的接近和适应市场。

    再次，降低变更的风险

    由于高内聚、低耦合的特点，每个业务系统之间互不影响，在对某一个模块进行修改和更新的时候，可以不必影响到其它的业务系统，把系统的变更请求封闭在单个应用系统/模块 内，降低了大面积修改现有系统所带来的风险。

    最后，促进IT持续改进

    业务变动和人员更替是避免不了的，通过SOA架构可以支持持续不断的流程改进，局部的业务改造对整个业务系统的影响比较低，不会造成大面积、高风险的系统更替。可以令IT部门用最少的代价实现对业务变更请求的迅速反应。

    “后台松散，前台紧致”是SOA架构的特点，也给我们采用经济实惠的技术手段实现SOA架构提供了可能。事实证明，SOA并不一定与高风险、高投入画等号，“经济适用”的SOA显然比价格高昂的厂商产品更能吸引企业的眼球。