作为一名架构师，你可以期望，在你职业生涯的某个时刻，参与一个关键的前线，动荡的项目或计划。在这种情况下，你需要依靠在信息和通信技术领域工作几年所获得的技术、政治和社会技能。

今天的博客（在伦敦考文垂火车上准备）提醒我们，在处理复杂的项目时，一般的解决方案架构师必须考虑一些“基础知识”。这些“以系统为导向”的考虑因素在项目参与要素中始终处于前列，需要在系统构建/交付的分析、设计和构建阶段进行考虑，同时保持结果的视线。

与生活中的大多数事情一样，列出的列表显然取决于您所操作的领域，例如，如果您正在研究制造执行系统（MES）解决方案，那么您在项目中的主要关注点将是实时监控和数据采集系统和过程。但是，如果您正在开发零售银行应用程序，那么您的重点将偏向于法规遵从性和报告。

所列清单并非详尽无遗，仅作一般性说明。然而，如果我们研究大多数信息和通信技术项目，我们通常会发现一种共同的模式，即收集原始数据，将其转换为信息，然后允许数字流程消费和生成报告，从而允许企业执行一项为组织增值的活动或行动。

这一运动如下图所示，思维泡泡代表了下表中进一步列出的思维区域；

项目期间的日常解决方案架构重点

数字化数据

信息

流程执行和编排

报表

讨论：请加入知识星球【首席架构师圈】或者微信小号【ca_cea】

定义解决方案架构

多年来，我一直致力于设计和创建基于软件的解决方案，我亲眼目睹了解决方案架构师需要不断学习和适应用于提供解决方案的架构设计模式，技术和方法的演变。

对于业务利益相关者而言，解决方案体系结构是一个抽象的，难以理解的概念，如果没有它，提供给业务的解决方案在需要进行未来更改时不太可能满足他们的期望。

在没有设计架构的情况下提供的解决方案仍然可以产生具有底层架构的解但是，由此产生的架构将是一个“意外”的交付结果，而不是一个旨在满足即时和预期未来能力的架构。

每个组织，技术团队和项目通常对解决方案架构师角色有不同的定义和期望，并且已经有尽可能多的尝试来简洁地定义解决方案架构。

解决方案架构的通用定义包括：

1. 定义系统的整体结构，解决方案组件及其职责和关系
2. 定义解决方案方面，这些方面将在以后更改并且成本高昂
3. 定义解决方案组件应遵循的原则和关键约束

协作架构

解决方案架构师需要考虑超出短期的观点，并了解解决方案需要适应和发展到未来的需求。构建解决方案体系结构是一项团队工作，架构师需要将不同的交付和技术团队聚集在一起，以帮助定义解决方案体系结构。做得好这需要架构师成为解决方案交付中涉及的许多角色的编排者，是“了解”目标解决方案的人，以便他们可以指导业务和技术角色之间的解决方案决策。

为了提供良好的解决方案，架构师需要具备均衡的技能组合，包括：技术，行业知识，沟通，利益相关者管理，领导力，解决问题，决策和谈判技巧。

对我而言，这突出了架构师能够促进他们所处理的团队和利益相关者之间的协作的重要性。 “协作，沟通和清晰”的口号应该是架构方法的一部分。

有效解决方案架构的品质

就像角色本身一样，衡量“良好建筑”的因素也各不相同。解决方案可以通过数百种不同的方式进行设计和组装。在此过程中做出的重要解决方案决策将改变最终的解决方案特征和变更能力。

我相信一个好的解决方案架构的关键方面是它：

1. 提供高效且经济的设计
2. 支持一种设计模型，可以提供体系结构依赖性的可见性并支持解决方案变更影响分析
3. 提供一个易于理解和明确表达的基础，定义解决方案模式，原则和约束，为架构的治理提供信息，以满足未来的需求。

解决方案技术的快速变化使我们从单一服务器单片应用程序转变为当今云商品化解决方案服务，组件和容器化部署框架的集合，这些框架支持创建复杂的分布式解决方案。

优秀的架构师将利用其他人的经验教训，并在适用的情况下应用经过验证的参考架构设计和模式。毕竟，在提供当今复杂的解决方案的同时更快，更经济地提供商业价值，就是在存在明确定义且经过验证的解决方案设计模式时，避免（重新发明轮子）需要（或希望）。

随着技术的发展，我们的解决方案也在不断发展。技术方面的变化几乎与方法一样多，例如

SDLC，瀑布，OOMD，RUP，RAD，SOA，敏捷，精益，Scrum，SAFe等。每种方法都采用不同的方法来解决项目中解决方案架构的交付方式。

早期的敏捷采用正确地看到了解决方案架构师在开发之前制作大型端到端解决方案架构文档的大量前沿工作，这是浪费。不幸的是，人们倾向于将任何解决方案架构活动视为浪费。

最终的解决方案可能会在第一天的功能框中打勾，但对架构的真正评估只有在生产之后才会出现，并且不得不响应功能，规模或弹性的变化。

什么可以用来取得成功

通过以下方式帮助制作成功的解决方案架构：

• 经过试验和测试的架构模式，参考架构和框架
• 云平台服务可减少构建分布式，可扩展和弹性系统的工作量

               云平台还使架构师​​能够将“模拟”架构部署到一次性非生产云环境中，从而为不同的架构设计进行原型设计。

• SAFe等方法可识别解决方案架构思维和设计，而不会影响交付灵活性。
• 架构设计工具，用于对设计进行建模，并基于该模型提供解决方案的架构视图，为不同的利益相关方群体提供解决方案视图，并为未来的设计变更启用影响评估。

             在考虑未来的设计变更影响时，架构模型经常被忽视，是一个关键的可交付成果。架构模型比静态设计图提供了更多的价值。

成功交付当今复杂的分布式解决方案比以往任何时候都需要架构思考和设计。架构师专注于定义整体解决方案结构，组件职责，并为那些难以改变设计核心方面的人做出设计决策。

结论

成功的架构提供了第一天的解决方案成果，同时能够经济地发展解决方案以提供第二天的成果。我们采用的解决方案架构的方法和方法需要随着底层技术的发展和变化而适应和发展。

较短的开发时间框架将目标架构视野从5年缩短至1年至X个月，成功的敏捷和DevOps方法使解决方案几乎不断变化和发展。这也意味着我们可以评估并应用来自生产解决方案的洞察力，以进入下一代架构开发。

德勤平台工程师知道如何构建不断变化的业务环境所需的复杂解决方案。我们的经验源于技能，学科和方法，利用现代流程工程，集成，云服务，DevOps以及测试和优化规程，这些规范已被证明可以在不断变化的复杂业务和IT环境中为第一天及以后提供成功的解决方案体系结构。

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

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

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

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

解决方案架构生命周期

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

识别

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

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

定义问题/问题的上下文

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

捕获需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

将解决方案交付到生产中

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

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

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

原文：https://dalbanger.wordpress.com/2017/05/07/the-solution-architecture-life-cycle/

本文：http://jiagoushi.pro/node/1043

讨论：请加入知识星球【首席架构师圈】或者小号【intelligenttimes】