笔者在 InfoQ 前文《关于架构演进生长的探讨》和《架构演进的第四个趋势：行业级尺度化》中，提出了笔者对架构生长趋势的一些浅见，也先容了企业级业务架构方法论的来龙去脉，本文拟基于上述文章提炼一下企业软件（大家常说的 B 端软件）架构设计中的四大思维支柱供大家参考。支柱一：整体思维一、从敏捷说起敏捷降生正是为相识决传统软件工程普遍被认为存在的“低效”问题，诸如周期长、不能快速响应需求、结果恒久不行见而易导致失败等，因此，敏捷往往给人“一言不合就开干”的雷厉流行的印象，而许多时候，敏捷在实操上也确实由于对“速度”和“形式”的片面追求忽视了对整体的合理设计，这样的敏捷并不是真正的敏捷，而是“着急”。

敏捷开发的几位殿堂级大师对设计的重要性有着很是深刻的认知。Martin Fowler 认为敏捷注重的是演进式设计，而不是轻视设计；Vernon 也品评一些敏捷开发实践是用“任务板挪卡”取代了设计；Sutherland 在“OODA”循环中也强调掌握全景信息而非只从自身视角看问题的重要性，每次 Scrum 竣事提出 MVP，都要重走一遍循环，因为 MVP 就是为了获得更多、更全的反馈信息，有了这些信息才气快速决议，快速决议绝非快拍脑壳，是因为有模式加速了对信息的处置惩罚速度，这才是敏捷的原动力，也是要总结方法论的原因，“全景信息 + 思维模式 = 快速决议”。

“OODA”循环如图 1 所示：图 1 “OODA”循环（来自互联网）敏捷开发由于其“高效”的特点，在支持快速试错的同时，也支持快速犯错，这是一体两面的，不能只看到其由于快速提供交付物所具有的结果可见能力。缺少整体把控，敏捷也容易堆叠“技术债务”。所以，敏捷开发也需要有整体思维做指导而不是只关注“速度”。如果敏捷也需要整体思维，那本就因此被“诟病”的传统软件工程方法和系统分析方法也就更应该“且行且珍惜”了，众所周知，Zachman 模型、TOGAF 模型和 DODAF 模型都很强调全景信息。

二、切勿因小失大所有局部问题的解决都离不开对整体的分析，分析的规模差别，得出的结论也会差别。举个简朴的例子，如果我们为功效开发任务排定优先级，那么，10 个任务之间举行排序和 20 个任务之间举行排序，很有可能得出排序结论是有很大差异的，分析规模会决议分析结论。

随着输入的增加，各种因素在总体上的权重就会有变化，原本认为重要的事情也可能因此不再重要了，最近大家又常提起一句话：“时代的一粒灰落在小我私家头上就是一座山”，其实也有这个意味。面向局部的分析和面向整体的分析是有很大差异的，而现在的企业治理越来越注重提升整体性，因此，B 端软件的架构设计、需求解读都应当有一个全局观，分析规模差别，解决方案也可能差别。

过于关注局部，将视野局限在小规模内，很可能会造成“因小失大”。近年某大型电商曾在自己的支付平台上引进社交功效，但却被用于非法用途，效果导致功效下线。该电商实力非凡，在系统设计方面也可谓独步青云，可是泛起这样大的“失误”，很可能是分析问题时，没能更广泛地视察已有案例和功效实际价值对整体的孝敬，低估了相关影响。

只管上述说法未免“事后诸葛亮”，但我们不是一直希望制止泛起此类问题吗？那回首原因，没做更全面的分析，就不能仅是一种“说辞”了。三、工具何其难基于整体分析的架构设计是一件极其泯灭心力的事情，我们不能总是依靠架构师这台“碳基盘算机”，总给架构师压上千斤重担而不提供支持，架构师不是魔术师，我们也经常忘记了，“架构”是整个企业的架构而不是架构师的“架构”。工欲善其事必先利其器。

工具不仅仅是软件类工具，方法论、流程治理工具、已有的模型资产、架构治理软件都属于工具的领域，而所有这些资产中，其实最重要的两样是方法论和模型资产。大家可能会以为架构治理软件更重要、更直接，可是架构治理软件是凭据架构设计方法论和架构设计实践做出来的，所以方法论和模型资产是更重要的基础性工具，而以现在架构设计的“杂乱”现状而言，没有通用的架构治理工具也是一定的，因为公认能普适的架构理论和行业级尺度化的模型资产都没有，也就没有合适的、可以真正直达“痛处”架构治理工具，如果能做出这样的工具，那么，一定可以开发一个世界级的市场。

除了工具的支持，来自企业的整体支持也很重要，不外这就属于资源层面而不仅仅是工具了。面向整体的设计，应当有整体的到场，企业的各个部门都应当到场到整体设计中，而整体设计也应当向整个企业传导。走不出架构师的架构设计，没有持久的维持能力；走不出 IT 部门的架构设计，不会凝聚起整个企业；走不出企业的架构设计，就无法真正落地企业战略。支柱二：洞察能力一、深入明白业务洞察能力是个老话题，不外架构领域本也没几多新鲜事，任何架构方法都需要深入实践才气逐渐掌握要领，架构领域没有快餐，不大可能“一夜顿悟”，也不要急着“PK”，更多的是需要重复去啃的“硬骨头”。

做软件设计，大家常说要对业务举行深入分析，要抓住需求本质，要有合适的抽象力度，这些说的其实都是洞察能力。洞察需要的是深入明白，而不仅仅是对需求的字面明白或者浅层的相同。架构领域一直不乏有对哲学方法论的应用，好比本体论，笔者近期阅读维特根斯坦的《逻辑哲学论》时也发现，只管难以深入明白大师的思想精髓，可是盘算机领域劈面向工具编程的研究与这本一次世界大战期间写就的哲学著作如出一辙。

增强洞察能力，一般都市认为是要提升思维穿透能力，这固然是必须的，可是从企业层面而言，也有相对容易操作的方式，就是增强深条理相同。这首先需要企业逐步。

本文来源：hthcom华体会-www.christmasonroad.com