「方案架构」解决方案架构生命周期

最近，我在Linkedin上发布了一张关于解决方案架构生命周期的工作进展图片——浏览量超过1000次，我想我会在博客上发布一张更详细的图片，并附上一些非常简短的注释。

如前所述，解决方案架构师负责与计划和项目合作，以确保问题解决方案的设计、成本计算、采购、构建和交付给组织，这通常会导致交付新的过程结果和IT能力。

解决方案架构师处理从简单到复杂的各种问题，因此需要广泛的技能（技术/业务）。

解决方案架构师的工作可以分为不同的阶段，并分为以下几个方面：

解决方案架构生命周期

下面简要讨论解决方案架构师生命周期的每一层。但是，必须注意的是，每一层的焦点将与顶层对齐，即问题/问题。

识别

通常，一个问题需要一个工作组来确定某件事是否值得考虑，例如对一个项目的投标，或讨论技术领域正在出现的一种“模式”，这种模式需要报告系统进行调查，例如容量和性能/安全事故。

解决方案架构师通常在这个阶段提供解决问题的可能选项的建议，并帮助触发活动的下一个阶段。

定义问题/问题的上下文

没有一个商业案例，即一份记录了启动一个项目或任务的理由并记录了基本成本和结果的文件，任何项目或工作计划都不会真正开始。如果问题是一个技术问题，那么解决方案架构师需要从系统的角度（用简单的术语）详细说明问题的上下文。

捕获需求

在需求捕获阶段，解决方案架构师将花费大量时间关注需求的系统元素，并试图理解系统组件特性。

在这一阶段，将有一个偏向于非功能要素的系统。

在这一阶段，可以从利益相关者那里获得一个最低可行的产品，也就是说，交付功能性和非功能性需求所需的最低组件和努力可以被勾画出来，以定义进一步的成本分析。

必须注意的是，这些要求还必须包含任何法律合规性问题，例如GDPR要求和任何企业架构指令。

定义产品Backlog和/或0级系统架构

一旦问题被知道、记录并分解为一组明确定义的功能性和非功能性需求，就可以生成一个0级系统架构（architecture）来概述解决方案。

在可能的情况下，应强调可重用组件，以缩短上市时间并增加项目的节约。

在这个阶段，结果应该是0级设计，在许多情况下，会导致解决方案的产品积压

0级设计将有助于项目确定交付所需成果所需的成本和努力。

设计解决方案并将可交付成果分解为sprint

在这一阶段，将对0级进行详细的分析，并对其进行进一步的阐述，以交付详细的设计文档和随后交付项目的技术冲刺。

根据解决方案的不同，可能需要谨慎地生成低级设计来支持解决方案设计。

实现解决方案和实施方案的选择

我之前已经讨论过可供分析的选项，从“不做”到“构建”，但从成本/执行能力的角度来看，应选择利用现有关系/服务和最佳性价比的选项。

将解决方案交付到生产中

开发、获取或修改系统需要部署到生产环境中，因此解决方案架构师必须能够为生存路径定义环境（测试、生产、预生产）。通常，这将涉及到与服务架构师一起设计服务和系统的操作元素（通常从NFR推断）。

如果我们把上面的所有元素都取出来，并分配解决方案架构师参与项目的时间，那么我们可以生成一个类似下面的图；

总而言之，解决方案架构师是一个重要的角色，需要随着每次参与而发展的技能，并且可以发挥从问题实现到交付到解决方案服务的作用。