架构设计的四大思维支柱
支柱一：整体思维
一、从敏捷说起
敏捷诞生正是为了解决传统软件工程普遍被认为存在的“低效”问题，诸如周期长、不能快速响应需求、成果长期不可见而易导致失败等，因此，敏捷往往给人“一言不合就开干”的雷厉风行的印象，而很多时候，敏捷在实操上也确实由于对“速度”和“形式”的片面追求忽视了对整体的合理设计，这样的敏捷并不是真正的敏捷，而是“着急”。
敏捷开发的几位殿堂级大师对设计的重要性有着非常深刻的认知。Martin Fowler 认为敏捷注重的是演进式设计，而不是轻视设计；Vernon 也批评一些敏捷开发实践是用“任务板挪卡”代替了设计；Sutherland 在“OODA”循环中也强调掌握全景信息而非只从自身视角看问题的重要性，每次 Scrum 结束提出 MVP，都要重走一遍循环，因为 MVP 就是为了获得更多、更全的反馈信息，有了这些信息才能快速决策，快速决策绝非快拍脑袋，是因为有模式加速了对信息的处理速度，这才是敏捷的原动力，也是要总结方法论的原因，“全景信息 + 思维模式 = 快速决策”。
“OODA”循环如图 1 所示：
图 1 “OODA”循环（来自互联网）
敏捷开发由于其“高效”的特点，在支持快速试错的同时，也支持快速犯错，这是一体两面的，不能只看到其由于快速提供交付物所具有的成果可见能力。缺少整体把控，敏捷也容易堆叠“技术债务”。所以，敏捷开发也需要有整体思维做指导而不是只关注“速度”。如果敏捷也需要整体思维，那本就因此被“诟病”的传统软件工程方法和系统分析方法也就更应该“且行且珍惜”了，众所周知，Zachman 模型、TOGAF 模型和 DODAF 模型都很强调全景信息。
二、切勿因小失大
所有局部问题的解决都离不开对整体的分析，分析的范围不同，得出的结论也会不同。举个简单的例子，如果我们为功能开发任务排定优先级，那么，10 个任务之间进行排序和 20 个任务之间进行排序，很有可能得出排序结论是有很大差异的，分析范围会决定分析结论。随着输入的增加，各类因素在总体上的权重就会有变化，原本认为重要的事情也可能因此不再重要了，最近大家又常提起一句话：“时代的一粒灰落在个人头上就是一座山”，其实也有这个意味。
面向局部的分析和面向整体的分析是有很大差别的，而现在的企业管理越来越注重提升整体性，因此，B 端软件的架构设计、需求解读都应当有一个全局观，分析范围不同，解决方案也可能不同。
过于关注局部，将视野局限在小范围内，很可能会造成“因小失大”。近年某大型电商曾在自己的支付平台上引进社交功能，但却被用于不法用途，结果导致功能下线。该电商实力不凡，在系统设计方面也可谓独步青云，但是出现这样大的“失误”，很可能是分析问题时，没能更广泛地观察已有案例和功能实际价值对整体的贡献，低估了相关影响。尽管上述说法未免“事后诸葛亮”，但我们不是一直希望避免出现此类问题吗？那回首原因，没做更全面的分析，就不能仅是一种“说辞”了。
三、工具何其难
基于整体分析的架构设计是一件极其耗费心力的工作，我们不能总是依靠架构师这台“碳基计算机”，总给架构师压上千斤重担而不提供支持，架构师不是魔术师，我们也经常忘记了，“架构”是整个企业的架构而不是架构师的“架构”。
工欲善其事必先利其器。工具不仅仅是软件类工具，方法论、流程管理工具、已有的模型资产、架构管理软件都属于工具的范畴，而所有这些资产中，其实最重要的两样是方法论和模型资产。
大家可能会觉得架构管理软件更重要、更直接，但是架构管理软件是根据架构设计方法论和架构设计实践做出来的，所以方法论和模型资产是更重要的基础性工具，而以目前架构设计的“混乱”现状而言，没有通用的架构管理工具也是必然的，因为公认能普适的架构理论和行业级标准化的模型资产都没有，也就没有合适的、可以真正直达“痛处”架构管理工具，如果能做出这样的工具，那么，一定可以开辟一个世界级的市场。
除了工具的支持，来自企业的整体支持也很重要，不过这就属于资源层面而不仅仅是工具了。面向整体的设计，应当有整体的参与，企业的各个部分都应当参与到整体设计中，而整体设计也应当向整个企业传导。走不出架构师的架构设计，没有持久的维持能力；走不出 IT 部门的架构设计，不会凝聚起整个企业；走不出企业的架构设计，就无法真正落地企业战略。
支柱二：洞察能力
一、深入理解业务
洞察能力是个老话题，不过架构领域本也没多少新鲜事，任何架构方法都需要深入实践才能逐渐掌握要领，架构领域没有快餐，不大可能“一夜顿悟”，也不要急着“PK”，更多的是需要反复去啃的“硬骨头”。
做软件设计，大家常说要对业务进行深入分析，要抓住需求本质，要有合适的抽象力度，这些说的其实都是洞察能力。洞察需要的是深入理解，而不仅仅是对需求的字面理解或者浅层的沟通。架构领域一直不乏有对哲学方法论的应用，比如本体论，笔者近期阅读维特根斯坦的《逻辑哲学论》时也发现，尽管难以深入理解大师的思想精髓，但是计算机领域对面向对象编程的研究与这本一次世界大战期间写就的哲学著作如出一辙。
加强洞察能力，一般都会认为是要提升思维穿透能力，这当然是必须的，但是从企业层面而言，也有相对容易操作的方式，就是加强深层次沟通。这首先需要企业逐步改变业务人员的和技术人员的比例，使技术人员能够走到业务人员中间来，加强二者的融合。
所谓深层次沟通并不是两个人要碰撞出哲学火花，如果两个人之间只能具有一个聊聊需求的时间，就急着做产品上线了，那双方之间的了解深度必然是有限的。技术人员如果能够轮班走到业务人员中间提供实地支持，深入理解工作环境，实际感受业务压力，理解的深度自然会增加。我们不需要指望技术人员变成哲学家来增加洞察力，只需要给予他们更多的观察机会和思考时间。这并非“强人所难”，至少，国外的大银行，如摩根大通、高盛、Capital One 等，已经不乏这样的操作了。
可能很多人会觉得这对中小企业不公平，不可操作，毕竟他们资源有限，但是，这也取决于你是否相信“未来的企业都是科技企业”，至少笔者相信，因为软件将是未来最主要的生产方式。也许今天很多企业不用急着进行这个操作，但是，这不代表可以忽视这个问题，而越大的企业应该越早动手，因为企业越大转型越慢、周期越长、沟通模式越复杂，企业的全貌也越难以掌握。
二、努力推进标准化
如果软件行业整体都具备了深入的洞察能力的话，那标准化就应当是件自然的事情，农业和工业的发展都是这个历程。农业的耕种方法、选种和培育、肥料的制作，即便在今天看来极为简陋的原始生产阶段，为了提高农业种植的成功率和产量，也是在进行着不懈的“标准化”努力。农书早已有之，即便在著名的“焚书坑儒”中，也获准可以保留，可见古人对农业技术的重视，更不用说在现代工业条件支持下的大规模农业生产。与之相比，软件行业真有那么特殊吗？真的不会有标准化生产这个历程吗？
反思软件行业目前的情况，也许只能说，洞察力依然不够，至少没有真正理解标准化对行业的意义，否则，一个已经发展了 70 多年、精英辈出的行业，不会在标准化资产、标准化生产方面如此“尴尬”，我们书写了那么多的技术标准，却依然无法提供一套能够有效复用的行业级软件资产，当然，这种复用不是指搬过来就用，而是至少不用从头做起。
开源提供了很好的支持未来大规模软件生产的模式参考，而需要的是增加对标准化的管理的思考，这也许是未来开源的发展方向。
没有标准化能力，软件行业可能无法撑起未来对软件生产的大规模需求。标准化是行业成熟的表现，也是软件行业对自身、对其他行业都具备深刻洞察力的体现，更是设计师在设计时应为之努力的方向。
支柱三：演进思维
一、唯快不破？
“快鱼吃慢鱼”几乎成了当今社会的集体“焦虑”, 企业由于竞争的压力，对“立竿见影”的追求近乎“执着”。笔者也是个二次元的爱好者，每每想到这个问题，自然会浮现出一部漫画作品——《浪客剑心》，主人公绯村剑心的独门绝技就是“拔刀”，一回合解决对手，拔刀的瞬间就致对手与死地。相信很多企业在搞软件建设时也寄望于此，希望采用某个架构、做成某个系统后，可以实现超级应变能力。
然而漫画作品中的主人公是在经历了地狱般的生死训练之后才具备如此能力，带着一身的伤病，成了一台需要精心保养否则很难“善终”的机器，用个通俗点儿的解释就是职业寿命比较短。所以，“快”都是有代价、有基础的，“快”是系统性训练的结果，不是哪个部门的“快”在支撑整个企业的“快”；“快”是整个企业持续演进出来的，而不是被外部因素突然赋予的。大家都不是漫威电影里的“超级英雄”，不是天赋异禀，也不是被蜘蛛咬一口就可以拯救世界。
不注重基础的“快”，只能是“眼见他起高楼，眼见他楼塌了”。在业务领域里，我们不乏见到业务人员被逼急了而出现的业绩造假、财务造假，而忽视软件工程的底线要求，把技术人员催的太紧，也可能出现技术“造假”。也许笔者的说法不够准确，但是英国 TSB 银行的案例也许可以当成一个侧写吧。业绩造假、财务造假对企业管理者而言还是可以搞清楚的问题，但是技术方面出的问题，相信大部分管理者可能搞不清楚。有兴趣的读者可以看看对计算机 BUG 的分类，像薛定谔类型、海森堡类型、分形类型等，这是连技术人员自己都搞不懂的 BUG 形态。
技术目标的实现很难一蹴而就，也许不少传统企业的管理者会问如今互联网企业不是很具备“快”的样子吗？与传统企业相比，他们是挺快，这是因为他们具有更好的技术管理能力和开发环境，有基础设施支持人员能力的发挥，但是，不容忽视的是之前热过的“996.ICU”这个话题。敏捷创始人可是说过，敏捷应该是高效和不用加班的。这种透支技术人员身体，把软件行业搞得像“血汗工厂”的做法，不应该用对“理想”的追求一笔带过。
传统方法只要用的纯熟、坚持对方法论的完善和演进，合适的条件下，一样可以获得“快”的效果。比如二神山的建设就是在瀑布模型和甘特图的指导下实现“中国速度”的，感兴趣的读者可以找找二神山的工程师们公开分享的资料，看看他们对传统方法的运用。
回到正题，架构设计及其实现应该注重的是演进思维，不可能“毕其功于一役”，再着急也无法忽视客观规律。如同搞战略设计，如果给设计人员的只有泡一碗方便面的时间，那交付的也只能是一碗战略方便面。
二、演进方向
架构设计要具备演进思维，演进思维除了意味着大目标要分段实现外，也意味着对目标该有一个整体认知，这个认知对企业软件而言，就是要统一到企业的愿景和战略上。本文笔者延续自己在《企业级业务架构设计：方法论与实践》一书中的观点，将愿景定位于 20-30 年的长期方向，而将战略定位于 3 年左右的“短期”方向。技术变化比较快，战略周期长了不利于调整，但是太短也很难有明显实施效果，尤其是对大型企业而言。
从长期愿景的角度看，数字化转型是必然的，当代的人碰巧处于时代切换的转型阵痛期，作为经历“痛苦”的人，任何企业和个人都无法回避这个问题。笔者将其列为长期方向，是因为笔者所认为的数字化与目前更为贴近信息化的各类主张不同，数字化不是一两个系统或者某个架构就可以快速解决的问题，而是整个社会的数字化，企业的数字化是社会数字化中的一环，并且，不可能仅靠自身的数字化完成。
以数字化转型为架构设计思维演进的长期方向，在每个战略周期内，密切跟踪技术的发展，适时引入可能带来业务模式变化的技术，实现新技术与业务的融合，这种架构驾驭能力才是未来企业竞争的关键。
笔者对数字化转型的详细论述包含在即将面世的新书《银行数字化转型》中，本文不再过多着墨于此。
支柱四：开放思维
一、有中心而无权威
这个说法略有“不当”，但笔者暂时没有想到更形象的表述。实际工作中，架构师在项目中是具有“权威”性的，这样比较有利于项目的总体管理，大的项目可能会有很多架构师，因为架构师的分工也是很细的，因此，从效率上来讲，也需要设立个“首架”。
“中心”会提高执行效率，但是，架构师必须具有开放性，保持谦虚，架构师是“中心”，但不要总把“权威”看得太重，架构是企业整体资产，说的不客气点儿，企业搞架构也正是为了能够摆脱对特定架构师的“单点依赖”，使架构工作能够保持“业务连续性”。
架构设计中要保持这种谦逊性，这样才能让更好的设计思路进入设计师的视野，进入设计方案。“海纳百川，有容乃大”。所谓的技术权威，最好是自然形成的，而非来自于职权的任命；技术权威是用来“向我开炮”的，如果用来维护，很可能会产生适得其反的结果；技术权威最终代表的是问题能被更好地解决，而不是“唯马首是瞻”。
架构设计非常需要注重整体，尽可能考虑全景信息，这往往也意味者过于依赖“权威”架构师其实是有风险的，“智者千虑必有一失”，负担太重也会造成核心架构师“过载”。从这个角度讲，架构师团队的开放协作，或者架构师与项目团队的开放协作是非常重要的，整体思维和开放思维之间相辅相成。
二、开放式架构设计
关于开放银行的讨论去年和今年特别多，笔者也曾发布过相关文章，在笔者看来，与其称之为开放银行不如称其为开放式架构含义会更明确。企业之间在生态建设的“大旗”下，连接越来越紧密，而且从商业层面的连接逐渐下沉为技术层面的连接，API、SDK 等对接方式让信息化程度较高的企业之间联系更为密切。
随着企业架构理论和企业实践能力的提升，企业内部一体化程度会逐渐加强，并转化为体现生态分工的跨企业系统协作，这要求架构设计遵循开放的设计方向，以企业之间更好地对接为目标，实现跨企业的流程整合，这样组成的“竞合”关系更稳定、更具竞争力。
面向开放式协作的架构设计，要求企业有更好的、可读性强、可公开的内部架构，这样才能有更好的协作前提，而今天这种充满个性的架构设计风格，要逐渐向更加标准化、更容易沟通的方向发展。PPT 不是架构师的发力点，对架构的过度宣传也许反而不利于架构的健康发展，架构风格的过度自由也许会带来沟通上的不自由。尽管今天架构师们面对的企业环境、技术环境越来越复杂，但是，简单依然是设计应该持续追求的目标。
本文总结的四大思维支柱相信各位读者并不陌生，笔者只是将个人的一些理解融合进去。如果用“T”型人才或者“T”型思维类比的话，整体思维相当于“T”字横头的“一”，洞察能力相当于“∣”，演进思维相当于小“T”逐步积累成大“T”，而开放思维相当于多个“T”的连接，包括企业层面、架构层面和架构师层面的开放与连接。架构说到底就是结构和关系，架构的四大思维支柱，谈的也就是处理好结构和关系的思考原则。
(欢迎大家加入数据工匠知识星球获取更多资讯。)
扫描二维码关注我们
我们的使命：发展数据治理行业、普及数据治理知识、改变企业数据管理现状、提高企业数据质量、推动企业走进大数据时代。
我们的愿景：打造数据治理专家、数据治理平台、数据治理生态圈。
我们的价值观：凝聚行业力量、打造数据治理全链条平台、改变数据治理生态圈。
了解更多精彩内容
长按，识别二维码，关注我们吧！
数据工匠俱乐部
微信号：zgsjgjjlb
专注数据治理，推动大数据发展。