“松散耦合”让企业IT更加“灵动”

“死板”的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这一设计理念，对信息系统进行适当的改进，降低不同系统间的依赖程度，变相实现“面向服务的架构”。

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

功能划分相对独立

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

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

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

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

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