我的架构思想(十一):你所关注的系统——知识的构建(知得,始于抽象概念的构建之后)

阅读数:19 2019 年 10 月 12 日 16:52

我的架构思想(十一):你所关注的系统——知识的构建(知得,始于抽象概念的构建之后)

“知得”是一个由抽象概念开始的思考过程。在我们的架构活动中,我强调这是一个由“架构意图”驱动的抽象活动。但这并非惟只的方向,并且可能是一个本末倒置的方向。这里需要强调两点,一是我们并没有完整地讨论“架构意图”的由来9,二是“本末倒置”并非是一件坏事。

9 严格地说,“管理”这一架构意图的由来是我们在小节“2.3 抽象概念与模型是展示架构意图的方式之一”中讨论过的——它来自于基于现实系统的几点事实的推论。但是存有两个问题:其一,这一推论过程是经验化的;其二,我们未讨论有关“架构意图的由来”的思考方法,而只是陈述了它的某一个实例(即“管理”)的由来。

我们要实现的系统只是现实系统的一个映像,这是我一再强调的。这意味着它与现实系统近似而又不完全相同。近似表明它与现实系统的关联,这种关联来自于对现实的观察、分析以及由此进行的知识构建活动;不完全相同,表明它与现实的差异,这种差异来自于架构师对系统的设定,亦或者说架构师强加于系统之上的架构意图。

从经典的架构与设计的法则来看,是“需求决定架构及设计”,这种需求通常是以现实系统为核心的。这很合理,毕竟从上述的分析来看,现实系统才是系统的本体,系统只是现实系统的一个侧相,而“架构意图”只不过是由架构师对系统之所用的理解。我们一旦强调由所用来推动架构过程,而忽略了本体的真实与侧相的含义,那么往往就会被指为本末倒置。

但是首先,对本体的认识方式决定了我们不能基于它来建立系统。本体不是观察而得的,也就是说,即使是用知得与识得构建的知识,仍然只是表达本体的一个侧相,而非本体的自身。这就是不同的架构师去观察与构建同一个系统的结果并不相同的原因——无论他们如何关注本体,如何尽心竭力地去阐述它,并证明自己的阐述是惟只正确的观察。本体是通过建立感受而形成的,如果一个人对现实系统不能设身处地,无有感同身受,那么他构建的系统会离现实系统很远。但是,如果这一观点成立,那么对本体的感受事实上是不可叙述的,任何语言文字叙述的“这一系统”都立即成为一个侧相,因为叙述可以有万千种渠道,万千种方式或万千种程度与细节上的差异。所以本体是唯只的,感受的结果也是唯只的,但到了表达为侧相,却不唯只了,是所谓“只可意会,不可言传”。

其次,本体的复杂性决定了我们不能基于对它的感受来建立这个系统。佛陀的拈花一笑是无解的:相对于其真实的本相来说,任何参悟者从这一公案10中所得的寓义都是确实的,而将它应用于任何思维活动的解说都是可行的。真正的原因并不在于“拈花一笑”这个行为外在的、形式上的简单,而在于“佛陀”这一背景的丰富。源于背景无以穷尽的丰富,对于任何其外在观察的解说都将趋于合理;对于其任何内在的感受都必将是、也仅只是对真实的无限逼近。本体的复杂性并不来自于一个形式或表面,而是其背景与历史的全体构成:全部影像以及影像的关系的集合。若基于如此复杂的本体来建立系统,其结果只会是三个字,是谓“不可说”。

10 “公案”,佛学禅宗用词,是对高僧言行的记录,可用作思考对象、座右铭,以启发思想,供人研究等。

我们需要反思此前系统11中所出现的概念:管理、组织机构、授权、角色(集)、业务(集)、日常办公、电子化管理,以及特定功能。在这里,我们并不讨论它们的确实含义,也不讨论这些抽象是否必要以及是否足够纯粹。我关注于一个实际问题:它们因何而来,如何来,以及为何不会成为你思维中的一个闪念并随之消逝而去。

11 目前来说,“架构 v0.0.0.2”是一个不错的架构。尽管它离投入开发实施还很远,但就我的经验来说,它在“正确地架构一个系统”这一方向上有着相当可喜的表现。

我们需要反思这些概念在架构思维方法中的意义。

所有的这些问题都指向一个答案:架构意图。我们可以找到这样两个不同的架构:它映射同一系统,由不同的架构师来实现。当我们对这样两个架构作分析时,一定可以找到一些相同的部分。这些内容大体来自于由需求驱动的架构方法,它们是架构师对需求的正确描述、复制与映射。如果这些描述、复制与映射中存在了差异,在这两个或更多的架构师之间是可以调和的,因为这仅仅是对一些真实可见、可以反复而又唯只陈述的需求的不同看法,它可以论证、分解、削弱或搁置,无论如何,它们不会成为两个架构中最核心与典型的差别。

我们也必然会找到一些不同的部分。(除了上述的差别之外,)不同的部分必然来自于架构意图的差别,是明显的主观认识,带有很强的目的性。举例来说,如果架构师 A 将系统设计为基于数据流的,可能的原因是:

  • 他熟悉一门数据流语言;
  • 他的团队有过此类开发经验,熟悉这种架构;
  • 他特别关注于系统中的数据活动;
  • 他掌握某种成熟的数据流架构实现;
  • 他有过数据流架构的成功经验;
  • ……

如果架构师 B 要理解这一意图,除了在知识积累上要与 A 类似之外,还要对 A 的上述背景也有所了解。换言之,事实上架构师 B 是要了解“目标现实系统 + 将架构师 A 作为系统对象”这整个的全集。对于架构师 B 来说,这是很不公平并且难于实现的。所以,往往架构师 A 无法期望别人理解,而只能寄期望于别人接受他的架构意图。

但是,如上所讨论的,如果它仅仅是意图——既有主观性、目的性,也有强制性,那么就可能是某个个体或利益干系人的一己之私。例如,某个架构师在会议中所发之言论,可能只是向其他架构师的权威挑战,而并非是系统在架构方面的真实所需。因此,如果我们不确切地定义“架构意图”,那么从种种意图中找出真实有意义的架构意图这一活动,就会变成一种类似修炼的东西,进而变得无有方向、无有所指,因而也无法辨识。

评论

发布