原创 冯英睿 2025-05-08 19:02 陕西
解决方案架构师会遇到的问题及其对策。
很多解决方案架构师的职业生涯起点都是从技术人员开始的，在刚刚从事解决方案设计时，都只是负责软件架构设计的部分。我自己在刚开始参与解决方案设计的时候，就有很多问题，可能大家也都有类似疑惑：
●什么是愿景？愿景和目标有什么不同？
●明明技术深度都有，为什么得到一个很虚的评价？
●解决方案不是显而易见的吗？怎么就有那么多人挑战？
●解决方案就是把已经做出来的成果包装包装，到底有什么意义？
●完全没有办法确定交付时间，怎么写的出来演进路线？
●…
可能还有很多问题无法都列举出来，但大家可能已经产生一些共鸣了。希望能通过这些分享，帮助大家减少“汇报一遍改一遍材料，看不到达成一致的希望”的痛苦。
关于解决方案，我理解的是：解决“问题”的方案，没有问题是不需要解决方案的。所以解决方案的关键是问题和应对措施，包括指导后续研发交付落地的计划。
很多朋友都知道这个道理，但就是难以提笔。这时候解决方案的结构就很重要，需要能够体现问题、措施、计划这些关键内容。做Web开发的朋友们大概都知道三层架构，今天分享一个常用的解决方案分层结构：
●目标设定
●问题分析
●整体方案
●技术方案
●实施计划
大致来说，上一层的产出就是下一层的输入。真实情况也存在相互影响，但反向的影响较小，往往是对上一层输入的一些调整。
思考：有些朋友可能会有点疑惑，为什么问题分析不是在目标设定之前？
1. 目标设定
目标设定是为了确定解决方案要达成的具体目标。目标应具体、可衡量、可落地，也可能有时效限制（目标的SMART原则[1]）。
1.1. 愿景不是目标
看到这里是不是有朋友能回忆起很多解决方案把愿景当目标的场景了。这有可能是领导听到朋友分享了某个厉害的概念，也可能确实是业务的痛点。但我们一定要清醒的认知到愿景和目标是不同的。
愿景是对未来理想状态的描述和期望，它描绘了长期目标的发展方向，具有前瞻性和指向性。但愿景之所以不是目标，是因为它代表了理想和现实的差距。
在目标设定的时候需要分析愿景吗？除了定方向的作用外，是否需要分析愿景还取决于：
●如果理想触手可及，愿景就是目标。
●如果理想离得不远，愿景就是用来争取预研经费的理由。
●如果理想遥不可及，愿景就是用来控制范围的工具，是用来把大家拉回现实的方法，愿景分析之后可以结合技术趋势和在行业的应用趋势，分析大致的可行性。
1.2. 目标分析工具
可落地的目标分析是这一部分的关键，可以从外因或内因的不同视角来分析，方法也有很多种：
●[趋势] 技术趋势分析：分析技术成熟度与目标可行性和投入产出，例如Gartner的炒作周期等[2][3]。
●[竞争] 竞争性目标设定：人有我无、同业对比，收集专业领域的各项指标和参数。
●[客户] 用户需求和趋势洞察：可以关注目标方向和紧迫性，例如一些行业报告。
●[客户] 用户旅程或应用场景分析：分析痛点、机会点、价值点。
●[自己] 价值链分析：分析效率、质量、收益，设定优化和改进目标。
●[自己] 根因分析：分析识别问题的潜在原因。
●[机会] 战略分析：如SWOT、波特五力、商业模式画布等，通过组织战略分析设定重点目标。
也可以理解为这类似于五看三定中的五看一定：看趋势、看客户市场、看竞争、看自己、看机会再加上定目标。总的来说，这些分析都是为了推导出一个合理的，但可落地的目标。
并不是所有人擅长分析的人都擅长以上这些分析，有些分析内容需要专业性的输入和判断。例如：同业指标、根因分析和技术趋势就需要行业专家或技术专家的输入。
另外，很多解决方案架构师会忽略启动解决方案设计的背景。例如：本来是为了解决规模化的问题，但是因为解决方案设计师对工程效率并不了解，本来应该用价值链分析找到改进点，却把重点放到了技术趋势分析上，追求创新而忽视了效率。
1.3. 目标总结
目标作为下一部分的输入，如何能够快速把目标清晰的讲出来其实非常关键。可能很多同学希望在将目标的时候把很多观点放到一起来介绍，但这反而增加了描述目标的难度！目标范围可以很详细，但目标的介绍应该是非常简洁的，至少包括价值点、差异点、行动号召等就是好的目标。
常用的工具有产品电梯演讲[4]，可以帮助我们在30秒内介绍完产品或解决方案的目标、价值和优势。
●为了：目标客户或用户；
●他们想：他们的痛点或期望；
●这个：产品或解决方案的名称；
●是一个：什么类型的产品或者定位；
●它可以：提供什么样的功能，也可以是提供或形成某种能力；
●不同于：差异化优势或者单纯它不是什么；
●它的优势或价值：不同于同类项目或竞争对手的独特价值。
以下是一个电梯演讲的例子[5]：
回到开头的问题，虽然解决方案是解决问题的方案，但要小心不要把问题当作目标！一来解决方案的目标设定并不完全是问题驱动的，再一个解决方案要解决可以解决的问题，所以下一部分是把可落地的目标转化成可以解决的问题。
注：分析无法解决的问题是用来澄清愿景和目标差距的，可用于设定范围，对指导设计帮助有限
二. 问题分析
把可落地的目标转化成可以被解决的问题，是这部分的重点。问题分析越彻底，解决方案的可行性、可信度就越高。这是因为问题分析有一个很关键的价值，那就是向不同的关键干系人传递信息：所有的问题我都考虑到了，如果这些问题都能被解决，那么我的解决方案就是合格的。如果问题分析不透彻，那么解决方案看起来就会比较虚。让人感觉你说的都对，但解决什么问题呢？
2.1. 问题分类
通常要解决的问题可分为：
●技术问题：当解决方案是以技术为核心的时候，需要重点打开分析技术上存在的问题，例如：智能问答系统、改进系统技术参数等。
●优化问题：随着业务开展，存在很多场景需要考虑资源和任务如何计划和分配的问题。此时需要进一步分析数据、算法存在的问题。
●流程问题：当要解决效率或体验的问题，往往从当前的流程或用户旅程开始分析，发现需要解决的问题。
●信息问题：当存在海量信息，但无法获得关键信息以辅助决策的时候，需要解决如何精准快捷的获取信息和情报的问题。
当然还存在很多不同类型的问题，但先对问题进行分类，有助于根据类型去寻找案例，进一步细化问题。
2.2. 解构问题
如果一个问题是一个系统性的问题，则问题解构的框架是非常重要的事情，同时也没有固定的方法。常见的问题解构的方法有：
●金字塔原理：逐层分析问题。
●MECE：一种系统性的问题分析和框架构建方法。
●用户旅程：一种分析流程和体验问题的有效。
●其他问题分析框架：行业中存在的各自问题分解框架。
如果要解决的问题是行业中广泛存在的，一般存在问题分解的框架。例如，数据平台的设计可以用数据工厂的概念来列举问题并对问题进行分类。
目标：构建一个数据平台帮助企业快速的加工高价值数据，为实现自服务的数据加工提供服务
框架：一家工厂包括原材料仓库、流水线厂房、实验室研发、办公室、营销、运行监控中心等部分，每个部分的人员和责任不同，可以对应到数据集成、数据流水线、数据治理、数据消费、系统监控等部分。是一种设计分系统的框架。
2.3. 问题与方案
问题分析是方案设计的关键输入，例如在DDD中有明确的提到的问题空间和解决方案空间这两个核心概念。问题空间能帮助各干系人形成清晰的全局视角，同时也能帮助解决方案设计师认识到解决方案和问题之间的关系。
问题（领域）与方案的映射[6]
DDD提出了“事件风暴”作为领域聚合的方法，但并没有明确说如何分析问题。如果按照事件风暴的分析方法来找到领域，可能并不适合分析一些智能化解决方案。这时也可以通过“发散再收敛”的方式对问题分组，主要目标还是要明确问题和方案之间的关系。
例如设计一个搜索引擎系统，这个系统的问题空间可以初步总结如下：
●数据的采集：如何及时获取关注的数据？
●数据的处理：如何灵活的处理数据？
●数据的存储：海量的数据如何被索引？
●信息的检索：如何准确的检索用户想要的信息？用户如何分析检索结果？
●情报的传递：用户如何订阅并及时的获取情报？
这个系统的解决方案空间就会包含：网页采集系统（采集）、实时数据处理流水线（处理）、批处理数据加工平台（处理）、大数据平台（存储）、搜索引擎集群（存储/检索）、信息检索服务（检索）、内容推荐引擎（传递）等多个解决方案，并和问题空间形成映射。
总的来说，能够更系统地识别问题，是判断解决方案的合理性的有力依据。
注：有朋友曾与我讨论这部分的问题是否就是需求，某种意义来说，分析出可实现的问题就是“目标”。但分析过程其实往往会经过几次迭代，期间有些问题会影响目标的设定，所以最后觉得还是问题分析更合适一些。而且本阶段注重分析过程和逻辑，需求其实是分析的结果，属于下一阶段的产出。
三、整体方案
可能很多朋友会问：为什么分为整体方案和技术方案？如果提到4+1视图，熟悉软件架构设计的朋友可能很快能理解，整体方案就好比是用例架构，描述用例和功能。没有用例，则余下的逻辑架构、运行架构、实现架构和部署架构是很可能存在偏差。
3.1. 用户旅程
所以此部分的实质是推导出谁是用户，他们的旅程和功能等要求是什么？产出给下游的内容主要包括：
●用户角色与用户旅程：是对未来用户使用流程的描述，描述用户为完成某项或多项任务的旅程。
●功能架构（或用户故事地图）：是对功能的描述，同时功能或用户故事需要能够映射到用户旅程，表明功能的必要性及完整性。
●交互设计（可选）：功能是交互设计的输入，而交互设计的目的是交付团队和各干系人对齐理解的重要产出物，就好比建筑设计需要看得到，把设计理念呈现出来才能确认所有人的理解是一致的。
●数据流（可选）：如果还依赖了外部数据，和用户旅程类似，应该描述数据加工的流程。所以应提出需要什么数据，产生什么数据，数据的格式和质量要求等。
●模型要求（可选）：如果需要AI能力，需要描述对AI能力的要求以及构建和改进AI能力的方法和流程，例如介绍相关的ML任务，通常AI能力的水平，需要做什么来持续改进等。
●合规要求（可选）：涉及到内外部标准、规范等合规要求应及早梳理，如果技术分析的时候没关注，可能会造成返工的后果。
为什么需要梳理数据和模型，可能这就是智能解决方案的不同吧！但本质上，都是在梳理用户、旅程、功能而已，只是智能解决方案交付的软件系统，是由软件、数据、模型三类交付件构成的。
部件 | 用户（角色） | 旅程（包括流程） | 能力或功能 |
软件 | 用户、运维、运营等 | 涉及的旅程或流程 | 所需的软件能力或功能 |
数据 | 数据所有者、管理者等 | 数据传输处理的流程 | 数据加工管理等能力或功能 |
模型 | 数据科学家、标注员等 | 模型开发优化的过程 | 模型训练优化等能力或功能 |
3.2. 功能分析
通过旅程或流程，对系统的能力和功能提出了具体的需求。为了和更多的干系人对齐理解，并进一步指导技术设计和交付计划的制定，一定需要详细的设计。在整体方案的详细设计的产出一般指：
●交互体验设计：因为很多干系人其实并不是软件领域专家，例如用户，要理解最终交付的产物是什么，还是需要类似建筑设计图才能直观的理解。而在企业内，用户往往就是出资方。
●用户故事地图：有了交互体验设计，业务分析师就可以基于此分析出需要开发的用户故事，而后技术团队就可以基于此评估所需的资源和人力，帮助制定实施计划。
交互体验设计就不举例分析了，用户故事地图是比功能列表更细的分解，每一张故事卡更聚焦于用户需求，可能是为实现某用户需求而需要的一个按钮。
用户故事地图举例[7]
3.3. 跨功能需求
当然除了功能，还需要更多的信息才能更好的描述业务的要求。一些非功能性或跨功能性的要求，都可以在这一部分明确的提出来。比如在一个智能问答系统中，用户等待的时间不能超过15s，用户等待第一个token的返回的时间不超过5s等要求。
注：如果是纯技术解决方案，不涉及用户、旅程、功能的变化，此部分可以介绍解决问题的原理方法。但其实很少有纯技术解决方案，假设范围仅是智能搜索或问答接口，仍然需要人员参与对基础数据进行管理。
3.4. 功能架构
整体方案是通过分析用户和旅程，推导出能力需求的过程，而交互设计和用户故事地图是对功能进一步的明确。最终我们可以将功能绘制成一张功能架构图，来向更多人呈现我们解决方案提供的各子产品或模块包含的功能。功能架构可以是一张思维导图，也可以是一张由不同模块组成的架构图。
通过思维导图描述的产品功能架构[8]
常见产品功能架构示意图[9]
功能架构是对这整个部分的总结，是否需要对功能架构进行梳理，主要取决于项目功能是否庞杂，它可以很好的帮助项目组成员快速认识产品或解决方案。它的另一个作用还可用于验证技术方案的完整性。不同功能点所需的技术方案不同，如果技术方案和功能点都能够映射起来，那么技术方案基本上也很全面了。
4. 技术方案
整体方案梳理的用户、旅程和功能，是技术设计工作的重要输入。如果从4+1视图来看，需要完成逻辑架构、运行架构、实现架构和部署架构，但如果不是实施过很多遍的成熟方案，是很难在方案设计阶段就产出翔实准确的实现架构和部署架构的。
于是，仍然要思考为什么要做技术方案设计？主要有两部分原因：
●对齐功能，进一步说明技术上的可行性；
●作为交付团队进行详细设计的输入，用于分析成本投入并制定实施计划（可能会新增很多技术卡）。
4.1. 架构设计的内容
所以并不是要按照4+1视图完成设计之后再进入交付，可以根据目的灵活处置，指导实施的技术方案包括：
●逻辑架构：描述各架构元素之间的逻辑关系。
●数据架构（可选）：描述数据模型设计，以及所需的技术。
●集成方案（可选）：是指导部署架构逐步完善的指导。
●运行架构（可选）：说明系统间集成或者内部关键技术组件运行过程等，作为技术方案可行性判断的补充说明。
●技术架构：推荐的技术栈选型，包括软件、数据、AI的各类技术栈。
●部署架构（可选）：说明技术方案在成本、可用性、可扩展性、网络安全等方面的设计。
●持续集成（可选）：构建、测试、发布、运维的过程设计和技术选型。
4.2. 架构设计的思路
架构和技术选型可以参考行业内最佳实践如：
●单体架构：如果系统的标准化程度很高，单体架构其实也是合理的选择。
●面向服务的架构：采用SOA或微服务架构设计思路。
●事件驱动的架构：以及基于Event Sourcing & CQRS设计的微服务架构。
●Severless架构：适合专注业务功能的快速迭代的轻量级应用系统的架构。
●数据仓库架构：数仓设计的贴源层、数仓层、集市层。
●数据中台架构：One Data、One Service、One ID。
●其他数据架构：Data Mesh、Data Fabric。
●AI模型或算法：可以根据实验结果或行业横向测评结果进行选型。
架构设计思路可能仅供参考，而不是方案设计的主要内容。但只有结果而没有技术方案建模的 过程，不足以体现出设计的合理性，可参考常见的设计方法：
●DDD：应用事件风暴、四色建模等工具完成领域建模，输出更为合理的解决方案。
●数据建模：可参考Inmon和Kimball的数据建模范式，Inmon还在大数据技术应用阶段提出了Data Vault数据建模方法等。
●安全设计分析：纵深防御、华为八维度设计方法、威胁建模等设计方法。
●持续交付：可参考业界DevOps、DataOps、MLOps来指导设计。
虽然有很多实践和方法可以指导我们开展技术设计，但需要经常自省的是，技术部分的设计最终还是为了分析可行性、指导交付团队并制定实施计划。完全可以迭代完善设计，灵活控制设计投入。
注：注意遵从企业和组织要求的IaaS、PaaS、SaaS等高阶的分层设计原则和技术管理要求。过程中可能需要和团队或企业的总架构师对齐整体规划。
五、实施计划
这一部分的目标就是制定清晰的计划。但有了功能和技术方案，就可以评估交付计划了吗？理想很美好，现实往往存在各种各样的问题，导致很难制定一个清晰的可执行的计划。即便已经进入实施阶段，有些解决方案仍然是基于某些关键假设来设计的。
5.1. 风险/假设/问题/依赖
在开始做计划之前，可以先了解一下这个项目管理工具，将已知的风险、假设、问题和依赖都写下来。
●风险：可能对达成目标产生负面影响的事情。
●假设：没有确定，但假设为真的，对项目目标会产生影响的条件或事情。
●问题：正在对达成目标产生负面影响的事情。
●依赖：达成目标所依赖的外部因素或条件。
在完善方案输出时，不同类型的具体事项，可以采取不同的应对措施，并不断的更新状态。例如：
类型 | 事项 | 影响 | 跟进措施 | 状态 |
风险 | 算力可能不够 | 高 | 询问新的供应商 | 跟进中 |
假设 | XX数据已经存在 | 中 | 明确假设是否成立 | 已确认 |
问题 | 响应时间要求苛刻 | 高 | 解释协商中 | 跟进中 |
依赖 | 外部XX查询服务 | 中 | 明确依赖服务交付时间 | 跟进中 |
存在问题其实不用担心，问题不透明才是最要命的，通过提高透明度，能更好的促进协作，提高效率。
5.2. 路线图
回到开头提出的问题：“完全没有办法确定交付时间，怎么写的出来演进路线？”
现实中是一定会存在风险和问题的。在制定演进路线时候，可以先划定阶段或关键里程碑，而不是直接设定时间。确定里程碑没有固定的方法，这需要结合具体的情况分析。主要来说还是对关键子任务的分解，以及子任务之间的依赖关系的梳理。
当然并不是说路线图一定就没有时间了，只能说时间估算是一个逐步清晰的过程。需要足够清晰的任务分解和依赖关系分析，以及对任务复杂度和工作量的评估，才能最终得到准确的实施计划。
如果马上就要开始交付了，那么就需要评估工作量。这时候，有很多团队通过故事卡估点的方式来评估所需的资源并制定发布计划。
六、方案发展的阶段
要达成的愿景可能真是“一张蓝图绘到底”，但不可能撸起袖子一直干一样的事情！
如果是由技术驱动的创新性项目，它的发展一般会经历几个阶段：
●概念验证：在概念验证阶段，方案主要关注可行性的验证，不需要过多的关注体验，功能点也非常的简单，因为可能都没有真实的用户。运维运营管理基本上很少考虑。因为可行性都还没有被验证，过渡设计就是浪费。
●价值验证：为了验证解决方案的业务价值，需要真实的用户参与。这时也需要考虑体验问题和系统集成等问题。解决方案内容就必须要包含旅程（流程）、功能等，而且因为真实用户使用过程的行为数据也需要考虑收集，运营相关的功能也需考虑是否包含。
●持续运营：当价值被验证之后，为了推动到更大的范围，需要考虑支撑规模化所需的能力，再规划相应的工具或平台的开发计划。这时需要分析提供某种服务的价值链，寻找优化运营的机会点，强调怎么把服务做好，成本控制好。因此运营推广和协作的功能就是这一阶段设计的重点。
另外需要注意的是高阶方案和详细设计是不同的，并非所有以上讨论的内容都需要在高阶解决方案中完成，例如交互设计一般就不需要在高阶解决方案中编写。下表是一些内容的分类，可供参考：
内容分段 具体内容 高阶方案 详细设计 概念验证 价值验证 持续演进 价值验证 持续演进 整体方案 用户旅程 ✅ ✅ ✅ ✅ ✅ 功能架构 可选 可选 可选 可选 ✅ 交互设计 可选 可选 ⛔ 可选 ✅ 用户故事地图 可选 可选 ⛔ 可选 ✅ 技术方案 逻辑架构 ✅ ✅ ✅ ✅ ✅ 集成架构 可选 ✅ 可选 ✅ ✅ 关键技术验证 ✅ 可选 可选 可选 ⛔ 部署架构 可选 ⛔ ⛔ ✅ ✅ 实施计划 演进方向 ✅ ✅ ✅ ✅ ✅ 时间节点 可选 可选 可选 ✅ ✅ 交付计划 可选 ⛔ ⛔ ✅ ✅ 以上就是所有和方案内容有关的分享了，希望能够对大家有所启发。
参考
如何做好目标管理？SMART目标法5个原则帮助你！
Gartner 2024 Hype Cycle for Emerging Technologies
科技棱镜：助力企业管理者领航未来
如何用“电梯演讲”表述你的产品愿景？
电梯演讲-CSDN博客
Domain, Subdomain, and Bounded Context - Zaf1ro
用“用户故事地图”高效进行需求组织和迭代规划
产品结构图=功能结构图+信息结构图
架构设计实践五部曲（二）：业务架构与产品架构设计实践_架构_胡斌
敏捷开发中的故事点是什么？您将如何估算它们？ | Atlassian
