Architecture 评估大型项目的架构和技术选项

在工作中，我们刚刚获得资金，开发一个复杂的面向研究的信息系统供内部使用。该系统必须支持100多名科学家和技术人员的日常工作，管理10 TB的数据，并可远程和本地使用。这些数字将以每年大约10%的速度增长

我是指定的项目经理。虽然我在一些可能适用的建筑风格和一些我们可能选择使用的技术方面有着丰富的经验，但如果没有仔细考虑所有可用选项以选择最佳选项，我不想开始这个项目。为此，我想对架构和技术方面的选项进行某种评估。执行这些评估有几种选择，例如在内部进行评估（负担得起但耗时，可能不太可靠），请外部方为我们进行评估（可能很昂贵），依靠现有报告或以前的工作，或所有这些的组合

我的问题是：

在我们开始项目的工程阶段之前，您认为这种评估是一个好主意吗？值得吗

你认为我们应该如何进行评估？有哪些基本方法，它们的优缺点是什么

---

谢谢。

有些事情需要做：

• 询问您正在考虑提供与您的案例类似的参考资料的技术供应商，并与这些参考资料交谈
• 做一个概念验证，使用一个真实的垂直方向来展示你想要构建的东西

---

我们使用基于透视图的体系结构来进行此类选择，请参见

我同意@Shiraz关于概念验证的观点，特别是确保系统的各个部分进行适当的沟通。可以结合他的答案的要素，在时间和专业知识方面都有所收获（详情如下）。我想说的是，我会认为你所考虑的这种评估是必要的——它很可能是一个成功的项目和一个时间和金钱的损失之间的区别

我曾参与评估一个系统的体系结构，以满足3000多名为多个平台开发的软件开发人员的需求。该系统不像您的系统那样数据密集，但我们之前已经完成了评估数据库功能和生产系统大小的工作，该系统大约比您的数据大50%

我们选择的数据库评估步骤之一是与学术界建立一个联合项目，以评估大型系统的性能。那时RDM还很新，我们找不到有过我们设想的那种使用经验的人。双方都从中获益；与咨询或聘请专家相比，我们以更低的成本获得了我们想要的结果；他们得到了一个实质性的研究项目和资金

在评估开发环境的体系结构时，我们起草了一份需求规范，然后进行招标。然而，招标过程的独特之处在于，我们要求入围名单上的开发商在为期一周的交易会上与竞争摊位上的所有其他开发商展示其提案的垂直部分。然后，我们为所有参加交易会的开发商提供机会，让他们提问、测试提案，并就他们的经验向我们提供反馈。大约45%的开发人员利用了这个机会，能够对竞争解决方案进行深入审查。这给了我们综合的专业知识和不同的观点，充分利用了我们现有的内部资源，并促使供应商向流程提供大量技术投入。这也是非常快的（大约6周，为3-4人设置这部分招标，然后是交易会的一周，然后是几周，收集和比较交易会产生的数据）

---

我提到了系统元素之间的通信问题。在上述两种情况下，仅保证（例如）这两个部分都使用SQL；或者双方都使用标准化SQL；或者他们声称遵守标准；他们有必要证明在系统的一个部分生成的SQL可以被系统的另一个元素读取和操作。这给我们和供应商带来了一些冲击，他们通常不那么遵守标准按照他们声称的标准。

谢谢，设拉子。很好的链接和建议，我会尽快查看。