1.1　什么是解决方案架构

如果你向周围的人询问他们对于解决方案架构的定义，可能会得到十几个不同的答案，而且这些答案可能都是正确的，因为这些人所处的组织结构不同。每个组织都会根据其业务需求、组织层次和解决方案的复杂程度，从不同的视角来看待解决方案架构。

简而言之，解决方案架构从战略和战术的视角，对业务解决方案的方方面面进行定义和展望。解决方案架构不仅仅是软件解决方案，它涵盖了系统的方方面面，包括但不限于系统基础设施、网络、安全、合规性要求、系统运维、成本和可靠性。图1-1展示了解决方案架构师可以解决的不同方面的问题。

图1-1　解决方案架构环形图

从图1-1可以看出，一位好的解决方案架构师可以解决组织中关于解决方案最常见的问题：

□全球分布式团队：在这个全球化的时代，几乎每个产品都会有分布在全球各地的用户，以及负责满足客户需求的利益相关者团队。通常，软件开发团队会采用在岸-离岸模式，该模式下团队跨时区工作，以提高工作效率并优化项目成本。解决方案设计需要考虑全球分布式团队结构。

□全球合规性要求：当在全球范围内部署解决方案时，每个国家和地区都有其法律和合规制度，这些都是解决方案需要遵守的。以下是一些示例：

●美国的联邦风险与授权管理计划（Federal Risk and Authorization Management Program，FedRAMP）和国防部云计算安全需求指南（Department of Defense Cloud Computing Security Requirements Guide，DoD SRG）。

●欧洲的通用数据保护条例（General Data Protection Regulation，GDPR）。

●澳大利亚的信息安全注册评估师计划（Information Security Registered Assessors Program，IRAP）。

●日本的金融业信息系统中心（Center for Financial Industry Information Systems，FISC）。

●新加坡的多层云安全（Multi-Tier Cloud Security，MTCS）标准。

●英国的G-Cloud。

●德国的IT-Grundschutz。

●中国的网络安全等级保护制度（Multi-Level Protection Scheme，MLPS）3.0。

此外，不同行业的合规性要求也不一样，例如国际标准化组织（ISO）9001（主要针对医疗、生命科学、医疗器械以及汽车和航空航天行业）、针对金融行业的支付卡行业数据安全标准（Payment Card Industry Data Security Standard，PCI-DSS）、针对医疗行业的健康保险携带和责任法案（Health Insurance Portability and Accountability Act，HIPPA）等。解决方案架构在设计阶段就需要考虑这些合规性（更多关于合规性的内容见第8章）。

□成本和预算：解决方案架构能够很好地估计项目的总成本，这有助于确定预算。预算包括资本支出（CapEx），即前期成本，以及运维支出（OpEx），即持续成本。它有助于管理层为人力资源、基础设施资源以及其他与许可相关的成本制订整体预算。

□解决方案实施组件：解决方案架构预先提供了产品不同实施组件的高层次概述，这有助于计划执行过程。

□业务需求：解决方案架构考虑了所有的业务需求，包括功能性需求和非功能性需求。它确保业务需求是兼容的，因此可以将它们转化到技术实施阶段，并在利益相关者之间取得平衡。

□IT基础设施需求：解决方案架构决定了项目执行需要的IT基础设施，包括用于计算、存储、网络等的基础设施。这有助于有效规划IT资源。

□技术选型：在解决方案设计过程中，解决方案架构师会进行概念验证和原型开发，考虑企业需求，然后推荐合适的实施技术和工具。解决方案架构的目标是进行内部自建或者向第三方采购工具，并定义整个组织的软件标准。

□终端用户需求：解决方案架构特别关注终端用户的需求，因为他们将是产品的实际消费者。这有助于发现因产品经理缺乏技术细节而无法捕获的隐藏需求。在实施和发布的过程中，解决方案架构师会提供标准文档和典型的语言结构，以确保所有的要求都已满足用户的需求。

□解决方案维护：解决方案架构不仅涉及解决方案的设计与实施，还需要负责上线后的活动，例如解决方案的可伸缩性、灾难恢复、卓越运维等。

□项目时间表：解决方案架构设计根据每个组件的复杂性布局其细节，通过提供资源估算和相关风险信息，进一步帮助确定项目里程碑和时间表。

行业标准和明确定义的解决方案架构可以在技术解决方案中解决所有业务需求，并确保交付预期的结果，以满足利益相关者对解决方案的质量、可用性、可维护性和可伸缩性的期望。

解决方案架构的初始设计可以在售前环节的早期进行构思，比如需求建议书（Request For Proposal，RFP）或信息请求（Request For Information，RFI），然后再创建原型或进行概念验证，以发现解决方案存在的任何风险。解决方案架构师还需要确定是构建解决方案还是采购解决方案。这有助于确定技术选型，同时也要牢记组织内关键的安全性和合规性要求。

创建解决方案架构的两种主要情况如下：

□第一种情况是，增强现有应用程序的技术，可能包括硬件更新或软件重构。

□第二种情况是，从头创建一个新的解决方案，这样可以更加灵活地选择最适合的技术来满足业务需求。

然而，在重构现有解决方案时，还需要考虑最小化影响范围，创建最适合当前环境的解决方案。如果现有解决方案不值得重构，解决方案架构师可以决定重建以提供更好的解决方案。

简而言之，解决方案架构就是要考虑系统的方方面面，勾画出技术愿景，从而提供实现业务需求的步骤。通过将所有与数据、基础设施、网络和软件应用程序相关的不同部分整合在一起，解决方案架构可以为复杂环境中的一个或一组项目定义实施方案。一个好的解决方案架构不仅要满足功能性和非功能性需求，还要能解决系统的可伸缩性和长期维护问题。

我们刚刚概述了解决方案架构及其不同方面的内容。下一节将探讨解决方案架构的发展历程。