软件架构师是一个角色，不是一项工作
架构与实现的分离
在公司晋升体系中，软件开发者可以成长为软件架构师。架构师通常位于一个架构团队，这个团队负责早期应用架构设计，开发节点的验收，产品发布前的批准。
开发团队接收架构师的要求。在开发中，开发团队在某些检查点或者当架构师定义的要求无法完成时与架构师进行沟通。
产生鸿沟
Doug Sundheim的文章消除战略和执行之间的鸿沟见解独到地描述了当架构师与开发团队分离工作所产生的风险和失衡。
我同意Doug—尤其是与软件项目相关的内容：
| “过程总是有点不愉快。执行者粗浅的视角与战略家高远的视角总是区别很大。” |
架构师呆在与实现独立的角色中时间越长，他们对新工具、流程、范型的成熟度和风险的评判越不合格。架构师预先进行的决策变成了开发团队的痛苦。开发者对看不见摸不着的架构师很失望。架构师对“敌对的”开发团队也很失望。
我怀疑，建立或维护一个将战略和执行分离的组织结构的管理者认为，双方的人员能够合理地行动，建立联系，有效地沟通来完成工作。但是就像Doug阐述的一样：
| “不幸的是，完全不是那回事。实际上经常发生的是双方都在踢皮球。最坏的情况，战略者怀有优越的、分离的观念：我们是思考者，其他人会付诸实施。他们不花点心思来搞明白实现这个想法需要什么。他们不提前与执行者沟通询问，“这实际上怎么实现呢?”执行者也有责任。通常，他们并不完全理解这个战略之下的想法。他们只取表面含义，并且不详细询问... “问题是双方都不认为自己有责任理智地将双方拉回来。他们之间产生了鸿沟，并希望这个鸿沟能够奇迹地自我愈合。但它不会。事情就因此而失败。” |
Doug总结出，战略者和执行者消除鸿沟用的是信念(beliefs)而不是过程(process)。你应该读读Doug文章中总结的信念。他们总结了在一个等级组织结构下团队或个人共同工作的观念模式(mindset)。
更好的、一体的结构
我怀疑分离的架构工作和团队的出现包括以下原因：
- 雇佣效率(工作描述和经验要求)
- 运营效率(分配架构师到各个团队)
- 晋升和职业成长激励
但是我认为，一个更好的能将架构和实现团队组成一体的组织结构，也能满足上面观点所代表的逻辑。架构和实现不应该是分离的工作。
一个组织应该雇佣高级开发者来负责架构，而不是雇佣架构师。每个开发团队都应该有一个人来负责架构工作。这个负责架构的人应该对团队效益负责，而不是命令。
详细地说，将架构师安排到实现团队有如下好处：
- 消除战略和执行的分离，以及与此组织结构相关的功能失调风险。
- 架构师可以在实现的整个过程作出决策并收到反馈。反馈循环可以提升学习和未来更好的决策。
- 架构师可以对开发过有所贡献。
- 架构师可以了解在实现过程中有很大帮助的新工具、过程和范型。
- 架构师可以教授初级开发者架构和开发实践。架构师身处早期架构决策，期间不断编码，能偶与团队成员建立和维持互信和尊重。互信和尊重能够促进教学相长。
总结来说，一体架构方法能够形成：
- 提升的士气
- 提升的质量
- 提升的执行速度
- 产品开发过程中的员工自由发展
使用一体架构模型的雇佣效率不会比传统上雇佣架构师的方式更有挑战性。雇佣有架构经验并且不愿意放弃写代码的高级开发者。
运营效率可以使用Spotify组织模型中的几个观点来保留。架构师可以通过参加Chapters和Guilds(Spotify组织模型的术语，意思是各种协会)互相支持、互相学习。Chaperts和Guilds使不同团队的架构师可以分享知识和工具，所有团队都能从中受益。个人、团队、公司的成长会更快。单个团队的独特见解可以带来放大的规模效益。
晋升和职业成长激励也简单。当有人胜任架构师角色时，奖励他们获得了一项能力，而不是晋升他们到一个新的工作。给予认同，并相应地调整薪酬。
一体结构的风险
一体架构模型的一个风险是架构师可能聚焦在实现上。在架构和实现职能间的切换可能导致结构和纪律变得松散。