软件架构师是一个角色,不是一项工作

标签: 软件 架构师 角色 | 发表时间:2015-03-06 16:51 | 作者:
出处:http://kb.cnblogs.com/

   英文原文: Software Architect – A Role, Not a Job

  一个产品开发组织结构中,软件架构的团队与开发团队分离,可能成为功能失衡、质量低下、士气不振的祸因。

  架构与实现的分离

  在公司晋升体系中,软件开发者可以成长为软件架构师。架构师通常位于一个架构团队,这个团队负责早期应用架构设计,开发节点的验收,产品发布前的批准。

  开发团队接收架构师的要求。在开发中,开发团队在某些检查点或者当架构师定义的要求无法完成时与架构师进行沟通。

  产生鸿沟

  Doug Sundheim的文章 消除战略和执行之间的鸿沟见解独到地描述了当架构师与开发团队分离工作所产生的风险和失衡。

Architecture

  我同意Doug—尤其是与软件项目相关的内容:

“过程总是有点不愉快。执行者粗浅的视角与战略家高远的视角总是区别很大。”

  架构师呆在与实现独立的角色中时间越长,他们对新工具、流程、范型的成熟度和风险的评判越不合格。架构师预先进行的决策变成了开发团队的痛苦。开发者对看不见摸不着的架构师很失望。架构师对“敌对的”开发团队也很失望。

  我怀疑,建立或维护一个将战略和执行分离的组织结构的管理者认为,双方的人员能够合理地行动,建立联系,有效地沟通来完成工作。但是就像Doug阐述的一样:

“不幸的是,完全不是那回事。实际上经常发生的是双方都在踢皮球。最坏的情况,战略者怀有优越的、分离的观念:我们是思考者,其他人会付诸实施。他们不花点心思来搞明白实现这个想法需要什么。他们不提前与执行者沟通询问,“这实际上怎么实现呢?”执行者也有责任。通常,他们并不完全理解这个战略之下的想法。他们只取表面含义,并且不详细询问...

“问题是双方都不认为自己有责任理智地将双方拉回来。他们之间产生了鸿沟,并希望这个鸿沟能够奇迹地自我愈合。但它不会。事情就因此而失败。”

  Doug总结出,战略者和执行者消除鸿沟用的是信念(beliefs)而不是过程(process)。你应该读读 Doug文章中总结的信念。他们总结了在一个等级组织结构下团队或个人共同工作的观念模式(mindset)。

  更好的、一体的结构

  我怀疑分离的架构工作和团队的出现包括以下原因:

  • 雇佣效率(工作描述和经验要求)

  • 运营效率(分配架构师到各个团队)

  • 晋升和职业成长激励

  但是我认为,一个更好的能将架构和实现团队组成一体的组织结构,也能满足上面观点所代表的逻辑。架构和实现不应该是分离的工作。

  一个组织应该雇佣高级开发者来负责架构,而不是雇佣架构师。每个开发团队都应该有一个人来负责架构工作。这个负责架构的人应该对团队效益负责,而不是命令。

  详细地说,将架构师安排到实现团队有如下好处:

  • 消除战略和执行的分离,以及与此组织结构相关的功能失调风险。

  • 架构师可以在实现的整个过程作出决策并收到反馈。反馈循环可以提升学习和未来更好的决策。

  • 架构师可以对开发过有所贡献。

  • 架构师可以了解在实现过程中有很大帮助的新工具、过程和范型。

  • 架构师可以教授初级开发者架构和开发实践。架构师身处早期架构决策,期间不断编码,能偶与团队成员建立和维持互信和尊重。互信和尊重能够促进教学相长。

  总结来说,一体架构方法能够形成:

  • 提升的士气

  • 提升的质量

  • 提升的执行速度

  • 产品开发过程中的员工自由发展

  使用一体架构模型的雇佣效率不会比传统上雇佣架构师的方式更有挑战性。 雇佣有架构经验并且不愿意放弃写代码的高级开发者

SpotifyModel

  运营效率可以使用 Spotify组织模型中的几个观点来保留。架构师可以通过参加Chapters和Guilds(Spotify组织模型的术语,意思是各种协会)互相支持、互相学习。Chaperts和Guilds使不同团队的架构师可以分享知识和工具,所有团队都能从中受益。个人、团队、公司的成长会更快。单个团队的独特见解可以带来放大的规模效益。

  晋升和职业成长激励也简单。当有人胜任架构师角色时,奖励他们获得了一项能力,而不是晋升他们到一个新的工作。给予认同,并相应地调整薪酬。

  一体结构的风险

  一体架构模型的一个风险是架构师可能聚焦在实现上。在架构和实现职能间的切换可能导致结构和纪律变得松散。

  如果Chapter和Guild的沟通不能提供足够的检查和平衡,团队应该经常使用 暂时休息并把握整体规则。让团队在一个总体高度来审视自身工作有没有满足整体的架构方案。

相关 [软件 架构师 角色] 推荐:

软件架构师是一个角色,不是一项工作

- - 博客园_知识库
   英文原文: Software Architect – A Role, Not a Job.   一个产品开发组织结构中,软件架构的团队与开发团队分离,可能成为功能失衡、质量低下、士气不振的祸因.   在公司晋升体系中,软件开发者可以成长为软件架构师. 架构师通常位于一个架构团队,这个团队负责早期应用架构设计,开发节点的验收,产品发布前的批准.

软件架构师的沟通修炼

- - 博客 - 伯乐在线
在架构师的角色中,沟通是要求有效果的必备技能与工具. 换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段. 架构师通常没有对为其项目工作的他人的直接管理权. 他们的项目往往是跨部门的,也可能会跨好多个行业单位. 由于不能直接管理他人,所以架构师指示别人或群体完成特定行动的能力就受到限制.

软件架构师的职责

- - 研发管理 - ITeye博客
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调.     在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可. 架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求.

【译】软件架构师之路

- - 掘金架构
今天给大家带来一篇自己翻译的干货《软件架构师之路》. 本周Github上升很快的项目. 其内容对致力于成为软件架构师(不论前后端)的同学应该都会有极大的帮助. 中文地址 github.com/gamedilong/…. 原文地址 github.com/justinamill…. 如果有看完英文原文,发现本文翻译内容中存在问题或者错误的欢迎到中文Git地址PR,如能够对大家起到一定的帮助也欢迎star.

软件架构师不等同于资深程序员

- - 研发管理 - ITeye博客
本文的作者Armel Nene是ETAPIX Global公司的首席架构师,他居住在伦敦,他参与过的开源项目包括 Apache Lucene,,Apache Nutch, Liferay 和 Pentaho等. 如今很多的公司的IT部门仍然认为招聘一个资深的程序员,他同样也能承担软件架构师的角色. 资深程序员对整个软件生命周期很了解,他们可以经过培训成为架构师,但他们不等同于架构师.

如何做一个好的软件架构师

- - Dawei XU
最近有人问我一个好的架构师需要哪些能力,我回想了一下自己差不多10年的架构师生涯,又去网上搜了一些什么是好的架构师的文章,把自己觉得重要的东西总结在了下面. 技术方面就不多说了,这篇文章主要谈谈非技术方面的软实力. 我们首先从架构师的日常工作开始说起,当然每个架构师的工作会不尽相同,我下面列了一些我日常工作中需要做的事情.

业务分析师和业务架构师角色的对比引发热烈争论

- - InfoQ cn
Nick Malik是微软的企业架构师,他最近写了一篇 博客,讲述了业务分析师和业务架构师的区别,而且很快就有人批评他的立场. Malik力主:业务分析师与业务架构师的工作有本质上的不同. 但是国际业务分析师协会(International Institute of Business Analysts,简称IIBA)的Kevin Brennen 强烈反对,并指出这两种角色的相似之处.

对大宋下一代系统软件架构师的七个期望

- joyoner - 弯曲评论
有诗云:人之老,其言真;人之去;其行善. 系统软件设计是软件系统的皇冠中的宝石. 在系统软件,特别是通信系统软件的设计上,有没有一些可以提炼的方法论. 今身处幽州(北平),心在大宋. 谈谈我对大宋年轻一代的系统软件工程师的期望. 年轻人都以为有些事情需要粗,有些事情需要厚. 系统软件一定要越细越好;越薄越好.

软件架构师应该知道的97件事(极致总结)

- - CSDN博客推荐文章
 软件架构师是IT 行业里独一无二的职业,既要精通软件开发技术,又要掌握业务知识,还要周旋于公司不同部门之间,协调各种予盾. 简洁的总结下,希望对读者有帮助. 1.客户需求重于个人简历. 为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违. 2.  简化根本复杂性 ,消除偶发复杂性. 根本复杂性指的是问题与生俱来的、无法避免的困难.