我目前工作的团队，主要在大健康和人类服务领域为现有的SaaS应用程序提供更新。在工作时，我们需要支持现有的客户/用例，扩展支持的用例，演进架构以对其进行支持，并发展支持托管应用程序的PaaS不断变化的景观，例如我们正在使用的IBM Cloud。

在我们的方法中，我们践行了许多开放敏捷架构实践。在这里，我将专注于持续的架构重构，特别是规划、理解和指导架构。随着我们解决方案的发展，我们需要平衡改善客户功能/功能的动力，跟上PaaS的演变，并保持/改进我们解决方案的非功能特性。

在规划方面，关键是要对架构的演变有一个“愿景”，这不是一成不变的东西，而是根据您当前的知识对架构应该的走向进行最佳预估。随着外部因素的变化，您的架构很可能受其影响并产生变化。然而，尽管“愿景”具有波动性，但它仍然是指导架构演变的核心工具，因为它是评估拟议架构变化的参考点，以确定它们是否正在将整个架构推向您的目标。

在我的团队中，这种“愿景”往往是一个清单，列出了我们认为最终需要进行更改的一系列架构变更。对我们来说，这个价值的一个关键要素是，它使我们能够快速看到拟议的变更与此列表的交叉点——这可以为我们的决策提供信息。有时，这会导致我们改变“愿景”，事实上，有时我们允许改变，使我们远离“愿景”——但每次决策都是明智的决定。

在许多方面，“愿景”也是理解和指导架构的关键制约因素，但还有其他限制。对于我的团队来说，托管和运营成本始终是一个非常重要的考虑因素——简而言之，如果我们的解决方案没有盈利，我们就不会长期经营！对我们来说，另一个关键制约因素是合规性，如我们的产品在严格监管的地区，那么架构变化经常会受到限制。诸如以下问题通常主导着我们的思维：“我们想要获取的服务是否具有合规版本？”、“我们的整体解决方案能否继续满足这一变化的合规标准？”。

其他我想涵盖的关于理解和指导架构的关键方面是我们给开发人员/团队的支持，以帮助他们在设计和实施更改时保持在架构的总体约束范围内。其中一些是“适应度函数”（Fitness Functions），是对架构特征的可执行性验证，有些是“护栏”（Guardrails）特征的书面陈述。其中一个持续的压力是试图找到方法，尽可能多地将特征编码为 "适应度函数（Fitness Functions）"--以减少开发者和团队在过程中不得不主动思考的多样事务。