持续的架构提供了灵活性，以适应新的业务要求和用户需求
在工程团队开始开发应用程序和系统之前，软件架构和系统的冗长设计阶段曾经是一个必要的步骤。架构师将审查高层次的需求，考虑企业标准，并在软件开发过程中使用的平台、设计模式和组件上绘制架构图。
如果需要新的技术或软件组件，一些组织会进一步进行架构规划。他们建立了架构审查委员会，以提供决策的透明度，强调架构风险，调整预算，并检查其他影响可持续发展实践的因素。也有人质疑架构审查委员会的有效性，因为它们阻碍了自主性，扰乱了开发流程，并可能导致过多的文件。
敏捷开发团队寻求自主权和授权，以应对变化，而不是遵循规定的计划；这是《敏捷软件开发宣言》的关键价值之一。但是，技术领导者寻求可重复使用的平台、开发标准和可持续的运营模式，以提高效率、质量和可靠性，同时减少技术债务。
平衡可以通过持续架构原则来实现。持续架构宣言支持 "从以前的瀑布式方法，即架构主要在功能实现之前完成，转向持续的跑道"。原则包括架构 "长期产品，而不仅仅是项目解决方案"，以及 "通过实施验证架构"。他们的原则适合于开发云架构的团队，利用devops最佳实践，并使用概念验证和敏捷峰值来验证他们的解决方案。
我联系了Continuous Architecture的软件架构师Pierre Pureur，以获得他对宣言和实践的见解。他说："持续架构方法为在敏捷、devops和云时代创建和维护可持续的软件架构提供了一条行之有效的途径。它强调了基本活动的重要性，包括关注质量属性要求，推动架构决策，了解你的技术债务，以及实施反馈循环"。
自动创建开发和测试环境
持续架构的第一个起点可能是基本的开发实践，如自动化基础设施即代码（IaC）来启动开发和测试环境。自动化有助于锁定架构师所追求的标准配置和模式，并提供开发团队所需的敏捷性。
Quali公司产品管理副总裁Amir Rozenberg表示同意，他说："提供应用程序的组织依赖于并应该能够方便地获得可靠的、现成的、符合要求的环境，以支持他们的持续软件交付管道。"
Rozenberg建议，架构师与开发团队合作，创建云基础设施蓝图。他说："Devops团队应该建立环境蓝图模型，以自助服务的方式为他们的业务成员，如开发团队、产品经理、测试人员和售前提供适当的云基础设施，以消除漫长的等待时间。"
Buildkite的创始人兼联合首席执行官Tim Lucas表示赞同。"他说："一个持续的架构，无论是技术还是文化，都需要开发团队和企业的承诺。他建议的一个关键原则是 "创建一个专门的角色，专注于开发人员的经验并对其负责"。你可以通过让开发团队更容易地自我服务于开发和测试其代码所需的环境和部署管道来解决开发者体验问题。
在定义生产架构时考虑客户和用户需求
虽然devops团队通过自动化来寻求生产力，但业务领导人，包括产品经理、数据科学家和合规官员，也在生产环境中寻求架构的灵活性。这通常意味着根据用户需求扩大和缩小生产环境。有时，这意味着要根据合规性要求旋转出多个环境。
Lucas为生产环境补充了一个关键的设计原则，并建议 "投资于减少故障，因为要使某件事情连续，需要减少中断。"
对于数据科学家来说，集成和部署往往有不同于软件开发团队常见的要求。KNIME的联合创始人兼首席执行官Michael Berthold说："在整合过程中建立的数据科学生产流程与数据科学团队创建的不同，生产中的监测可能导致自动更新和重新部署"。
用量和基础设施监测可以触发环境的扩大和缩小，但模型ops监测也可能触发配置变化或重新部署。Berthold说，对于数据科学和机器学习管道，"部署周期可能由监测过程自动触发，在生产中检查数据科学过程，只有严重的变化才会迫使整个过程重新启动。"
架构必须专注于未来的可能性
企业领导人往往关注近期的机会，而devops团队则尽最大努力开发模块化和可扩展的软件组件。一些支持持续架构的最佳实践包括：
- 使用云原生和无服务器架构进行开发
- 标准化部署管线
- 支持持续测试实践
- 构建微服务并支持API生命周期
- 利用平台简化的低代码解决方案，并帮助避免定制解决方案
Axway执行副总裁兼首席创新和技术官Vince Padua专注于开放架构，他说："企业对企业的整合和协作将加速其建立在API和云计算基础上的数字化转型。因为云原生和API优先的方法已经成熟到一个开放的一切架构，通过伙伴关系和协作进行创新的时间和成本已经大大降低"。
许多企业现在正投资于客户体验、集成和数字化工作流程的定制软件，必须考虑最佳实践，以保证他们的投资符合未来的需要。帕多瓦建议："随着企业表面区域以API为中心，通过跨行业和垂直领域的产品和供应链的松绑和重新捆绑，更多的创新被解锁。在旅游、物流、仓储、制造、借贷、保险和精品零售的B-to-B产品中，有大量的投资和启动增长机会"。
践行持续架构需要平衡今天的业务需求和devops团队需要的生产力，同时还要对组织如何支持未来的变化、扩展和新需求有一个愿景。部分认识是，从事今天的实施工作的团队很可能会随着时间的推移而改变，因此架构师寻求易于学习的积木式解决方案，允许新的团队成员毫无顾虑地进行代码修改，并有足够的测试覆盖率来验证变化。持续架构认识到使用可重复使用的模式进行开发的必要性，但也承认，鉴于业务需求的变化和技术的发展速度，创建一个完美的蓝图是不现实的。