话题被岔了一下，目前回到业务中台商品中心的需求上来，为了满足这种系统的运营，先要思考的是组织编排（管理）方式！一个是业务侧，另一个是技术侧，技术侧又分成研发和运维等几部分。这里，不太吝啬地指出一个观点：永远不会找到离开组织模型或者社会协作模型的平台系统，如果有人非得要抬杠，说 AI 能让软件全自动化，那么请打住，一个自动化的系统，比如自动驾驶汽车，不也是最终给人服务的吗？根据康威定义的含义，任何技术架构都会反映到组织架构上，反之亦然！而窃以为，最好是先理清楚人的组织问题，对接下来的产品规划很好的指导意义，按照产品领域的叫法，叫做“解决谁是客户、谁是用户并且他们都想要什么的”问题范畴。了解人怎么运作业务十分重要，比如一个非常有感触的例子，网上也好，书籍也好，都说按业务维度去拆分微服务，但是往往落地效果不佳，其实是没有考虑组织方式的典型例子，微服务粒度不重要，重要的是能够以一个小团队自闭环的完成一个服务的设计、开发、发布和运维，不需要过多和其他团队进行沟通，此时代价最小，微服务的快速迭代目标才能实现。有个著名的定律，叫做康威定律，就是说了这种情况。

从组织架构能发现些什么？

• 研发部门存在协作关系，需要类似 DevOps 平台的能力支撑各种人员角色的协同。（另外文章里讨论）

• 内外部各类应用面向客户不同可能导致对底座产品诉求是不同的，比如在流量支撑规模、性能、稳定性上的不同，在运维上也因为面向的业务场景不同而存在不同，但是底座产品功能可以做到统一化，所以根本上是能力需求的不同，这是技术领域的问题。

• 可能存在多种交付形式，由于 Dev 与生产环境软硬件的差异性，也就是运维特性的差异性，另外研发和交付团队是两个团队，交付设计传递过程中产生信息变形或者理解差异非常正常，这些都导致交付成本居高不下，虽然这个完全靠技术不能得到 100% 的解决，但是在技术上需要往低成本的交付自动化能力而努力。

• 部门或者组织之间可能存在数据安全的问题，需要得到重视。（另外一篇文章详细讨论）

• 在公司级别，可能存在需要全局技术能力治理的需要，比如将 IT 统一分配的管理的需要，背后的动因是节约 IT 投入成本。

• APP 前后台账号体系的需求，也同时存在需要对接各种账号体系或者服务的需求。IAM 是底座平台对账号体系的支撑子系统。（IAM 可以归类为业务层支撑，IAM 在另外的文章里讨论）

• 由于这些组织部门不是在业务系统构建时才有的，它一定存在很久时间，所以传统的系统遗留或者核心 ERP 系统的存在，在不可能为已经存在的系统再做一遍云原生改造的情况下，一定会产生系统集成的需求。另外隐含着即已存在的微服务系统透明化上云的需求，以便在最低成本下，获得容器底座的能力，以便加强业务应用的技术支撑能力。

• 企业间可能存在集成关系以便构成企业间协同关系，所以开放平台等连接生态的机制需要考虑。

• 无论基础设施也好或者业务应用也好，都需要运维部的运维保证，所以需要能够给予云原生的思维，构建自动化的甚至于智能化的运维工具体系提供给用户使用。

• 无论是跨部门还是跨公司组织交付，都需要共享的镜像服务作为支撑。
  

 

上图可以看到的是，客户是诸如 X 划算这样的上层业务组织，用户们则是如上图一般其具体业务运营的人群所构成，而底层技术设施用户协同之实现受到业务层需求的牵动或者影响，这可能因为领域知识的不同以及团队归属的不同而带来实操时无法获得一致的效果等现象，更深入一些的话，不同团队归属还隐含一个交付的大问题，分属于不同团队的研发环境与生产环境软硬件等条件不一致，导致交付成本高的问题，所以对于底层基础设施的实操要从业务应用角度抽象简化和自动化运维事项，以便从高纬度视角统一意图的效果变现。

可以看到的是，分析组织形式不仅仅是协作分析，还会引申出很多技术上的诉求。从业务需求、市场分析以及组织分析所归纳出来的第一阶产品架构是：