我的架构思想(十四):你所关注的系统——最初的事实(如何推翻那些最初设定的“事实”?)

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

我的架构思想(十四):你所关注的系统——最初的事实(如何推翻那些最初设定的“事实”?)

我们谈到过系统的脉络在架构意图中最为重要,它包括两个部分,即内在动律整体动向。通常,前者是无可争辩的事实,后者则是主观判断或客户战略。

考察上述“三点事实”,其中只有第一点是“办公系统”的事实,但它构成不了内在动律,因为内在动律应当是对一般过程的描述。只有将第一点和第二点事实合而为一的时候2,才能表达如下的一般过程3

2 从语言严谨性上来说:第一点事实是正确的,而第二点事实并不完整,是对第一点事实的补充。

3 UML 中的用例图(use case diagram)是这种一般过程的形式化方法。但是,用例图是从用户视角来阐述与表达的,因此通常它将这一过程体现为(亦即是用例图表达的含义):办公室成员使用日常功能。

一般过程:办公系统向某些办公室成员提供日常工作所需的功能。

接下来我们讨论事实之三,亦即是:这一系统既包括对现实工作的映射,也包括一些试图改变现行工作的电子化需求。其中,“系统包括对现实工作的映射”是完全正确但又毫无意义的——这是软件系统的本质含义,大体上来说是放之四海皆准的。而后半句就不见得正确了,因为“试图改变现行工作”并不见得是事实。

是否需要通过办公系统来改变现行工作,是客户的一项决策。如果在客户对业务的电子化战略中是有这样的需求的,那么这可以先“暂且”作为一项事实放在这里4;如果没有这样的需求,那么它就是一种相当危险的臆断。

4 在现实的情况中,客户可能是盲目的。客户有自己的语境、目的与表达方式,因此将客户需求或叙述直接作为“事实”是相当可怖的。

先讨论它的危险性。“改变现行工作”将会涉及的问题是业务流程再造(BPR,Business Process Reengineering),它直接将“办公工具”这一简单的解决方案推进到了“企业流程化”这一系统的规划工程中。它涉及目标企业是否有能力展开 ERP(企业资源计划,Enterprise Resource Planning)过程的问题,涉及该企业对其资产背景、管理模式、行业领域以及长期决策能力的评估。因此,是否“改变现行工作”是架构师无法直接从上述的一般过程,亦即是从第一点和第二点事实中推断出来的。

架构不是为客户设定战略5,而是服从客户设定的战略。如果客户没有形成战略,那么架构也就只能依据内在动律来主观判断整体动向。如前所论,这种主观判断是依赖对系统的分析而非对战略的假定的,并且也主要用于描述系统的发展方向,而非系统的客户——企业或领域的发展方向。

5 如果真有这样的情况发生,那么应该看看架构师是否同时承担了战略决策者或顾问的角色。我事实上乐观地认为(系统的、整体的、面向全局的)架构师应当参与战略过程,但在这里只能谨慎地摒弃这些因素的影响。

所以在架构意图上中对整体动向的考虑主要是三点:依赖、复杂性与持续价值。这三方面的问题都可以从战略设定中去寻求最终答案;如果战略不清晰,则也可以从上述的一般过程中去得到一些(阶段性的、可维护系统自身的发展所需的)设定。例如,在“架构 v0.0.0.2”中引入的管理这一概念(以及架构意图),其实是对系统的长期目标作出的考量:

整体动向:提供面向办公室成员和所需的办公功能的管理功能。

进一步地,对于整体动向的三个方面的问题的思考可能是:

  • 是企业内部的独立系统6

6 如果用户整体的电子化程度相当高,则可能提供有限的、功能性的、面向内部系统的开放接口。

  • 是功能渐增的系统;
  • 是战术过程中的一个实现点。

看起来,我们最初设定的“三项事实”许多是作不得准的。但这并不影响我们进一步架构该系统。与其他工程活动一样,架构工作也是渐进的,并不是一开始就准确无误。因而架构思维中需要不断反思与回顾,而架构活动也将是持续与迭代的。

在现阶段,伴随着“架构 v0.0.0.2”而来的,是我们确定了一项事实与一个架构意图。这是我们目前能做到的、有关“系统架构”的全部思考。

评论

发布