如何在敏捷世界中交付可靠的架构？这是一种创建适应不断变化的架构的方法。
有很多关于敏捷架构的文章，但我认为我们还没有一个公认的实践。
好的架构必须考虑许多不同的观点（技术和人的），并不断地权衡一个与另一个。
MVP 论点
有一种观点认为不需要架构，开发人员可以构建最小可行产品（MVP）。
对于简单的解决方案，这可能是一个有价值的练习。如果做得正确，MVP 可以提供许多帮助定义客户需求的经验。从这个意义上说，它是原型设计的一种形式。
但是，MVP 的任何增长都需要某种形式的架构。
备注：如果您有客户为解决方案付费，并且您建议向客户提供最低可行产品，这听起来像是“我们将根据的资金提供最低限度的产品”。但是，如果您说您将首先构建一个 MVP 以加速需求收集过程，然后最终会交给他们的一个强大解决方案，那是一个非常不同的提议。
作为交付 MVP 的项目的架构师，您需要帮助正确确定其范围。确保 MVP 是一次性的，或者更常见的是，当 MVP 回答问题时有一个明确的点，并且有一个结构化的演变成一个完整的产品。
未来交付的架构意图愿景
当今世界没有大前端设计 (BUFD) 的空间，这是一件好事。BUFD 在没有明确价值的情况下花费了数百万美元，而且通常，当（或如果）完成时，设计就已经过时了。
解决方案是开发架构意图Architecture Intent。
架构意图是全局的东西。
鉴于您的项目、客户、解决方案或企业的需求，处理所有“功能”的最终架构是什么？哪些可能的产品可以帮助实现目标？
从表面上看，这可能听起来像 BUFD，但你所做的是制定长期的架构愿景。并非所有细节都已充实。确定可能需要更多充实的架构上重要方面将取决于您的具体解决方案。
它只是为将来大的架构来设定方向。
除了少数（现在很少见的）政府 IT 项目外，没有人能够从一开始就实施完整的架构。
架构意图为整个架构设定了方向。然而，架构意图可以并且将会改变。
与所有敏捷或增量交付一样，需求也会发生变化。需求变化可以改变架构意图设定的方向。
此外，转型计划可能需要数年时间。当您交付架构意图的某些方面时，可能会使用与您开始时不同的技术。
即时当下的架构
已经确定了架构意图，那如何首先满足当下即时需求？
此外，鉴于开发团队目前的技术能力，需要缩减多少意图以避免交付风险？
再一次，架构就是权衡。这些是具有业务意义的权衡，而不是架构师孤立地做出的事情。
与架构意图不同，即时架构是具体的。针对需要发生的事情制定了精确的规范或政策。
即时架构到架构意图
毫不奇怪，从即时架构到架构意图的步骤构成了您的路线图并定义了产品或发布增量。
根据项目的敏捷程度，只有路线图中的后续步骤可能会得到很好的定义。目标是不要做太多的BUFD；当需求改变时浪费精力。
是不是在一开始时就没有基本架构的解决方案吗？
不是。作为架构师，您仍然需要确保所有必需的“功能”都在即时架构中。但是，可能会与客户就初始增量进行一些协商。
您可能还会发现最初的数据量和用户数量很少，因此可以采用分阶段的方法来支持可扩展性和并发性。