传说中和现实中的双模开发
“天下武功唯快不破”。电影《功夫》中火云邪神这句台词可谓深得互联网时代竞争的要旨，也不乏业内人士常常感叹，一个产品的成功可能只是领先对手一周甚至两三天的上市时间，产品创新速度、市场响应速度越来越被企业重视，但这两个指标似乎都是大型企业，特别是传统行业中大型企业的弱项。所以，不少人都致力于教大象跳舞，不断有关于软件过程、项目管理的概念应运而生。比如，Gartner 在 2014 年提出了“双模开发”，敏态加稳态，可预见性的业务使用传统瀑布式开发，也就是稳态；探索性业务使用敏捷开发，也就是敏态。
2015 年，Gartner 对全球 2800 多位 CIO 进行了一次调研，结果显示：38% 的企业已经实施了双模 IT，26% 的企业将在未来 3 年内实施双模 IT，只有 13% 的企业不会实施双模 IT，另外还有 23% 的企业则不确定。虽然没有找到近期的数字，但是按照 Gartner 的说法“双模开发”少说也占据了半壁江山。我无意在这里去质疑或者争论这种统计，但是，显然这些 CIO 们口中的敏捷开发未必是“敏捷宣言”所提到的敏捷开发，更多的还是应对特殊需求时，打破常规的“快速”开发，省略了通常的管理环节，组个小分队，快速上线。这种剧情相信大家都经常遇到，市场着急、领导着急，大笔一挥，桌子一拍，下月上线。当然，对互联网科技公司而言，可能就是下周上线。所以，大家都经常在稳态和敏态，也就是按部就班和大干快上中做来回切换。
无论是符合敏捷开发定义的敏捷，还是特事特办的敏捷，都意味着忽略既有流程中的一些环节，压缩周期，快速实现目标，那么，相比之下，经过业务架构设计、应用业务模型驱动的开发是不是显得有些笨重，是否与敏态不兼容？是否在敏捷过程中应该被省去？要回答这些问题，我们还是从符合敏捷开发定义的敏捷和特事特办的敏捷这两个角度分别看看吧。
跟正宗的敏捷比比
说到正宗的敏捷开发，自然要说到“敏捷宣言”中提出的四个核心价值：个体和互动优于流程和工具、工作的软件优于详尽的文档、客户合作优于合同谈判、响应变化优于遵循计划。最直接的冲突莫过于第二项，敏捷开发素来以“不重视”文档闻名，但其实敏捷开发并非不要文档，而是不要那么详尽的文档，过于详尽的文档会消耗大量不必要的精力，而用途又非常有限。对于开发人员而言，在软件维护方面，高质量的需求文档远不如整洁的代码加上详尽的注释会更让人清楚软件的结构，所以敏捷开发在这方面做了大胆的改变。但是，敏捷开发也还是要求有一份恰当的概括性文档作为项目的总体目标，而不是什么都没有就甩开膀子干。如此，业务模型这套方法要想与敏捷开发融合起来，自身也必须具备一定的简洁性。
从之前的介绍来看，首次企业级转型肯定不适合这么干，而且企业级转型需要深思熟虑，也不是应该去“敏捷”完成的事情。一旦转型结束，具备了企业级架构之后，就是如何快速应用架构工具的问题了。我之前提到过，业务模型不应该承载太多的业务细节，要保持适当的抽象度，否则不利于对企业级的描述，至于细节要描述到什么程度，不同的企业可能会有不同的要求，大的原则是，可以基本解释清楚任务对数据实体的创建和变更，以便划分任务以及组件的边界。因此，模型本身具备快速应用的潜质。而且，模型本就是一张“作战地图”，通过模型也可以更快摸清项目范围、涉及的组件和团队以及潜在影响。敏捷并不是不顾一切的敏捷、更不是牺牲企业级架构一致性的敏捷，否则，敏捷项目就成了为短期利益而有意忽视长期影响的盲目行为。无论多着急，不看看地图就冲向战场，都是危险行为。不过话说回来，模型分析和调整需要一定的过程，企业级这类庞大的模型体系也需要工具来支持，否则真的谈不上快。
这似乎跟第一项核心价值也有冲突。其实不然，敏捷开发的速度来自于节省不必要的步骤和提高协作的效率，所以“个体和互动”才“优于流程和工具”，注重面对面直接交流，减少分歧。这就要求业务架构师必须参加敏捷项目，在项目中快速完成架构分析，把控项目引起的架构调整，而不能在项目之外等着按“流程”操作。敏捷开发团队在要在业务架构师的直接参与下，在项目一开始就根据需求描述快速使用模型工具澄清项目范围，列出对架构的改变事项，这其实也是对企业“统一语言”构建效果的检验。在项目期间，业务架构师则可以根据项目的具体情况完成对模型的详细调整，实现并行作业。所以，应用业务架构和业务模型驱动的开发过程，可以转变为敏捷过程，并为敏捷过程提供更好的分析依据。
跟“特事特办”论论
再说到特事特办的敏捷。这种敏捷其本质就是“临时事项”，因事而立，事过则废，这种方式其实对企业整体的架构管理带有一定的破坏性，往往会直接要求一些违反“架构”整体安排的改动。而事后也经常无人对此负责，做了就做了，然后交给运维团队去维护。有些真有长期价值的系统可能会持续使用，还好些，但是做了之后就再无人问津，半死不活地躺在哪里的系统也屡见不鲜。
与上文提到的“真”敏捷不同，“真”敏捷是软件过程的差异，并不意味着要去违反企业级，可以与企业级很好地融合；但是有些特事特办的敏捷确实有不管不顾的意思，上线是唯一目标，手段可以不问。这种情况就很棘手了，因为它超出了业务架构师的控制能力之外，是对企业文化的考验，是对企业维护其企业级架构决心的考验。
不过我们还是坚持下具体问题具体分析，别一概而论地扣大帽子。
首先，有些项目确实形势逼人、速度第一，不上线毋宁死，这种要举全局之力搏一隅的情况不支持也不行，但是业务架构师要切实参与到项目中，不但要给出当时的架构设计建议，也要尽快给出影响分析和事后的重构方案，如果成本允许，尽可能要在企业“搏命”之后，回归正途，避免架构遭到破坏，如果成本不允许，那这块架构“飞地”也要标识清楚，尽可能让它成为以后架构设计可以利用的“轮子”而不是会踩的“坑”。
其次，对于不具备上述价值的“特事特办”，架构师应该从业务架构的角度申明其立场，给出认真的分析意见，这是架构师自身的职业操守，而能否容忍架构师的意见则是企业文化的真实体现了。如同会议表决中的“保留意见”一样，如果架构师真的反对项目的设计和实现方式，那企业就必须在项目文档中保留其分析意见，这倒不是非要“立贴为证”，而是在未来真的需要调整时，作为参考意见使用，同时也供所有架构师进行检验和学习。这是对企业级的一种警醒，但并不是业务架构师工作中的常态，也不应是其工作追求的目标，架构师不是以参倒了宰相为荣的“言官”，要有原则但也不要让自己孤立，更不能变成言必称企业级、处处拿大帽子压人的“反对派”，架构师的宗旨是解决问题，而不是让自己变成问题。虽然跑了点儿题，聊了下架构师的素养，但这是“特事特办”牵出来的，足见这种事的麻烦，它超越了正常工作的范畴，带有点儿其他色彩，需要架构师谨慎对待。
综上，无论是否企业有意识地推行过“双模开发”，大家也总是忙碌在一般流程和“特事特办”之中；无论是否建立了敏捷开发体制，也总有项目必须要快上。大型企业中，企业级体制建立不易，打破却很容易，不要为了“快”而牺牲企业级。管理大企业开发就像指挥大兵团作战，既有担当主力、要稳扎稳打的方阵部队，也有要处理特殊任务的游骑兵，多兵种之间的有序协作是克敌制胜的关键，这就离不开有序的架构管理，通过业务架构方法、应用业务模型驱动开发本身与敏捷并不矛盾，敏捷可以是、也应该是一个有序架构体系下的敏捷，而不是“叫嚣乎东西、隳突乎南北”的乱闯，好像有句格言，“捷径是迷路的最快方法”。所以，一定要有效利用业务模型这个“作战地图”，培养好业务架构师这个“领航员”。
说到这里，朋友们也不妨想一下，仅凭中台模式就能很好地解决敏捷问题吗？其实，这应该还是一个更大范围的企业管理或者企业文化要去解决的问题，它并非一个单纯的开发模式或者技术架构问题，之前我也提到过，企业级业务架构设计是希望实现企业整体的联动、文化的转型，而不是仅仅建立一套系统，实际上，阿里的中台背后支撑其运作的也是阿里的企业文化。没有敏捷起来的往往不单纯是工具，而是人和人所在的环境。
