公共能力建设
在前面的多产品架构升级中，我们讨论了多产品业务隔离的发展。我们可以看到，随着业务发展，我们会把公共的业务独立出来。虽然这是一个相对自然的过程，但其中也会面临很多挑战，因此有必要单独出来进行讨论。另外我们也一起会讨论一下其他公共部分的建设。
独立公共团队
对于公共业务的维护，如果职责不清，会带来设计上的混乱，所以最好由独立的团队来维护。当团队规模不大时，也可以指定某个业务团队来负责。部分技术类的公共能力，也可以考虑由公共的虚拟组织来负责（比如前、后端的开发框架）。进行公共能力建设的团队，需要具备以下能力：
- 需要有较强的业务理解和抽象能力。公共业务和不同的产品团队都有交互，会出现不同的需求，需要较好的理解业务和洞察，才能进行较好的抽象。如果团队规模较大，或者公共业务比较复杂，可能需要配备公共业务的产品经理
- 具备较好的架构和代码设计能力。公共业务影响范围较大，变更成本更高，需要更灵活的设计，减少变更带来的影响。
- 具备较好的沟通协作能力。公共团队需要和各个业务团队进行沟通协作，有时候还需要协调不同团队间的差异，良好的沟通协作能力有利于提升团队的整体效率。
需要独立的公共能力
基于多产品发展的场景，以前在单个产品中的公共能力需要独立出来进行建设，避免重复建设和系统表现的不一致。我们需要从业务和技术两个方面进行考虑。下面我们列举一些主要内容：
业务方面：
- 用户体验：包括登录方式、界面风格、交互设计等的统一。可以由公共团队的相关角色主导。如果能力有欠缺，有UED团队则可以由该团队主导，与前端虚拟团队一起建设；没有统一的UED团队，可以由前端虚拟团队来主导。最终通过开发框架、前端组件和开发规范来进行约束。
- 多租户业务管理：包括租户的授权、计费、运营管理等能力。
- 公共业务：包括组织、用户权限等系统功能，也包括产品、项目、客户等公共业务信息的维护和管理。需要注意的是公共业务的抽象层次，如果包含太多产品个性化的内容，则会带来不必要的多团队协作，会增加沟通和实现成本；如果抽象得不够，又会导致多个产品重复建设，带来业务数据或逻辑不一致。
技术方面：
- 工程基础设施：包括DevOps相关的规范以及对应的工具支撑，如果团队规模较大，可以由单独的团队来负责。团队规模较小时，需要联合运维团队一起建设。
- 代码框架及组件：可以由公共团队的相关角色主导，或由前、后端虚拟团队来主导。对于第三方组件的引入，可以由业务团队提出需求，由主导团队进行决策，由使用团队或公共团队负责引入相关的适配工作。
- 中间件使用：公共团队需要定制统一的规范，以实现业务、租户的隔离以及性能扩展的目的。必要的时候需要维护和提供统一的SDK来供业务团队使用。同时需要参与对中间件的运维，优化部署架构。
- 第三方集成：如前面提到的，对于第三方集成，需要进行统一的管理，必要的时候提供统一的接入封装。对于同一类似的多个第三方（如多个短信平台）由公共团队负责适配。
- 个性化需求能力支撑：公共团队需要负责前面提到的满足个性化需求相关的能力建设。比如特性开关、规则引擎、开放接口和事件等。
- 多租户管理：多租户的信息维护，框架建设、接口提供等。
