在当今的互联网时代，企业开发模式正面临着重大变革。互联网企业的敏捷开发模式大获成功，让传统企业的“瀑布式”开发显得有些“明日黄花蝶也愁”。而企业级业务架构这种看似耗时耗力的方法，也让很多人望而生畏。但其实，业务架构与敏捷并非不能兼容，今天我们就来探讨一下这个问题。
一、传说中和现实中的双模开发
“天下武功唯快不破”，这句话在互联网时代的竞争中可谓真理。一个产品的成功，可能就取决于比对手早一周甚至两三天上市。产品创新速度和市场响应速度越来越受企业重视，但这似乎是大企业特别是传统行业大企业的短板。
为了让“大象”也能跳舞，各种软件过程和项目管理新概念不断涌现。比如，Gartner 在 2014 年提出了“双模开发”，即敏态加稳态。可预见的业务采用传统瀑布式开发，也就是稳态；探索性的业务采用敏捷开发，也就是敏态。2015 年的一项调研显示，很多企业都在实施或准备实施双模 IT。
不过，这里所说的敏捷开发，未必是真正意义上的敏捷开发。很多时候，它只是为了应对特殊需求，打破常规，省略管理环节，快速上线。比如，市场或领导催着一个项目下个月甚至下周就要上线。在这种情况下，开发者经常在稳态和敏态之间来回切换。
那么，经过业务架构设计、应用业务模型驱动的开发会不会显得很“笨重”呢？会不会与敏态不兼容呢？要回答这个问题，我们先来看看正宗的敏捷开发和特事特办的“敏捷”有什么不同。
二、正宗的敏捷开发
说到正宗的敏捷开发，就不得不提“敏捷宣言”提出的四个核心价值：个体和互动优于流程和工具、工作的软件优于详尽的文档、客户合作优于合同谈判、响应变化优于遵循计划。
工作的软件优于详尽的文档敏捷开发常被认为不重视文档，但其实它不是不需要文档，而是不需要过于详尽的文档。因为过于详尽的文档会浪费很多精力，用处却不大。对于开发人员来说，整洁的代码加上详尽的注释，比高质量的需求文档更能让人清楚软件的结构。不过，敏捷开发也需要有一份概括性的文档作为项目总体目标。
业务模型也应该具备一定的简洁性，才能与敏捷开发兼容。在企业级转型初期，不适合采用这种简洁的方式，但转型完成后，就可以利用业务模型快速应用架构工具。业务模型不能承载太多业务细节，要保持适当的抽象度，以便解释清楚任务对数据实体的创建和变更，划分任务及组件的边界。这样，模型本身就具备快速应用的潜质，就像一张“作战地图”，可以更快地看清项目的范围、涉及的组件和团队以及潜在的影响。
敏捷不能不顾一切，更不能牺牲企业级架构的一致性，否则就成了盲目行为。不管多紧急，都不能不看“地图”就冲向战场。
个体和互动优于流程和工具模型分析和调整需要过程，企业级庞大的模型体系也需要工具支持，这似乎与敏捷的核心价值有冲突。但其实，敏捷开发的速度来自于节省不必要的步骤和提高协作效率。所以，“个体和互动”才“优于流程和工具”，注重面对面的直接交流，减少分歧。
这就要求业务架构师必须参加敏捷项目，在项目中快速完成架构分析，把控架构调整，而不能在项目之外按流程操作。敏捷开发团队要在业务架构师的直接参与下，根据需求描述快速使用模型工具澄清项目范围，列出对架构的改变事项。这也是对企业“通用语言”构建效果的检验。在项目期间，业务架构师可以根据具体情况完成对模型的调整，实现并行作业。
所以，应用业务架构和业务模型驱动的开发过程，可以转变为敏捷过程，并为敏捷过程提供更好的分析依据。
其实，仔细想想，敏捷过程与传统开发过程的主要区别有三点：一是大周期开发改成小周期冲刺；二是类似“多线程并发”的组织模式；三是分阶段投入资源改成一次性投入资源。在有业务模型作为指导的情况下，这三点都会变得更容易操作，不会拖慢进度。
三、非正宗的敏捷开发
非正宗的敏捷开发就是特事特办，因事而立，事过则废。这种方式会对企业整体架构管理带来破坏性，往往会要求违反“架构整体安排的改动”，事后也无人负责。有些系统可能会持续使用，但也有很多做完就无人问津。
与正宗的敏捷开发不同，正宗的敏捷开发是软件过程的差异，可以与企业级很好地融合；而非正宗的敏捷开发则存在不管不顾的问题，上线是唯一目标。这种情况很棘手，超出了业务架构师的控制能力，是对企业文化的考验。
对于特事特办的项目，我们要具体问题具体分析。如果项目形势逼人，必须尽快上线，那么业务架构师要参与项目，给出架构设计建议和事后重构方案。如果成本允许，要尽快回归正途，避免架构遭到破坏；如果成本不允许，要把这块“架构飞地”标识清楚，让它成为以后架构设计可以利用的“轮子”，而不是“陷阱”。
如果项目不具备紧急上线的价值，架构师要从业务架构的角度申明立场，给出分析意见。这是架构师的职业操守，而企业能否容忍架构师的意见，则是企业文化的体现。企业应该在项目文档中保留架构师的分析意见，以便未来参考。
架构师要有原则，但不能孤立自己，更不能变成“反对派”。架构师的宗旨是解决问题，而不是变成问题。
四、且行且珍惜
无论企业是否推行过双模开发，我们总是在“按部就班”和“特事特办”之间徘徊；无论是否建立了敏捷开发体系，总有项目必须尽快上线。大企业中，建立企业级体制容易，打破却很容易。我们不能为了“快”而牺牲企业级业务架构。
管理大企业的开发工作就像指挥大兵团作战，既要有稳扎稳打的方阵部队，也要有处理特殊任务的游骑兵。有序的架构管理是多兵种协作的关键。业务架构与敏捷并不矛盾，敏捷应该是有序架构体系下的敏捷，而不是乱闯。
大家可以想想，仅凭中台模式就能解决敏捷问题吗？其实，这是一个更大范围的企业管理或企业文化问题，不是单纯的开发模式或技术架构问题。
达不到敏捷标准的往往不是工具，而是人和人所在的环境。我们要珍惜企业级业务架构，在有序中求快。
