如果您是软件架构师（或什至是解决方案或企业架构师），您会每天遇到一个需要解决的重要问题。选择和决定要在项目中使用哪些技术；无论是在您的公司环境，启动，个人项目还是其他方面。
在这篇文章中，我将探讨架构师在选择技术时应考虑和研究的几个关键方面。这绝不是建筑师需要考虑的要点的详尽列表。在这方面还有许多其他因素需要考虑。但是，我讨论的观点最突出。同样，这些事实并不是新事物，而是一些我们可能认为不够充分的已知事实。我非常高兴学习架构师在选择技术时必须而且必须考虑的其他重要方面。
如今，该技术正在快速变化，您可能不时听到新兴的JavaScript框架。在过去的十年中，该行业带来了新的趋势，参考架构，编程语言，DevOps工具等等。一些已有十年历史的技术仍在发展。选择无数。建筑师必须每天做出决定。
您还将遇到各种主题的斗争；Angular或React，开源或专有的，基于配置的代码或基于代码的配置，云，本地或混合，容器或裸机，SQL或NoSQL等。因此，当建筑师选择一种技术时，无论是库，框架，编程语言还是供应商产品，如今都没有被认为是一件容易的事。我应该提供新的供应商产品吗？我是否应该只使用那种编程语言的流行Web框架来构建Web应用程序？这是否应该是云解决方案等？今天，架构师必须出于充分的理由回答这类问题吗？
如果组织内的架构师无法达成共识，企业通常会聘请顾问架构师做出公正的决定。大型企业将有许多架构师，负责业务，产品或项目乃至整个领域的技术架构。通常，做出影响多个团队的决定并不容易。是的，如果您相信我，它可能会变得如此政治化，特别是在选择供应商产品时。在这种情况下，企业甚至要求架构师发布RFP，以使供应商做出回应并仔细审查整个选择过程，其中该过程将涉及多个提供技术选择要点的实体。
因此，架构师应该对为什么要做出某些决定以及为什么这样做会对手头的工作有所帮助有一个据点。以下几点是需要考虑的一些高级方面。
需求
首先，有必要。如果架构师试图选择一种技术，仅遵循趋势，那么他/他可能会带来很多麻烦。您有多少次看到人们想探索这种炫酷的技术，因为他们偶然发现了这种技术，并想将其突然纳入公司发展的各个方面？如果企业出于战略原因而具有技术远景，那绝对是很好的。然后，建筑师将获得所有的绿灯。
例如，如果企业架构师认为容器和编排工具已成为未来的一切，并尝试引入docker和Kubernetes，那么我敢肯定您会认为这是不明智的，除非他们有明确的需求。公司考虑长远并且有远见。如果他们的目标之一是适应不断变化的数字需求，可伸缩性，所有服务和应用程序的高可用性，并具有使其能够为使用的商品付费的弹性，那么，现在该考虑这种技术了。因此，请记住需要。
另一个示例是为了进行更改而试图在高效的平台中进行更改。例如，某公司的应用程序可能具有分层体系结构，并且在ROI上显示出了出色的结果，然后架构师试图引入诸如微服务体系结构之类的新体系结构是不明智的。首先评估需求。
这并不是说，架构师不应尝试带来变化。如果改变是不可避免的，那么他/他应该坚持下去。否则，创建需求。
成本
我不想再强调这一点。每个人都了解金钱方面的细节。这是一种不需要进一步强调的语言。但是，如果我们不能自掏腰包，事情可能会有些松懈。是不是
在企业范围内，预算至关重要。作为一名架构师，要求您评估公司领域中所有应用程序的监视产品。您需要记住为此设置的预算。建筑师在看完分析师的报告后可能会选择这种精美的软件，只是发现它每年花费50万美元，而设定的预算仅为几千美元。
因此，在进行进一步分析之前先了解成本的影响，即可过滤出无论多么酷的软件几乎都无法进入公司的软件。这可能会导致架构师查看其他选项，甚至评估现有选项并查看其是否可以增强。
开源或专有
在过去的一两个十年中，OSS变得非常流行，甚至那些反对它的公司也开始拥抱它。但是，并非所有软件都是开源的。如今，由于开放软件的特性和查看驱动其应用程序的代码的能力，如今一些企业只看开源软件。万一绝对需要，他们有地方可以看看，而不是面对供应商的锁定。
公司的历史也可能促使架构师仅选择专有软件。原因可能是多种多样的，政治上的或历史上的锁定。但是我敢肯定，您可能会遇到X-Shop，Y-Shop等公司。根据需要填写X，Y。在涉及供应商技术时尤其如此。即使不是其他类型的软件（例如库，框架，DevOps工具和编程语言）通常也不关心的问题，但某些公司可能也容易受到此影响。
无论如何，记下管理层可能会接受的一个。如果他们乐于接受任何事物，那么您也可以继续考虑其他因素，寻找适合您的事物。
许可证
许可证是选择技术时要考虑的重要事实。这对于库和框架来说甚至很重要。假设您的团队正在开发一款封闭源代码的商业软件，但愿意使用开放源代码库或框架。架构师在选择具有正确许可证的软件时需要谨慎。法律建议是必须的。一些开源软件许可证要求衍生软件也必须是开源的。有这样的后果要考虑。
甚至开源供应商软件也具有不同类型的许可证。一些开源软件允许您出于任何目的运行。但是下载的打包软件可能会有限制。如果您只想在无须付费许可的情况下使用开放源代码，则源唯一版本可能是您唯一的选择。一些软件许可证要求派生的软件源也必须是开源的，有时还要求在同一许可证下发布软件。
即使您愿意付费，要么是因为该软件是专有软件，要么是OSS需要一些商业支持约束力，因此，重要的是要获得许可并与供应商的联系点联系以了解更多信息。有些软件有音量限制，有些条款要求您在停止OSS付费许可证的情况下删除更新，有些则要求您完全拔掉插头。
成熟度
除非您进行实验，否则您可能不想仅仅因为选择了一个不成熟的产品，库或框架，就面临着前所未有的问题而花了六个月的时间。
如果您为一项关键任务项目选择一种技术，那么一个重要方面就是要知道您正在评估的技术有多成熟。可以使用几年的发展，几个发行版（而不是版本号），具有可靠案例研究的客户群以及许多其他因素来评估成熟度。
评估技术的一种关键方法是，您的团队要进行概念验证（PoC），而不是供应商的团队或提供商业支持的任何人。当然，如果需要，您可以得到他们的帮助，以更好地理解。大多数情况下，这应该为您提供足够的线索，说明该技术可以满足您的需求。
文献资料
文档是当今软件的重要组成部分。好的技术将成为具有更多细节和信息的伟大技术。文档绝对是其中之一。
检查所选技术文档的难易程度。一些库，框架很棒，但是它们缺少妨碍其使用的文档。它要求您的团队在进行任何有用的操作之前都要过山车。架构师应该考虑开发人员以及古玩交易外行人员如何轻松通过它并加快速度。超级明星开发人员会向建筑师推荐技术，而他们可能有机会在几个月甚至几年的时间里以不同的视角来研究技术。本身不应该盲目地接受这种技术，而这会使整个团队处于旋风之中。
清晰，简洁的文档着重于正确的用户，这一点很重要。如果是库，框架，DevOps工具之类的技术，则目标受众是开发人员或DevOps。如果打算供非技术人员使用，请查看产品的用户友好程度，以及在不了解产品技术复杂性的情况下如何轻松找到有关产品使用的信息。不存在，请寻找其他选项。
团队专业知识和社区
我们都知道众包的力量。有很多人尝试技术，谈论技术，报告和解决问题都具有很大的吸引力。它暗示了很多人对该技术感兴趣，这应该是由于一些良好的原因。相信社区纽带并不坏。但是请记住第一点，极品。如果您有需要，并且有一个健康的社区，那么您会取得很大的领先。
但是，社区是技术的重要事实。该技术是开源还是专有社区驱动力。
与社区一起出现的另一个事实是团队的专业知识。社区将为建立团队专业知识提供巨大的投入。如果架构师试图推荐一种似乎没有强大社区的技术，那么他/他可能会使整个项目/产品处于危险之中。如今，开发人员喜欢学习他们认为会获得更好认可的新技术，因此，如果他们碰巧再次进入就业市场，他们会获得更多机会。如果引入市场上没有需求的技术，开发人员将表现出他们的阻力，最终将在解决方案中显示出结果。这当然与团队正在尝试做的成功有关。
因此，取得平衡。了解这一事实是一门艺术，而不是一门科学。
牵引力和路线图
除非您没有其他选择，否则您将不想使用已死或垂死的项目/产品来构建解决方案。知道技术的发展方向对关键的企业规模项目至关重要。作为建筑师，选择技术时不能忽略这方面。
对于开源的库和框架，您可以查看提交历史记录以及将来期望的功能。即使对于开源产品，您也可以通过查看发行历史记录，发行说明和更新周期来了解其发展趋势，从而确定其发展方向。
对于供应商产品，您可以随时联系供应商团队以了解产品路线图。建筑师通常需要考虑使用寿命至少为5年的产品，以对其进行有意义的处理。实际的年数根据您要建造的房屋而有所不同。
支持与服务
对于库，框架和编程语言，这可能并不那么关键。一些框架和库由可能也提供支持和服务的公司支持。但是对于企业级供应商产品，架构师不能忽略这一事实，他们需要了解支持和专业服务选项。通常，当公司选择付费支持许可证，订阅或他们可能称呼的任何形式时，供应商就会提供支持。
即使团队具有强大的开发背景，架构师也不应该忽略专业服务。选择新产品后，团队需要在某些领域提供专业服务，这是因为眼前的问题需要您自己解决，或者需要花费大量精力才能使其正确解决。无论是什么原因，企业架构师都应该意识到这些选择。
一些供应商拥有强大的合作伙伴渠道和完善的SI（系统集成商）系统，可以帮助您实现这一目标。因此，还应考虑供应商的渠道实力。
TL; DR
如今，架构师在选择分配给他们要解决的问题的技术时，不断需要做出重要的决定。在当今的数字世界中，有很多选择，选择技术本身通常是一个漫长而乏味的过程。
架构师在选择技术时应注意很多方面。该帖子讨论了一些关键点。我敢肯定，在做出决定之前，架构师可以考虑更多方面。
