论架构师的关注点：专业向下·业务向上

在架构师的工作中，可能面临两个方向的思考线路，而且需要具备的专业知识往往也是大相径庭的。

当架构师接收到一个新产品的方案设计需求时，大部分情况下产品团队会提供一些产品的背景概述、需求方和存在的待解决的问题、产品拟针对性地提供的功能清单，产品价值评估等基础信息。对于架构师而言，这些信息是直接的，也是单一层面的，即纯粹是功能产品层面的。对于经验丰富的架构师而言，需要做哪些工作呢？

首先，对产品功能做一个宏观的全貌的了解。然后深入分析这些功能背后的能力，这需要架构师具备良好的抽象能力以及撇开交互直抵功能本质甚至需求本质的理解和洞察能力。

因此，从专业角度，需要沿着产品功能往下挖掘，找出背后的业务模型和业务能力。并基于业务模型和业务能力去尝试构建整个产品的基本框架。举个例子，假设产品提供的需求是开发一款微信小程序，用于展示岗位信息，用户可以在浏览岗位信息之后投递简历，用人单位根据简历信息可以与求职者建立直接联系。这就是需求的直接描述。但是对于架构师而言，需要理清楚需求背后的业务模型。即招工单位提供岗位信息，求职者应聘岗位。本质是围绕岗位开展的供需双方的信息互动。其次，从业务模型来看，这也是典型的平台型模式，平台一方面联系求职单位提供岗位信息，另一方面触达求职者去传递信息，从而希望促成供需双方。

基于这样的业务模型设计，我们再来盘点需要的业务能力。

首先是岗位信息的编辑和呈现，岗位信息本身是内容丰富的，不同岗位结构往往还不太一致，因此需要一个内容系统，而且是可自由添加标题的内容系统。如果不是设计成高度灵活的内容系统，只是简单地参照产品原型进行数据结构设计，可以想象随着不同类型岗位的引入，必然会需要不停地增加新的岗位信息，从而不断地开发，既需要较长的开发周期，也浪费研发资源，重点是对业务响应时效还不太理想。

其次，既然是信息推送和撮合，那么如何提高信息推送的精准度就很重要了，这背后涉及推荐算法的能力。当然系统刚推出，对于推荐算法的能力要求不高，但是从模型层面来看，无论是简单的推荐，还是高精准度的推荐，系统都需要这样的能力。不同的只是随着产品业务体量不同，推荐算法的复杂度和效果更强。

此外，对于平台而言，肯定需要获取哪个岗位最热门，哪些候选人最积极，哪一类岗位关注度最高。诸如此类的系统运行时真实情况，一开始或许产品经理未必考虑得到，或许会打算后续的迭代再来完善。但是从能力规划角度而言，这样的数据采集和分析功能，应该是最基本的，所以可以一开始便规划进来。

还有非常重要一点，为了提高匹配效果，一方面希望用人单位新发布岗位时便给求职者进行推行，以提醒他们及时关注和投递；另一方面一旦有求职者投递岗位信息，用人单位一般也希望立即得到提醒，如果是紧急岗位，或许还需要尽快处理。因此，这背后的推送基本也十分关键，无论是对于求职者和用人单位的工作负担的减轻，还是提升平台的撮合效果，都有十分重要的积极意义。我们回顾一下，从简单的产品需求出发，我们罗列出内容系统、推荐系统、推送系统等业务内容，当然，如果我们继续挖掘，或许还可以发掘出更多的业务能力。而这些业务能力相比产品功能，更加抽象，因此其应用场景就更加广泛，可以被不同的产品所集成。实现一次开发多处使用的良好效果。

架构师的关注点

如果你的角色不仅仅是技术型架构师，那么从功能向下挖掘业务模型和业务能力于你可能还不太够，还需要从功能甚至产品往上去思考，所谓的往上，也就是往市场和客户的方向进行思量。

其实对于很多客户而言，产品固然重要，采购产品之后理论上他可以获得产品所具备的能力，利用这些能力可以实现客户某些方面的业务发展或者内部管理等目标。然而理论固然如此，真正落实到实际功能中却可能出现一定的障碍，甚至会因为某些障碍导致预期的业务效果大打折扣。

以灵活用工市场为例，提供佣金结算、电子回单、完税凭证和发票等业务、资金、财务、票务四流合一的产品供应商有数十上百家，功能虽然有强有弱，但大抵都可以支撑灵活用工结算业务的开展，区别无非是谁的产品配置更灵活点，操作更简便些，总之都无法呈现质的差异。

但是对于灵活用工业务而言，光有这样一个功能全备的结算系统就足以开展业务了吗？事实上可能没那么顺利。客户除了一套系统，还需要核实的税源地。国内不同地区政策差异性较大，而且政策也是变化较多，且政策之间有存在新旧并行的阶段，除非长期从事政策研究，时时关注政策动态并做方面加以解读和求证，某者要找到可供业务稳定开展的税源地可能就需要成立专门的团队来负责，而且一开始效果肯定不行，日积月累是少不了的。有了税源地之后，还需要考虑实际的用工业务如何规划，以便合规合法，这又涉及人力资源、劳动法、财税等多学科的专业知识了。要短时间补齐只能说是勇气可嘉。

可见，客户需要的不只是产品，更需要的是能够把产品应用起来的，或者说是把产品所支撑的业务运行起来的一整套解决方案，这套解决方案应该是完备的、合适的可落地执行的。

因此，对于偏向业务型的架构师，解决方案能力是必不可少的。从产品到解决方案，是维度的上升，需要对业务全链条有端到端的深刻理解，并且在理解的基础之上有行之有效的应对之策。难度增加了，但是客户更需要，也更容易获得市场的接受，业务才能够开展。否则只是提供产品能力，在某些行业可能会有鸡肋之嫌。

除了解决方案之外，有时候架构师还需要进一步站在客户立场，思考产品如何在客户环境下成功落地。正所谓不谋全局不足以谋一隅。在全局视角的统筹下，我们才能够横贯始末，设计出的产品才能更具备落地性和惊喜感。

再次提醒我们的架构师朋友们，当接手一个新的产品时，不要一味地盯着功能和需求，一定要向上向下两个方向探索，向下挖掘最本质的业务模型和业务能力，这些是相对固定且具备更强适应性的；向上全链路思考产品的落地和在客户内部的业务上、技术上和管理上的衔接，因为只有衔接良好的产品，才能够发挥奇效。

《企业架构研究与实践》

掌阅：https://m.zhangyue.com/readbook/13007348/1?p2=108694&share=1

微信读书：https://weread.qq.com/book-detail?type=1&senderVid=9239384&v=cb232a90813ab8441g016c47&wtheme=white&wfrom=app&wvid=9239384&scene=bottomSheetShare