一份方案设计文档
对问题、涉及的系统和最终选定方案的书面描述,连同被否决的替代方案及其原因。
迪拜企业往往会在一个特定、容易识别的节点开始迪拜聘请解决方案架构师:出现了一项新需求,而对于”这该怎么搭建”这个问题,诚实的答案是”这取决于我们已经在运行的三套系统”。也许是一种新的在线支付方式需要无需人工导出就能接入财务系统。也许是 CRM、预订平台和营销工具都需要对同一位客户的记录达成一致,而不是各自维护略有差异的三份记录。这是一个解决方案架构问题,而不是一次单纯的搭建,因为答案必须尊重那些已经存在、且当初并未被设计为协同工作的系统。
解决方案架构师的工作,是在开发开始之前把这个答案设计出来:哪个系统拥有哪部分数据,各部分之间如何通信,哪些需要改变、哪些可以保持原样,以及上线过程该是什么样,才能让一切在推进中都不出岔子。产出通常是一份书面设计、一套图表,以及一份对各种取舍的坦诚说明,交给真正负责搭建的团队,无论那是您自己的开发人员还是我们的团队。
这是一个比软件架构师更窄、也更偏技术的角色,软件架构师端到端地掌控一个产品的内部形态;它的范围也不同于企业架构师,后者为企业内所有系统设定标准,而不是解决其中几个系统之间的一个问题。这两个角色在本站都有各自的页面,在撰写工作简报之前先弄清楚区别,能避免找错方向。
解决方案架构师交付什么
迪拜企业在为一个真实的跨系统问题聘请解决方案架构师时会得到的东西,而不是一份充满愿景的幻灯片。
对问题、涉及的系统和最终选定方案的书面描述,连同被否决的替代方案及其原因。
系统之间如何交换数据的清晰图景:每一项信息以哪个系统为准,通过什么接口传递。
当不止一款产品能解决问题时,对照您真实需求做出的比较,而不是照搬某个供应商自己的销售说辞。这正是阿联酋企业在聘请解决方案架构师,而不是单凭一家供应商的说法做决定时,应该得到的那种比较。
各项操作发生的先后顺序,让现有系统在新方案落地期间依然能为用户正常服务。
把推荐方案的成本和风险说得足够清楚,让非技术背景的相关方也能批准它。
一份把每项设计决策与它所满足的业务需求对应起来的记录,确保没有任何东西是为了搭建而搭建。
重要技能
要看重的是在自己未曾搭建的系统上做设计的能力,而不是简历上的工具清单。
| 能力 | 优秀候选人的表现 | 为何重要 |
|---|---|---|
| 读懂陌生系统 | 能足够快地上手一个自己没有参与搭建的现有代码库或平台,诚实地据此做设计 | 大多数解决方案架构工作都会涉及架构师从未参与选型的系统 |
| 公认的设计方法 | 熟悉像 TOGAF 标准这样的结构化方法,并凭判断力灵活运用,而不是死板照搬清单 | 让设计拥有一致、可解释的结构,而不是随意画出的图表 |
| 供应商中立性 | 对照您的书面需求比较产品,解释推荐方案时不依赖品牌名气 | 一个带偏见的推荐,会在架构师离开后很久仍然让您付出代价 |
| 集成模式知识 | 知道什么时候该用 API、事件、批处理任务还是共享数据库,以及选错的代价 | 选错集成模式,是日后代价最高、最难挽回的错误之一 |
| 与相关方沟通 | 能把同一份设计,分别以合适的详略程度呈现给开发人员和业务负责人 | 一份从未获批、或从未被搭建团队理解的方案,什么价值也不会实现 |
合作方式
最常见的合作方式是基于项目:一个明确的问题、一份设计,在明确的完成节点交付。如果供应商或您自己团队已经提出了一份设计,一次较短的咨询审查更适合在投入预算搭建之前先核实一下。如果您更希望把解决方案架构师招入自己名下,我们的招聘支持负责寻源、筛选和组织技术评估,最终录用由您决定。同时运行多个设计问题、比起单一交付物更看重持续可用性的企业,通常会选择专职合作。
评估候选人
用来检验他们能否针对自己未曾选定的系统做设计的方法。
请候选人现场用您真实的系统,而不是一个通用的教科书案例,勾勒一个方案,观察他们在动笔之前如何提问。
有真实经验的候选人能说清楚,为什么一份早期设计在实施开始后不得不被修订,而不只是展示一份号称完美无缺的设计。
对他们展示的任何设计,询问他们还考虑过什么、为什么没有采用。一份没有被否决方案的设计,通常说明它并没有真正被拿来比较过。
询问一次供应商极力推销、但并非最合适产品的经历,以及他们如何与客户沟通这个话题。
请他们展示为搭建团队准备的文档。一份只有架构师自己能看懂的设计,并没有真正完成交接。
认证
在迪拜聘请解决方案架构师前值得核实,不过认证更多说明方法论,而不能证明他们曾解决过您这个具体问题。
由 The Open Group 依据其 TOGAF 标准颁发,当企业希望候选人采用一套有文档记录、可重复的设计方法,而不是完全个人化的做法时,值得询问这项认证。
如果方案高度依赖某一家云服务商,该服务商自己的解决方案架构师认证,例如 AWS 的认证,可以作为一个合理的补充信号。应结合您已经看到的设计和交接成果一并权衡,而不是单独作为依据。
阿联酋相关考虑
在为一个跨系统的设计在迪拜聘请解决方案架构师之前,值得提出的问题。
《2021 年第 45 号联邦法律令》规定了阿联酋对个人数据保护的要求,无论数据在哪里被处理都适用。一份在系统之间流转客户或员工记录的设计,应从第一张图表开始就满足这项要求,而不是在搭建开始后才补上。
如果阿拉伯语和英语的内容或姓名需要在系统之间流转,应尽早约定每种语言以哪个系统为准,因为事后再补做这项决策,代价远高于一开始就纳入设计。
直接解答
软件架构师端到端地掌控一个产品,从技术栈到内部结构。解决方案架构师则从一个业务问题出发,例如把一种新的支付方式接入现有财务系统,设计如何跨越已经存在、可能涉及多家供应商和多种技术的系统来解决它。
通常不需要。一次独立、自成一体的搭建,通常由软件架构师或该项目的主导开发人员负责就足够。当问题出现在已有系统之间时,例如 ERP、CRM 和电商平台都需要对同一位客户的记录达成一致,才是在迪拜聘请解决方案架构师的时机。
不是。解决方案架构师针对一个问题设计一套方案,有明确的起点和终点。企业架构师则为整个组织设定标准和技术方向,之后许多独立的方案都要遵循这些标准。我们的企业架构师页面介绍了这个更宽泛的角色。
本页介绍的是不限定技术平台的解决方案架构师。如果您的问题专门限定在这些平台之一,我们的平台专才页面,例如 SAP 解决方案架构师或 Salesforce 解决方案架构师,会更深入地涉及该供应商自己的工具和认证。
有时会,但核心交付物是设计本身:图表、集成方案和书面依据。搭建工作通常由专职开发人员或项目团队另行完成,以解决方案架构师的设计作为工作简报。
资料来源
书面固定价格
已收到,我们正在为您撰写报价。
工作时间内您将在 45 分钟内收到。请查收确认邮件。