冲突：为什么 IT 和业务不能协调

作者：Aki Iskandar

这无关个人恩怨。但情况越来越糟。

2011 年 9 月发布

在您曾就职的公司中，是否有家公司的 IT 部门和业务部门（即非技术方面的经理和高级职员）真正协调融洽？如果您是在 IT 领域工作，答案将几乎毫无例外地是一个响亮的“否！”。为什么这么多自己编写软件以支持其运营的公司都是这种情况呢？本文将尝试回答这一问题，并简要探讨初步的解决方案。

问题

公司内 IT 阵营和业务阵营之间的紧张是不协调的生命周期的结果。业务生命周期 (BLC) 和软件开发生命周期 (SDLC) 彼此之间完全不同步。尽管十年前情况还不是这样，但到今天基本就都是这种状况了，而且在出现任何起色之前还将继续恶化。

为了便于讨论，我们先从 BLC 和 SDLC 的实用定义谈起，并基于一项共识：即使是非软件销售行业的公司也仍然需要软件来管理其 BLC。也就是说，一家生产、销售小部件并为之提供服务的公司将需要定制软件来支持这些活动和管理其运营。

• BLC：公司围绕一项产品或服务的开发而进行活动的时间周期，自研发至生产、营销，最终到其最后一个单元和/或服务发货和/或交付的时间点。此时，公司可能常常由于市场饱和、产品/服务过时（计划或非计划）或其他环境压力而不再能够达成销售。
• SDLC：Wikipedia 将软件开发生命周期定义为“一种施加于软件产品开发的结构”。与 BLC 类似，SDLC 也表示公司围绕产品（在此特定情况下，指的是软件产品）开发进行某些活动的时间周期。人们创造了各种软件方法来帮助组织创建软件，包括 Agile 和 Waterfall，但不管是哪种情况，通常都有明确定义的起始日期和交付（或完成）日期。

注意：在本文中，软件产品这一术语特指由公司创建的严格供内部使用的产品，而不是为外部销售和分销而创建的产品。

彼时

了解 BLC 与 SDLC 之间关系的关键因素在于其各自的持续时间或时间周期，以及这些持续时间在过去 30 年间是如何变化的。图 1 将这 30 年的时间周期分成 3 个 10 年块，比较了创建大型系统（支持业务活动的软件集合）时的 BLC 和 SDLC 时间周期：

• 1981 - 1990：BLC 平均为 7 年。SDLC 时间周期约为 3 年。结果：业务部门很高兴，因为及时创建软件毫无问题。
• 1991 - 2000：BLC 平均为 3 年。SDLC 时间周期大致保持不变，还是大约 3 年。结果：业务部门满意，但已注意到如果需要返工，几乎没有留给返工的时间。
• 2001 - 目前：BLC 已被压缩到 18 个月，而 SDLC 时间周期仅仅略降至 2.5 年。结果：业务部门完全不满意，事实上，是彻底恼火。永远不能获得需要的结果，起码不在经济可承受的范围内。

此时

问题很明显并且越来越糟糕。业务那边的人员很不安，因为他们根本不相信 IT 部门能够按时交付软件。“你们这些家伙做个软件花的时间太长了，不仅如此，我们拿到手时，还有错误。完全不对劲！”业务经理嚷起来。这种不信任继续加剧，因为业务阵营可以看到，或至少直觉感到，BLC 与 SDLC 之间不一致的恶化趋势，即使他们还不能真正理解。他们不了解软件业务。他们只知道如何生产和销售他们的小部件和服务。

在 IT 那边，情况同样令人沮丧。“这些经理 — 他们希望一切立马就能实现！更糟糕的是，他们希望软件的构建既低廉又迅速，还希望软件能够完美。他们还天天更改要求！”IT 项目经理反驳道。

如今，业务需求变化迅速，因为业务面临着越来越短的 BLC 时间周期。全球竞争、信息更灵通的客户以及其他环境压力要求业务像闪电般行动迅速。一些业务面临着这样的抉择：要么彻底重塑业务，要么关门大吉。稍有一点业务敏锐性就可以看出这一点。

SDLC 未能与 BLC 保持同步，个中原因却不是那么显而易见。技术当然是在以惊人的速度向前发展。IT 部门现在可以任意选择 Java、C#、Python 和 Ruby，这些软件语言都可以缩短编写代码的时间。预打包的框架和软件库使开发人员在实现通常的任务时不必重新发明已有组件。目前强大的软件编辑器甚至可以在数秒钟内编写部分样板代码。如果运用得当，各种 SDLC 方法都有能力压缩 SDLC 时间周期。那么原因何在？这些进步及其赋予开发人员的强大能力，为何不能让 SDLC 时间显著缩短呢？

原因很简单。技术进步带来的 SDLC 时间周期上的任何缩短，已几乎完全被目前的白热化竞争和快速变化的业务环境对软件产生的越来越复杂的要求所抵消。

解决之道

解决方案在哪里？答案并非轻而易举。但是千里之行始于足下。首先要做的是实施良好的企业架构 (EA) 计划。虽然坚实的 EA 计划本身并不能解决此问题，但 EA 将能够大幅抑制 BLC 与 SDLC 之间不一致所造成的负面影响。

在跨部门和孤岛垂直审视组织方面，企业架构师占据着得天独厚的优越地位。从这个角度更容易看清业务阵营与 IT 阵营之间的紧张关系。只有这样，当问题及其范围清晰显现的时候，两边的人员才能够联合起来诊断出台一揽子战略战术混合解决方案来尝试缓解此问题（即不协调的 BLC 和 SDLC 生命周期）的影响。不要误解：这一过程永无止境，需要双方的承诺。EA 是一个业务流程，不是一个技术规范。

总结

结束公司业务部门和 IT 部门之间的冲突没有灵丹妙药。问题是复杂的，并且在不同公司以各种独特的方式宣示自己。希望本文能够对您有所启发，让您找到针对自己的特定环境和团队动态的可行解决方案。最重要的是，该解决方案可从业务阵营和 IT 阵营获得以和谐方式稳定推动组织实现其目标的承诺。

Aki Iskandar 是一位企业家和软件架构师。他曾在 Microsoft、Compuware、Progressive Insurance、Allstate Insurance、KeyBank、Ernst & Young、Charles Schwab 担任顾问，最近他在 PNC Bank 担任企业架构师，是 PNC 的 EA 团队和架构评审委员会的核心成员。他的公司网站地址：www.LambdaSoftware.com