业务架构
在方案设计时，如果“数转办”过去有进行知识积累，或者对业务知识有足够的了解，那么这时正是将这些知识融入到平台方案设计里的用武之地。
比如业务部门想在“用户画像”的基础上，为不同画像推荐差异化内容；也就是说，需要一个工具能获取用户画像的结果，并允许运营人员针对不同画像设置推荐规则。
如果在没有业务输入的情况下，研发团队可能给出的方案就是：
基于用户画像的某些具体信息，如年龄、性别等，分别设置不同的内容结果。如下图所示，当用户A喜欢物品A时，与用户A相同画像的用户C获得物品A的推荐。
但经过业务分析师（Business Analyst）基于对业务的理解，分析业务提出的这个需求后，则基于用户场景将需求细化为更多样的推荐能力：
根据特定的用户路径进行推荐：比如想通过推荐内容引导一个“理财小白”开股票户，那么就先通过“用户画像工具”定义数据湖里上“20-30岁年龄、2-5万资产、自由职业&互联网&xxx等职业、在企业App上进行过xxx行为”的用户画像为“理财小白”； 当该用户进入“内容专区”页面时，被推荐的内容为带有“打新”、“新手上路”、等等标签的内容，并引导用户去“打新股”页面购买预备上市的股票； 当该用户在“7天”内完成过“打新股”的操作时，该用户则被转移为“打新客户”的用户分层中，内容推荐则增加“可转债”，引导“打新客户”进行这种收益较高，风险较低的投资方式。
基于用户社交关系推荐：比如用户A通过微信注册App，通过微信ID获得好友列表后；当用户进入“内容专区”页面时，将其好友B看过&喜欢过的内容加入内容推荐池；而当用户点击/点赞xx条相同内容后，将用户打上与其好友B同样的标签，并纳入用户画像中。
基于内容的推荐：这个策略的核心在于基于用户过去感兴趣的内容，建立起内容的一个相似矩阵；内容的相似性是通过内容的一些特征进行量化计算，当用户喜欢某一个内容时，将相似内容纳入推荐池。比如把一篇文章的完整阅读时间、作者、内容类型标签、读者受众标签进行量化，然后在候选集中找到与之相似性最高的内容。
...
在BA将业务方提出的“一句话需求”转化后，就将“内容推荐”这个能力更贴合用户在不同实际场景所需要的内容，推荐自然更有针对性。
而每一条推荐方式的设计，都提高了技术方案的复杂度，远非研发团队最早的理解；
“数转办”就是要通过这种方式，帮产品孵化团队更了解真实的用户需要，以更符合业务需要，这样在未来产品迭代时，对技术架构的影响也最小。
技术架构
在设计技术架构时，要更贴合业务架构，这样技术架构才能更稳定，在未来提供服务给其它工具时，大大降低团队的工作量。
比如刚刚讲到的“内容推荐”方案，如果按照研发团队自己的理解，则技术方案可能是：
将用户所带的“标签”、“标签组合（即用户画像名）”以API的形式向外提供出去，外部系统既可以通过某一个标签组合获得所有标签，也可以获得符合该标签组合的所有用户ID。
而经过BA分析后的“内容推荐”方案，对技术方案的要求则是：
外部系统除了获取数据外，还可以为用户ID添加一个或多个（一组）标签；
除了用户ID，还要获得用户ID所关联的一系列的元数据；
除了获得用户ID所关联的一系列的元数据，还需要添加元数据进去；
......
那么在讨论技术架构时，尤其是哪些功能由谁维护时，就更要和BA紧密合作，基于用户场景和未来可能的需求进行分析。
比如除了用户画像、内容推荐功能外，未来要做的用户旅程、漏斗分析也需要调取甚至添加元数据，那么就需要有专门的数据团队来管理“用户ID”，而不是被用户画像工具团队管理。
再比如“用户画像”工具团队现在已经将一些用户操作行为，如“启动App”、“页面停留时间超过xxx秒”作为标签进行管理，而在未来开发“漏斗分析工具”时，需要对更多的用户行为操作进行管理，那么这些数据应该由哪个团队统一纳管，且由谁配合谁改动代码，就需要在当前技术架构设计时就明确清楚。
从新旧两种技术架构的思路上，就可以看出研发人员原本的方案根本没有考虑到未来业务的变化；而贴合业务架构的技术架构，在面对需求增长时，才有更好的拓展性，边界也更加清晰明确。