我为一家几乎是大公司初创公司的组织工作。该团队拥有多名数据库工程师和一些软件工程师（在数据挖掘领域）。我们正以快速增长，这需要在未来几年内制定整体架构战略或技术路线图（或指南针）。作为一名软件工程师，我被赋予了开始双月会议以引导讨论的任务。所以，我的问题是，你如何启动你作为建筑师的角色？你如何开始组织范围的架构讨论？ 我开始阅读“软件架构师应该知道的97件事”这本书，但我想从你的经历中听到更多。那么，作为一名建筑师，你是如何开始的？
致以最诚挚的问候，
答案 0 :(得分：3)
在你知道自己的开始之前，不要开始讨论架构。除非其他人也这样做，否则不要开始讨论架构。
答案 1 :(得分：3)
您的问题很难，因为它触及了许多领域：流程，领导力和软件设计（或架构）。我将假设您已经有一个标准流程，但如果您没有，那么请尝试其中一个敏捷流程。我将谈论领导力和软件架构。
<强>领导即可。弗雷德布鲁克斯的伟大着作The Mythical Man-Month谈到了一个技术领导者，就像手术团队有领导者一样。就个人而言，我喜欢比医生看到的更多合作，所以让我们将布鲁克斯的外科团队视为极端。但是，你需要有人在技术上协调谁正在做什么，比如分配人员在系统的不同部分工作，决定最难（最危险）的部分是什么（这样他们就不会被推迟，直到他们付出昂贵的代价。改变/修复），并在团队不同意时做出选择。无论您是在制造软件，汽车还是弹簧杆，都需要这种技术领导力。
<强>建筑/设计即可。标准的口头禅是“每个系统都有一个架构”，但必然结果是不是每个架构都是故意选择的。您可以隐式地从上一个项目中复制架构，比如一个3层系统。或者，一旦您知道自己正在使用像EJB这样的框架，就可以预先确定它。在项目开始时，您将做出架构决策，有些将很难在以后更改。你将如何坚持数据？你会使用一个框架（例如Spring，EJB，RoR）吗？您是以增量方式还是批量处理数据？
几乎任何架构都可以被迫满足您的要求。例如，您可以使用RoR构建恒温器。但是，当您的架构非常适合需求时，您将会更轻松。有时您会有一些要求，例如较低的用户界面延迟，这些要求可以通过明智的架构选择来帮助，例如使用AJAX。因此，项目的开始是一个思考这些事情并使其正确的机会。 （这并不意味着你上山，认真思考，然后决定你对团队的回答 - 这里我再次赞成合作）。
不要害怕预先考虑建筑，尤其是它可以帮助你避免困难的方法，但也不要试图提前做出决定。如果团队的一部分开始使用Ruby on Rails而另一部分开始使用EJB，那么你会遇到麻烦 - 所以做出一些技术决定，那些强加给你的决策以及那些能解决你最大风险的决策。
最后一件事：早期的建筑讨论是一种祝福和诅咒。他们是一个祝福，因为他们提前得到想法，让你选择你的设计而不是犯错误。但是他们是一个诅咒，因为每个人都会有意见，并且很难让他们都指向同一个方向（即回到技术领导的需要）。
我建议Applied Software Architecture的第12章提供有关您问题的指导。标题列表很好地概括了它的建议：创建愿景，建筑师作为关键技术顾问，建筑师制定决策，建筑师教练，建筑师协调，建筑师实施，建筑师倡导者。你提到的97 Things书更多的是一系列智慧珍珠，而不是一个有凝聚力的建筑指南。
乔治费尔班克斯，Just Enough Software Architecture的作者
答案 2 :(得分：1)
我个人没有这种经历，但这里有一些提示：
答案 3 :(得分：0)
这不仅来自经验，更多来自实践思维。首先，很难定义软件架构 - 开始的一个很好的参考始终是'design patterns explained'，因为这需要一种非软件方法来理解架构。
开始研究架构的具体核心问题，例如
架构不是要消除复杂性，而是关于管理它。因此，首先要了解项目环境中包含复杂性的问题
答案 4 :(得分：0)
专注于非功能性需求，并从那里尝试选择一种架构模式。软件质量分析将很有帮助。然后我会根据他们感兴趣的粒度级别对模式进行修饰并向团队描述。