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