Ted Neward看架构师的角色和责任

作者 Gavin Terrill 译者 郭晓刚 发布于 2007年9月26日

领域

架构 & 设计,

企业架构,

过程 & 实践

主题

企业架构 ,

客户及需求 ,

架构 ,

团队工作 ,

领导能力 ,

质量交付

标签

大企业病

Ted Neward最近分享了他对架构师的角色和责任的一些看法，以回应对一些针对架构师的责难。

第一个问题是关于“架构师做些什么”？

在我工作过的一些公司里，作为一名“架构师”，你需要沾手代码，并作为技术上的领导，同时也开发者，有时候又是项目经理。你总是要一边盯着客户/业务价值，一边又同样要盯着技术细节。在其他一些地方，架构师（或“架构团队”）只是给一群不得不升职的开发者（通常是出于年资的原因）的职位，他们除了转作管理之外并没有其它清晰的升职路线。然后这个“架构团队”会设立一些“公司标准”，通常是以“行业标准”为基础。他们一般并不理会这些标准对于底下真正面对问题的开发者有没有实用意义。

下一个问题是，架构应该是支持性的还是限制性的：

架构应该是支持性的，当然如此。从这个方面来说，一个好的架构应该帮助开发者更快速更容易地构建程序，而不需要花费大量时间重新为一个个项目分别发明出相似的基础设施。一个好的架构还应该有助于跨程序的互操作，保证代码质量，保证良好的可维护性，为将来提供扩展能力，等等。以上这些，我认为都属于“支持性”。

但架构也是限制性的。从这个方面来说，架构应该驱使软件开发者向着成功的方向前进，远离以后可能出问题的决策。换言之，正如Microsoft的CLR架构师Rico Mariani所说，一个好的架构应该让开发者“掉进成功的坑里”。在这样的架构里，你只需“随波逐流”，就可以做出正确的决策，达到我们前面所说的良好的软件质量。

最后的问题是架构师是否仍然重要：

Fowler说在敏捷项目里架构是无关紧要的，我差不多从根本上反对这样的说法：架构师是船长，要横跨多个领域，为各种事物做出决策（航路、轮机等等）。他为整艘船以及船上所有人员（项目及其团队）的整体健康担负着最后的责任，并且当有需要时，他能够站在任何岗位上履行职责（一旦失去某位成员时，项目的任何部分他都能为之编写代码）。他必须熟悉问题域和牵涉到的技术，他还要时刻留心任何可能对项目有帮助，或者可能满足客户的新需求的新技术。

这些观点跟Fred Brooks（《人月神话》的作者）的意见一致，Fred认为架构师是达成“概念完整性（Conceptual Integrity）”的关键角色：

概念完整性是产品质量的中心。拥有一名系统架构师是朝向概念完整性的最重要的一步……在一个软件工程研究室执教超过20次之后，我开始坚持即使仅有4个人的学生团队也要选出一名经理，以及一名架构师。

你对架构师的角色和责任有什么看法呢？

查看英文原文：Ted Neward's thoughts on Architecture Roles & Responsibilites

译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。

1. 返回顶部

   Fowler说在敏捷项目里架构是无关紧要的，我差不多从根本上反对这样的说法

   发表人 Yuan Shayne

   我怎么不记得Fowler有这么激进的言论？从Fowler的一些文章中可以看到他也认同架构设计的。
   Fowler倒是不赞成存在架构师这种称号，而是用 教练 来代替，其实干的活和上面的差不多

   回复

• 更早的 >