问在哪个阶段决定TOGAF技术栈和平台(java、.net、mobile等)。

EN

基本上，这取决于您的需求。重要的是要记住，TOGAF只是一个需要为您当前的企业量身定做的框架。您可能不需要ADM的所有阶段即可成功使用该框架。

...in我们为新应用程序定义技术堆栈的阶段...

话虽如此，它通常是Preliminary Phase/Phase A或Phase D：如果你的架构工作的主要目标是迁移(或创建)特定的技术(java，.net等)，我建议在开发/更新Architecture Principles期间用Preliminary Phase或Phase A解决这样的决定。如果这不是你的主要目标，但它支持你的Architecture Vision，那么它通常是Phase D -其中一个输出是更新的Architecture Definition Document，特别是Target Technology Architecture，Version 1.0 (详细)：技术平台及其分解，显示实现特定技术“堆栈”所需的技术组合。

...and在什么深度...

此定义的深度还取决于您的需求:它可以像您需要的那样详细。

...if会是移动应用、web应用还是混合应用？

这个决定类似于第一个决定:如果您的主要目标(例如，在Request for Architecture Work中声明的)是将您的应用程序更新为移动友好的，那么应该尽早解决这个问题。但这种需求也可能会在Phase B期间出现--你的利益相关者可能会说，让这款应用对移动设备友好是至关重要的。

TOGAF是一个架构框架。

主要用于企业架构项目、交付和团队。好的企业架构(EA)是设计不可知的。与技术相比，EA更贴近业务。但它对成功至关重要，因为它定义了为什么问题的答案。为什么我们需要一个网络？什么样的网络？为什么我们需要分布式IT系统？或者相反的，诸如此类的。

EA本质上是通用的。

EA定义了设计的要求，包括大小、容量、能耗、性能等。

类比:城市规划。

EA就像城市规划师。他们没有规定任何关于建筑物设计的规定。

TOGAF可以在EA宏观级别下使用(特别是ADM)，但这在很大程度上是TOGAF的未知领域。

戴上我们的EA“帽子”，当我们说“网络”(在EA的领域中)时，这与技术或解决方案体系结构领域中的“网络”不同。但仅此而已。

这一切看起来都很抽象，因为它确实如此。抽象思维能力对于良好的EA来说是最重要的。这就是EA的困难之处。

也许您可以选择软件设计和开发的一种流行的敏捷开发方法来指导您选择技术堆栈？

基于TOGAF标准9.2，虽然没有明确说明，但我认为您第一个问题的答案

我们在哪个阶段定义新应用程序的技术堆栈(如果这是一个自定义应用程序)以及深度。比如，它是移动应用、web应用还是混合应用。将使用哪个平台来构建它，等等

阶段D技术架构是否基于阶段D中的一个输出：

目标技术架构，1.0版(详细)，包括：…技术平台及其分解，显示了实现特定技术“堆栈”所需的技术组合

关於第二个问题：

如果

是现成的产品/服务，我们什么时候最终确定它。

在TOGAF中，商用现成(COTS)产品和第三方服务提供商通常被视为可重用的解决方案构建块，您将在阶段E中完成这些构建块作为阶段目标之一：

E阶段的目标是：…基于体系结构构建块(ABB)

对整体解决方案构建块进行.Define，以最终确定目标体系结构