我的架构思想(二十二):架构是过程,而非结果——架构师的能力结构(有价值的决策是对意图的响应)

阅读数:32 2019 年 10 月 12 日 16:58

我的架构思想(二十二):架构是过程,而非结果——架构师的能力结构(有价值的决策是对意图的响应)

第三个问题则是关于架构意图在复杂模式下的效果的。这涉及我们上面讨论的一个核心设问:架构整体需要决策的本质原因是什么呢?

我们所讨论的系统的规模已经扩展到多个领域,因此需要由架构师团队来处理它的架构需求。进而地,多个领域之间的——系统本身的——问题作为一个独立领域仍然有自身的架构需求,因此我们提出了系统架构师或平台架构师等规模来应对之,并(根据其领袖能力、可能性地)赋予其一定的组织责权,例如“首席架构师”或“主架构师”。

这一架构角色面对的并非上述系统各个独立领域内部的问题,而是“架构整体”的问题。将其本身作为系统,综合一下我们此前的讨论:

  • 其一,它是领域集。从领域集的关系来看,它可能涉及的基础构件包括领域 / 子系统、通信与验证,以及它们的问题与解决方案,例如分布、依赖、消息等。
  • 其二,从其定义来看,它的抽象必须能容纳上述构件并提供可以讨论的事实基础
  • 其三,从系统性的限制上来看,上述事实基础必将涉及全局性的边界约定,以及对非可控因素(包括但不限于风险)的识别与处理。
  • 其四,从架构的本质上来看,其范围与联接件的问题,实质上是各领域边界的全集与交集(以及交集间)的关系。

可见,这些内容提出了“系统需要事实基础”,这与架构意图所讨论的问题是一致的。

但这并不能表明“架构本身的架构意图”与领域性的、子系统的架构意图有着一样的源起与价值——我们在这里提到了“价值”,亦即是对“架构本身的架构意图”的效果问题的讨论。

架构有两个效果方面的考量,即它对时间需求空间需求的响应与收益。这样的考量依据来源于以下三点。

  • 其一,若架构不谈时间需求与空间需求,而只谈目标需求,那么“架构整体”就必将等效于“各种架构的全集”。然而,若这个全集的元素之间没有关系,也就无法构成整体,进而“全集”这一观念构成了对架构整体性的破坏。
  • 其二,如前所论,架构是可以通过解决问题来实现需求的,而非单纯对需求的响应。若架构本身只谈上述全集的“目标需求”,那么也就无法触及其背后的“问题”;而时间需求与空间需求背后的问题是清晰的,即系统的规模与复杂性。
  • 其三,架构本身的价值在于:在保持方向的同时控制成本。而架构在时间需求与空间需求上的考量,构成了“架构全集”到“架构整体”的价值提升。它使得架构可以通过在时间与空间上的分解——一般表达为架构阶段(以及对应的实施阶段)的迭代——来解决架构规模问题与复杂性问题,进而达到成本控制。

综上,团队模式下的决策与个体决策有很大的不同16。团队决策考虑的对象有两点,其一是对架构整体的把握,其二是对团队整体的把握。对前者的思考,仍然可以归于架构意图,是由领悟能力驱动的;而后者则可以视为对架构意图的效果的保障,是由领袖能力所驱动的。

16 注意决策能力、领袖能力与管理能力并不同一,这里只讨论其中的决策能力部分。而将“架构团队”作为一个组织来看,也存在对“管理者”的需求。但即便如此,也并不表明首席架构师必须担负架构团队的管理责任。

评论

发布