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

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

①本书只讨论了决策过程模型，但并不否认团队推动架构的其他过程方法。

从上述一般过程的各个关键环节来分析，一个架构的有效性、正确性应当表达为：□如何确保宏观规划层对需求映射层的约束，以及确保功能架构对开发架构的约束；□如何确保在将能力架构映射为实现架构时不丢失功能设计；□如何确保开发实现的结果能够被应用于预设的交付环境。

以此为参照，我们回顾此前图4-7所示的“通用办公系统架构v0.0.0.2”,为方便阅读，重复于图4-18中。

确切地说：它充其量只能算功能架构①,离系统架构还很远。但是有趣的是，在一般性的“办公系统的规模”下，从“架构v0.0.0.2”开始就已经可以进行有效的软件开发活动了。yipindushu.com

①一般意义的“功能架构”是“实现架构”中相当重要的组成部分，例如对客户需求项的映射，但这未能在中体现。

从上述过程来分析“架构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”太过于简陋，而且也未能在“系统架构”的背景下来表达架构意图，所以无法表现上述一般过程。撷其片段，可以就“这是一个什么样的系统架构”暂作一小结，其架构意图可以表述为(通过上述方法与过程，将最终构建):以功能性为核心的管理系统(的架构)。

现在，让我们再前进一步①,将这一架构意图表达为一个概要的系统架构的模①接下来两个小节，是对“架构形成模型M0”的一个应用。我们假定了一个实例，并基于此实例展开了一个系统架构过程，注意它并非是一个已经被理论化的架构方法，因此许多名词借用了其他场景。

我们需要在后续的架构活动中补全它对于开发与部署的约束性，由此得出整个“架构团队”的完整工作集②。其中，功能层是不需要过深讨论的，因为它应当可以通过“通用办公系统架构v0.0.0.2”逐渐细化而来，表现为一种功能架构(functionalarchitecture)。

服务层可以用一种静态的运行架构(static view of process architecture)③来表达，例如将不同的功能包装并发布成服务，在图4-20中，角色定义服务是对功能层中的“角色集”的封装，而业务登记服务是对“功能集”的封装。“定义”与“登记”在一定程度上暗示④了两种封装的形式不同，前者可能是一个角色管理子系统，后者可能是一个调度框架中的注册模块。