「来源:｜泡杯茶看金融ID：FinancialTea」
这是我前一段时间帮公司面试解决方案架构师时的感慨。跟几位10+年经验的技术软件架构师面试下来,感觉技术能力都很过关,尤其是对新技术,能从架构师的角度思考问题,对架构设计有成体系的理解与输出。
但是,当我在围绕着一些比较宏观灵活的解决方案架构方法与思维上的问题时,比如:
跨领域发展的解决方案架构设计方法与模型从模糊的商业问题或抽象的业务愿景落到解决方案的方式如何治理解决方案架构设计,从抽象到具体的思路我发现,多数人停留在“技术架构,或软件架构的层面。少有能做到“开放性思维”,能从商业问题的本身出发,带领团队让“理真的越辩越明”。
为什么会这样?原因在哪里?
结合自己从工程师到企业架构师的经历,主要的原因是:构架师在解决跨领域复杂问题是的方法真的不多。这主要是因为大多数的架构师都是技术出身,他们解决问题的思维与方法主要来自之前技术领域的积累。
大多数架构师的思维模式是”专家模式“.这种思维模式是习惯于把已熟悉的解决方案(比如:微服务等)对接商业问题.。这种单一视角就类似查理·芒格说的:手里拿着锤子的人,眼中满世界都是钉子。
本文旨在探讨解决方案架构设计过程的方法,原则与逻辑思想以及我将分享根据过去的经验提炼出的一套解决方案架构的方法。
该方法曾在我工作过的世界强公司,国际4大咨询公司,以及政府部门,银行,电信,航空,金融等行业中使用。所以,无论你已经是架构师,还是目标成为一位优秀的架构师,这篇文章都与你有关。
让我们先了解什么是解决方案架构以及从我踩过的”坑“开始。
什么是解决方案架构设计?
解决方案架构设计是使用解决方案架构师的丰富的知识与经验,从纷乱复杂的问题中,应用科学的解决方案分析方法,进行定量和确有论据的定性分析,找出企业要解决问题的核心原因,提炼能被实施的解决方案与设计架构,进而指导方案实施的过程。
需要解决方案架构师解决的问题,大多数都是是由现状和期望的差异产生的,如下图:
有人会疑惑:我拿到需求后进行确认,再进行分析设计,输出框架方案。我也不需要设计解决方案架构啊?当然。不是所有的问题和项目都需要解决方案架构设计。
在分析处理问题时,解决方案架构师会从两方面思考问题:
我要解决的是什么类型的问题?
在不同的问题类型中,由于问题本身具备不一样的复杂度,认知问题和解决问题的方式也是不同的。
一般来说,解决方案架构师会把问题分成4类:
Cynefin框架-IBM在21世纪初开发
对于简单(Simple)问题,一般是可预测的、可能已经有最佳实践方案,或者你已经解决过类似的问题。问题和解决方案相对稳定;有已知的解决方案。例如有已知框架模型,可复用的方法和步骤,流程,组件。
这类问题不需要解决方案架构设计。比如,给产品需要添加新功能模块。
对于繁杂类型(Complicated)的问题,一般是可预测性大于不可预测性,可能有多种可能的解决方案,但是无法确定哪一个解决方案是最佳实践。这类问题你知道存在哪些未知问题域,你需要用系统的分析过程把因果关系整理清楚,再诊断和找出适合的解决方案架构。这类问题一般是需要解决方案架构分析的。
当然,问题本身不是非常繁杂,可以进行“轻”解决方案架构设计,或者直接进入系统设计。
对于复杂问题(Complex),我们需要通过建立一系列的假设,在多个备选方案中反复对比验证,从反馈中筛选出最符合实际情况的方案架构。再把复杂问题切割成若干个简单或轻度繁杂的问题进行详细架构设计。这个过程可能长达几个月或更长。
因为对于未知的问题,方案架构分析过程就是一个学习的过程。下面是一个对复杂问题认知的模型:
在方案架构设计初期,架构师通过分析,验证,反馈学习逐步更加认真范围,最终完成架构工作。但反之,如果框架师判断错了问题的类型,使用错误的方法,就可能会输出与问题不匹配的方案架构。
对于混沌问题,无法通过解决方案架构设计过程找到答案。这类问题只能选择解决问题的一部分,或者为问题专门设计套创新的方法。
我之前航空公司就曾经被公司要求解决过这类型的问题:如何把业务,数据和功能从一个已经跑了60多年的航空系统(Astral-是爱尔兰第一个IT系统,年上线,目前还在使用中)迁移出来的方案。
年,IBMAstral系统在AerLingusIT系统部
解决方案架构与问题是否匹配?
通常在一个解决方案架构设计过程中,架构师需要在4个层面和阶段思考架构是否匹配,如下图
1问题与愿景需求匹配
在开始阶段,架构师需要清晰的定义问题,确保问题与愿景,需求,期望相匹配。这里还包括确定问题的类型,复杂程度等。
2解决方案架构与问题匹配
在方案概念架构设计阶段,在多个假设或备选解决方案中,哪些是与问题相匹配。这里概念架构不需要包含太多的技术细节。概念架构应该做到对业务方人员,非技术背景人员友善易懂。这样我能确保最大程度的获得不同部门人员的参与与反馈。
这里架构师一般从2个基本维度去考虑问题与解决方案的匹配:
问题的复杂度与解决方案的复杂度相匹配问题的类型与构架设计方法步骤相匹配3解决方案架构与企业能力匹配
在总体(或概述)方案架构设计阶段,需要确保方案架构设计与企业的能力相匹配。这个很好理解,总体架构设计需要与企业能力对齐。意思就是能做的出来,而且没有太多的阻力。
举个经典的例子,如果你的架构设计中需要使用微服务技术,容器技术支撑。但企业实际没有这些能力,要实现这些能力就会变成方案架构本身的阻力(要解决问题A就先解决问题B和C)。在方案中解决这类能力依赖的方法有很多,本文就不具体展开。但最直接高效的方法就是尽量避免选择这类与企业实际能力差距较大的解决方案架构,选择企业能驾驭的折中架构方式。
4解决方案架构商业运营合规匹配
商业与运营相匹配确保方案架构设计达到质量标准,能被商业使用。包括功能需求,非功能需求,运营支撑。同时,方案架构是否符合法规,政策也需要在这个阶段考虑。我踩过的解决方案架构与问题不匹配的5种“坑”如下图:
“坑1”:解决方案架构只解决了部分问题,这种坑可能是最常见的。如何避免?做好问题分析定义,在构建设计初期确保架构方案与问题匹配。“坑2”:解决方案架构只解决了问题的表象。而真实的问题或更深层的核心问题被忽略。如何避免?确定问题类型,做好深入的问题分析定义。“坑3”:这种坑也是常见的。解决方案架构虽然解决了问题本身。但同时也生产出新的问题。如何避免?这种坑一般是应为架构设计质量没有把控好。“坑4-巨人解决方案”。这种情况会造成资源的浪费。所以,我在需要架构设计过程中对比,评估筛选不同备选方案。如何避免?架构成本效益分析(CostBenefitAnalysis)是一个很好的方法。“坑5-国足问题”。这类坑的意思是解决方案可能就不存在。就好比有人要你去解决“中国足球”的问题,你的标准答案是-这个我做不了,能力有限。如何避免?做好问题类型分析,避免直接去解决混乱类型的问题。解决方案架构分析过程漏斗模型
根据上面的解决方案架构
转载请注明：http://www.0431gb208.com/sjszlfa/4383.html
