architecture - "Solutions Architect"和 "Applications Architect"有什么区别？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




据我所知解决方案架构师 只是 的不同“营销”术语应用架构师 .这是正确的还是角色实际上有所不同？如果是这样，如何？

是的，我在 StackOverflow 和 Google 上都搜索过这个。

Answer 1

2018 年 1 月 5 日更新 - 在过去的 9 年里，我的想法在这个话题上有了很大的发展。与大多数人相比，我倾向于更接近我们行业的前沿(尽管肯定不会像许多真正聪明的人那样突破界限)。我一直是不同级别的架构师，从应用程序到解决方案，再到企业，在多个大大小小的公司。我得出的结论是 我们技术行业的 future 几乎没有建筑师 .如果这对您来说听起来很疯狂，请等待几年，您的公司可能会迎头 catch ，或者发现这一点的竞争对手会 catch (并超越)您。根本问题在于，“架构”只不过是对您的应用程序/解决方案/产品组合所做的所有决策的总和。所以“建筑师”这个头衔的真正意思是“决定者”。这说了很多，也包括它没有说的。它没有说“ builder ”。创建一个职业道路/层次结构，隐含地告诉人们“构建”低于“决定”，“决策者”不直接负责(通过标题的差异)“构建”。那些仍然坚持自己的建筑师头衔的人会对此感到恼火并抗议“但我亲自动手!”太好了，如果您只是一名建筑商，那么请放弃您毫无意义的头衔，并停止将自己与其他建筑商区分开来。强调“所有 build 者都是决策者，所有决策者都是 build 者”的公司将比竞争对手行动得更快。我们对每个人都使用“工程师”这个称号，“工程师”意味着决定和 build 。

原答案 :

对于从未在大型组织中工作过的人(或者曾经在一个功能失调的组织中工作过)，“架构师”可能在他们的嘴里留下了不好的味道。然而，它不仅是一个合法的角色，而且对于聪明的公司来说也是一个高度战略性的角色。

当应用程序变得如此庞大和复杂以至于处理整体技术愿景和规划以及将业务需求转化为技术战略成为一项全职工作时，这就是 应用架构师 .应用程序架构师还经常指导和/或领导开发人员，并且非常了解他们负责的应用程序的代码。

当一个组织有如此多的应用程序和基础设施相互依赖，以至于在不参与其中任何一个代码的情况下确保它们的一致性和战略是一项全职工作，那就是 解决方案架构师 .解决方案架构师有时可能类似于应用程序架构师，但涉及一组特别大的应用程序，这些应用程序包含业务的逻辑解决方案。

当一个组织变得如此庞大以至于协调解决方案架构师的高级规划和制定业务技术战略的条款成为一项全职工作时，该角色就是 企业架构师 .企业架构师通常在执行级别工作，为 CxO 办公室及其支持职能以及整个业务提供建议。

还有基础架构架构师、信息架构师和其他一些人，但就总数而言，这些人所占的比例低于“三大”。

备注 :许多其他答案都说这些标题“没有标准”。那不是真的。转到任何财富 1000 强公司的 IT 部门，您会发现这些标题一直在使用。

最常见的两个 误解 关于“建筑师”的是:

架构师只是一个更高级/收入更高的开发人员，拥有花哨的头衔

架构师是技术上毫无用处的人，多年没有编码，但仍然在业务中发挥作用，使开发人员生活困难

这些误解来自于许多架构师做得很糟糕，而组织在理解架构师的用途方面做得很糟糕。将顶级程序员提升为架构师角色是很常见的，但这是不对的。他们有一些重叠但不相同的技能组合。最好的程序员可能经常，但并不总是，一个理想的架构师。一个好的建筑师有一个 好 了解多 技术 IT行业的各个方面； 更好 了解 业务需求和策略比开发人员需要的更多；优秀 沟通技巧并且经常有一些项目管理和业务分析技能。对于架构师来说，保持双手接触代码并在技术上保持敏锐是必不可少的。好的。