软件架构本是软件工程师的一项职能？

在软件行业，似乎普遍认为软件架构和软件工程是截然不同的。在很大程度上，软件架构关注的是设计，而软件工程关注的是实现（即编写代码），两者在某种程度上是相互独立的。从根本上说，两者之间的联系大致类似于建筑行业中建筑师和土木建造师之间的关系。

但是，这并不代表软件开发的实际情况。有用的软件架构必须考虑如何在相对细化的层次上实现系统（例如，如何对集成点进行编码就很重要），理想情况下，设计系统的人和实现系统的人应该是同一个人。

为此，我认为软件工程师应该是一个统称，而软件架构则是软件工程师可能履行的一项职能。

大规模公司架构
O'Reilly 有一本名为《促进软件架构》的书在讨论这个问题：书中谈到，在大型应用程序中，需要有人维护系统的高层视图。

你确实需要每个软件工程师提高他们的架构技能（尤其是人工智能正在如何改变工作流程），但你也需要有人能在团队需要了解更大的系统以及该系统如何与业务目标互动时提供帮助。

在任何规模的公司中，你都需要团队专注于他们所定义的上下文，而且他们绝对需要掌控这些上下文。

不过，现在的架构师更多的是顾问，而不是设计师，如果你让架构师参与每一个设计决策，那么你根本无法很好地进行扩展。

软件工程就是要落实到最小的细节。但设计和实施细节需要由架构师给出。

上下文是决定因素
所有软件工程师都是软件架构师。从写作业的大学生到程序员再到首席架构师。我们都做出设计决策，设计和开发软件，但范围不同。

如果开发人员在该领域的进步稳定，经验和范围成正比。当然也可能无法达到总架构师级别。

要么是因为他们不能或不敢，要么是因为他们喜欢编写太多代码而无法放弃。

认知负荷
架构师的职责是为工程团队提供服务和支持。他们的工作是帮助管理团队内的认知负荷，这样他们就不会完全淹没在分析和设计中。他们教他们如何构建平台，同时给予他们一些初始约束（或护栏）。架构师大部分时间都花在帮助他人上，但也会花一些时间设计新的解决方案（即作为概念验证，在开始全新模式时等）。

在更高的层面上，架构师将定义“有意的架构”，同时授权团队使用“紧急设计”。这是 SAFe 的一个概念，实际上在更大、更复杂的组织中非常有意义。要避免的重要事情是臭名昭著的象牙塔，架构师像戒律一样交付他们的设计。

无论如何像“架构师”甚至“工程师”这样的头衔很有用，因为它们可以帮助我们说服上司给我们更高的工资。为什么要修复没有被损坏的东西呢？存在即合理。