Question

任何系统架构必存在其外部实现与内部实现的过程。所谓外部实现，即是指架构师团队用以形成与演化架构的过程，以团队决策模型为例，即是小节“4.3 架构决策”中基于架构师团队所讨论的决策过程 2 。所谓内部实现，即是架构以及其部件的内部关系得以构建与维护的过程，以架构形成模型为例，一个可能的过程如图 17 所示。

图 17　一个可参考的架构形成模型 M0

这张图已经表达了一般过程中的限制条件与流转关系，但仍然需要强调两点：其一，在“实现架构”与“开发架构”中，分别只列举出了其中最重要的两个组成部分，这并非其全部；其二，在“实现架构”中只列出了运行架构与集成架构，其原因是它们对部署与开发的约束作用最为明显。

从上述一般过程的各个关键环节来分析，一个架构的有效性、正确性应当表达为：

• 如何确保宏观规划层对需求映射层的 约束 ，以及确保功能架构对开发架构的 约束 ；
• 如何确保在将能力架构 映射 为实现架构时不丢失功能设计；
• 如何确保开发实现的结果能够被应用于预设的交付环境。

以此为参照，我们回顾此前图 7 所示的“通用办公系统架构 v0.0.0.2”（为方便阅读，重复于图 18 中）。确切地说：它充其量只能算功能架构 3 ，离系统架构还很远。但是有趣的是，在一般性的“办公系统的规模”下，从“架构 v0.0.0.2”开始就已经可以进行有效的软件开发活动了。

图 18　通用办公系统架构 v0.0.0.2

从上述过程来分析“架构 v0.0.0.2”的形成过程就会发现，事实上得出“架构 v0.0.0.2”模型时，架构师——比如我——就已经隐含地：

• 完成了对业务及其需求的分析，如架构 v0.0.0….x 到 v0.0.0.1 的整个过程；
• 预设了这个办公系统的规模，例如在此前的分析中提及的“不需要跨国管理”等限定条件。

也就是说，“从架构 v0.0.0….x 到 v0.0.0.1 的整个过程”正是上述一般过程的一个应用示例。这也就是它仍然可以用于（通过后续的、持续的细化来）推动开发活动的真实原因。

“架构 v0.0.0.2”太过于简陋，而且也未能在“系统架构”的背景下来表达架构意图，所以无法表现上述一般过程。撷其片段，可以就“这是一个什么样的系统架构”暂作一小结，其架构意图可以表述为（通过上述方法与过程，将最终构建）：

以功能性为核心的管理系统（的架构）。