我的架构思想(二十九):架构是过程,而非结果——系统架构与决策(形成论的另一种求解:架构规划)

阅读数:36 2019 年 10 月 12 日 17:05

我的架构思想(二十九):架构是过程,而非结果——系统架构与决策(形成论的另一种求解:架构规划)

什么是系统的本质问题?这是我们要明确讨论的最后一个关键设问。就题设来说,“系统”的本质是领域集。这是一开始就讨论过并强加在我们这里的讨论之上的。但其本质上的问题是什么,却是一个还没有被讨论的话题。

若以现实系统为各个领域的目标,那么系统只需实现目标需求即可,亦即本质问题将是“能或不能实现”的问题。但是这将会得到一个“死的”系统:从系统被完成的第一时间开始它就不再增删任何东西;也没有任何对外的接口,因为它不面向新的领域。这样的系统并非不存在,事实上它大量存在着,并且是“高可靠系统”的主要开发方式。这样的系统的一个主要特点是它在架构上的确定性,与之对应而又匹配的,则是其领域集中的运作模式也相对确定。

但我们是在讨论复合领域集的问题。尤其其关键核心在于:由领域集构成的业务模式(犹如产业链等)是可能变化的,甚至是变化频繁的。一如本章最开始所讨论的,我们将“面向时间需求与空间需求”来进行架构,以应对这种持续变化。更进一步地,“变化”本身也只是需求,背后真正的问题——架构的本质问题,其实是对系统性的维护。

总的来说,可以将此前提及的种种思想归于在这一问题下的求解。例如,以架构形成的一般过程为参考,或架构以平台或框架为方向,或架构对战略的响应,等等,这些无一不是在讨论这样一个问题:架构需要提供何种程度的持续性,以使得它能够应对系统在构建和应用过程中的变化——并在这些变化之下保持“系统整体的一致”?

抛开上述这些具体方法,直面问题本身,那么架构规划也可能是另外的一种求解思路。仍以办公系统为例,从中长期来看,开发方推广该产品会存在一些明显的阶段。例如:

  • 在早期可能应用方单一,所以系统功能明确,针对性强而定制性弱;
  • 在一段时间之后,系统的应用方就多了,但缘于业务开展的情况,所以用户大多数都在类似行业当中,因此功能的定制性要求虽然强了,但其领域性仍比较单一,并且大体的使用流程和现场问题都类似;
  • 再后,开发方可能要求该系统平台化——这基于两点要求,其一是业务推广开始面向通用领域,其二是功能的大量增加导致系统过于复杂;
  • 最后,整个系统还可能走向跨平台的方向,例如面向不同的终端(如手机),以及加入不同的设施(如办公室签到设备),或者跨地域的办公等。

我们可以对这些阶段作出规划。首先,不同阶段的系统重点是不一样的,如表 3 所示。

表 3 架构规划在不同阶段中的重点

我的架构思想(二十九):架构是过程,而非结果——系统架构与决策(形成论的另一种求解:架构规划)

当我们将当前系统的目标与上述规划对应时,就很容易锁定我们“应有的”架构意图,并且能够通过阶段规划,来促使当前的架构意图契合业务方向对架构的要求。例如,就办公系统而言,我们可能将当前系统的目标设定为:

架构一期,快速实现的市场探针性产品。

基于这样的设定以及对其后的持续性的考虑,我们就有了进一步的架构决策。例如:

  • 宜通过使用现有的成熟系统来搭建运行环境,加强现场团队的实施能力来解决客户的现实问题;强化现场团队的反应能力、反馈能力,对发现问题的敏锐度,以便更加准确地收集与响应客户需求。
  • 宜通过敏捷开发团队的模式来实现产品功能,可以考虑让客户直接参与测试过程(例如试用或小范围测试),可以直接向客户提供 alpha 版本。可以考虑客户配合的现场调试环境。
  • 简化产品化特性,例如说明书或安装包。

    因此,在这个阶段的架构上,对集成性、重用性、移植性等的考虑就会非常少,类似集成架构、功能架构等的实施也可以很概略。

    但是从架构的体系性上来考虑,即使在最初阶段的架构中,也不能缺少对后续架构阶段的设定。这至少包括两个方面:其一,后续架构阶段的启动条件;其二,后续架构过程“在当前架构中的”入手点。表 4 给出了一个示例。

    表 4 架构意图在不同阶段中的变化与入手点

    我的架构思想(二十九):架构是过程,而非结果——系统架构与决策(形成论的另一种求解:架构规划)

    架构意图在各个阶段的不同变化,意味着我们可以用“有规划的变化”来讨论整体的架构意图。我们需要做的最后的一步工作是:将几个关键入手点连续起来,于是整个系统架构的脉络也就赫然可见了。

  • 评论

    发布