Atomic
架构设计是前瞻性的，根本不能100%预见未来的全部变化。然而交付有必须是完美的、一体性的。所以架构设计需要关注在模块化，可以模块被后续丢弃或不被采用，可以被后续优化，但绝不能缺失。缺失率是评判一个架构设计的关键指标。往往交付出现问题后，会第一时间发觉之前的架构设计没有考虑某些因素，也没有设计或乃至规划相对应的实现，一句“我没想到”，是根本解决不了问题的；同时“我当时认为不重要”也是推卸责任的回复。可以后续开发团队和交付没有去实现，但是架构设计必须是全面的全局的前瞻的。就好比一本优秀的“红皮书”，其章节是缜密及完善的，但是内容可以或多或少不尽相同，但是其总能够给人一个全面的轮廓。
为了后续的变化的灵活应对，不仅仅需要全面性，更需要将任何设计细节变为可插拔的模块，既有清晰的界限，又能够灵活组合或编排，更容易被相同规格的模块所替代，也需要以此为基础继续衍生出更完善的后续模块群组。不管是IoC或AOP等等，都是设计模式或实现框架，其关键是协助总体设计能够将所需要实现的功能进行模块化的分割和组装。
就好比一个最简单的数据访问实现：
a) 需要首先定义Interface
b) 之后再去考虑具体implementation
c) 外部强依赖于Interface的能力，但是黑箱化具体实现。
d) 任何后续的变化，都重写或提供其他具体Implementation方式。
e) 为更好的提纯和精炼，那数据访问就变为一个Layer；同时各个具体Implementation逐步可以后续细化和增强。
模块化是为了应对未知而退而求其次的最佳时间，架构师的职责就是定义好足够充足和颗粒度，及精准的规格。谁都想后续实现的时候，交付及研发人员发觉：“呀，架构设计已经设计或考虑进去了，我赶紧去实现。”
Procedure to get job done
架构设计不仅仅是IT技术的囤积，其应该是在项目启动之前协助整体资源及计划规划的核心。即：做事的过程环节定义。项目管理的项目计划只是将人财物时间按需分配，但是其无法描述一个具体业务系统如何实现和功能实现流转。
好的架构师是在自身充分理解业务需求FR或系统质量指标NFR的基础上，或在自身资深行业背景的基础上，将自己自信的、认为最优的、适度合理及延展的做事思路注入到架构设计及方案设计中，以期后续引导项目团队各个角色和对应资源的流转。
就好比沏茶喝水：如何从洗茶壶、烧水、泡茶.....等一系列步骤最终实现喝茶的诉求，但是在不考虑哪一个最快的前提下，可以有很多路径。架构设计需要考虑的是为了实现喝茶的诉求，中间的环节如何切分和融合、哪些环节或资源可被替代、替代后流程的流转、哪些环节或资源需要增强以期达到最后某些特定目的、哪些诉求后续有变化的可能、如何前瞻规划或动态应对......等等。
Blueprint
架构不仅仅是需要告诉别人怎么做、如何做，更关键是全貌化的告知别人，人财物时间在项目或系统中的投放想法，以及后续变化演进的趋势。
往往很多项目成员，尤其是中下层的开发成员，忙忙碌碌半年，不知道自己在做什么。虽然项目里面有完整的开发文档、频繁的业务培训或技术交流，但是他们会一致的反馈缺乏全面性的全局理解和系统蓝图；即使提供便利，让其接触物理架构图、逻辑架构图、网络拓扑图、数据架构图、技术架构图等等一些整体图形化和文档资料，但是反馈还是老样子，总还欠缺一点。
这就是系统蓝图的重要性，其初始自项目启动之前，迭代完善到架构设计之后；提供End-User、配合团队或资源、交付团队等等各类相关资源的配合理解；给PM、SA、TL等等诸多角色提供最原始的另外一份输入（除了业务需求之外）；并给整体项目发展、变化、延申等等提供阶段性动态演进的信息。
其是基于逻辑架构图之上、描绘系统上下游交互、标注关键物理实现、明确数据逻辑架构等，且融入业务诉求，能够让End-User、业务人员、开发人员等多角色全面理解系统信息的可视化文稿。必要时候好需要绘制及编写其在最初阶段演进及变更的动态趋势。
Interaction Scope
在蓝图的基础上，往往被抽取出来使用最多的就是用于系统上下游界定对接和交互范围和分工的信息。任何事情都无法第一时间被自己完全实现，必须依赖于各类外部资源。如何合理分工、明确资源和工作范围、动态及平稳的扩张等等，都需要认真的在项目前期进行梳理。
工作量不是自身系统或功能实现的时间，更来自于外部资源的协同时间。好的项目管理需要完整及前瞻且动态的外部资源交互信息，并不是几个业务专家和项目经理就能够说清楚或决定的了的事情。
好的蓝图如果提供系统动态变化及延申的趋势，也会为系统上下游交互资源提供完整的工作清单的基础上，提供更明细的工作安排。
Flow
往往各类项目推提供一堆“物理架构图、逻辑架构图、网络拓扑图、数据架构图、技术架构图......”，但是关键本质是静态的、割裂的、没有交互的。架构设计及蓝图等全局的设计，不仅仅需要罗列相关资源和环节，更关键的是描绘其动态的交互流程、资源流转等等动态的信息。
a) 然而流程图往往被用于业务流程的描述，或具体实现的描述。同时缺少更全面的信息可视化元素。
b) 与此同时，太过于细节化的照本宣科的可视化图形，例如UML，时序图，泳道图等等，缺乏信息的融会贯通和动态性。
c) 流程/流转，不仅仅是业务的时序变化，更关键牵扯人/角色、数据、系统内外等等各类变化。所以单一的描述是不够的、不直观的。
