我的架构思想(五十五):附录 3.1.5

阅读数:17 2019 年 10 月 16 日 15:05

我的架构思想(五十五):附录 3.1.5

附三:超越软件架构——组织与架构 <1 什么是领域角色的关注 >(VEO 模型:架构角色出现的必然性)

对于一个小型的组织,或一个较短期的目标 / 方向来说,若要求“经营者”来保证两个投影的原始目标同一,并在实施过程中持续稳定,是有可能做到的。这也是一些小公司或小型团队能有良好的组织与合作的根本原因:经营者直接参与规模与细节的平衡。但是,在以下时候:

  • 规模持续扩大、技术渐趋复杂,
  • 经营者的方向与阶段目标间的距离越来越远,
  • 方向由多个方向簇构成,

经营者便将难以通过亲历亲为的形式来实现上述的平衡。这些情况下,经营者通常需要通过组织调整来保证其战略推进的有效性。

“组织”既是一种经营工具,也是一种管理工具。所以无论经营者还是管理者,都有可能使用这一工具带来系统整体或局部的变化。换一个角度,管理者其实也可能参与或直接行使经营职责。因此《大道至简》中所述的:

你可以更直接地观察到“经营者”与“组织者”之间的差异。例如公司的大小股东是“经营者”,董事会通常是解决经营问题的地方;而总经理、执行经理及各个部门经理则是各级的“组织者”,经理办公会则是解决组织问题的地方。

这样来将“组织者”作为角色讨论是并不适当的——“组织”,是管理职能的一种工具而非其全部。所以《大道至简》其实是用一种极端情况来区分出了“经营角色”,使我们在 EHM 中的模型可以被讨论而已。

经营者选择组织工具而非其他,是有一定合理性的。首先,模型4在“方向”轴上的缺失是局部问题而非全局问题,因此通过组织工具来调适不会带来全局性的风险。其次,经营者可能并不期望颠覆正在进行中的阶段性目标,因此选择组织工具而非战术手段(例如裁撤项目)相对会更为温和。

经营者需要在模型4中解决的问题是规模与细节的平衡,以使得工程角色的实施与目标、方向的设定一致。正是这一需求导致架构角色的引入,因为“架构”角色本质责任与这一需求不谋而合。

所谓架构,包含了“范围”与“联接件”两个方面。“架构”一词源于建筑学,中文所说的架构,意指“间架结构”。其中的间、架,在建筑中是对房屋规模的度量用词;结、构则是指建筑的关键位置上的技术构件。

但是,如果我们将架构角色锁定在“某种描述范围与联接件的文书”这样的产出上,无异于将架构角色当成技术工人:使用某些工具,生产某种产品。我在这里讨论 “架构”一词的本义,是强调应从本质特性上来看清架构角色所关注的方面。而这些方面,又与在现今软件工程中经营角色对软件系统的关注,例如问题的识别与控制等等存在一致性。正是因为这种一致性,由架构角色来介入模型4中的“方向”这个轴线所指代的领域,才会成为一种组织选择的必然,如图附 3-8 所示。

图附 3-8 模型 5:组织视角下的工程视图

我的架构思想(五十五):附录 3.1.5

在从 EHM 模型推进到图附 3-8 所示模型的过程中,我们让经营角色介入进来,又渐渐地将这个角色分离出去,代之以“系统架构”这样的领域与角色。以下我们把工程视图模型简称为 VEO 模型(View of Engineering Organization)。在开始后续的讨论之前,我们需要再次强调引入架构角色的本意与背景:

(1) 目标。架构角色围绕一个阶段目标,以及该目标在规模与细节上的投影工作。这是能将架构角色与其他两个角色纳入同一个系统(具体的工程实施)来讨论的前提。

(2) 方向。架构角色在方向领域上与经营者(或更宽泛地称为架构需求的提出者)保持一致,了解阶段目标与方向之间的关系,并通过架构产出、指导、推进和实施等一系列工作来把握这种关系。

(3) 范围与联接件。架构的主要产出是对范围进行的约束,对目标的关键构件之间的联接件的设定。并且还需要在实施过程中调适架构最初的约束与设定,平衡由时间、信息等因素带来的目标与方向之间的衍变。

评论

发布