稍微上点规模、分业务线/产品线/事业部管理的公司都会面临此问题，尤其是业务快速扩张期。自己所经历的公司也面临过类似的严重问题。
业务后台是集中式还是分布式都有其道理，一方面从公司管理层面、运营层面、研发层面必须考虑各种成本，另外一方面又要满足互联网公司各业务线创新、试错、快速上线的不同需要。务实及折中的做法是：集中式为主+分布式为辅结合的形式。
大的设计指导原则及建议：
1、避免重复造轮子
2、在公司层面与客户关系管理相关的核心资源必须统一集中管理，包括商户/用户/合作伙伴等等的资料信息。
3、与公司核心业务运营流程相关的系统必须集中统一管理。一个典型的例子是第三方支付公司的用户管理、商户入网、商户对账、商户清结算等。
4、与公司经营分析等相关的业务系统数据需要及早考虑集成及集中管理。
5、必须减少业务人员、运营人员多系统切换的成本，例如：要记录不同系统管理后台地址、用户/密码。要适应不同系统的界面风格、操作逻辑。
6、在产品/项目立项评审流程中加入对业务后台是基于统一运营平台还是单独开发的评审点，以兼顾公司层面统一管理需要和各业务线个性化需求、工期、创新的需要。
基本上所有的业务线都会希望自己能够对业务有绝对的主控权，也会低估自己开发的难度，因此都会选择自己做。
技术架构的一些建议：
1、在公司层面基础技术框架统一并复用
管理后台的操作风格风格统一。
管理后台所采用的技术框架尽量统一。
管理后台的基础框架及基础功能尽量统一。
其中基础功能包括：组织架构、人员权限（功能权限、数据权限）、菜单管理、菜单权限、单点登录、工作流、操作日志等与业务无关的功能。
具体到那些业务功能需要作为基础功能提供，根据业务实际情况确定。
以上基础功能，尽量能够作为公司级blank项目的基础功能，以便于其他业务线需要单独的运营后台时在其基础上快速创建。
2、业务后台Portal
业务portal提供对各个业务后台集中统一入口，包括：
a、整合公司组织架构、员工信息，为各业务系统提供统一的视图。
b、提供员工与各个业务后台的用户、角色的映射，不用到系统权限级别，只需要到是否有权限访问对应的业务后台。例如员工登陆后，有哪些业务系统的入口。
c、提供各个业务后台的单点登录功能
d、提供与公司其他核心公共服务的统一接口。例如与客服系统、财务系统、短信网关等。
这里指的portal不是指商业软件的portal解决方案，商业软件portal设计思路有值得借鉴的地方，但作为业务后台portal，核心还是业务本身，没必要搞得太复杂。
业务后台portal的价值一方面为各个业务后台提供统一的入口，避免运营人员记录一堆密码的问题，更重要的是降低各个系统用户管理的隐形成本。
例如系统用户对应的员工离职后，其账户的删除、停用。单一系统相对好说，如果公司有多个系统，再加上与人力资源的离职流程衔接存在问题，则怎样及时清除过期的账户、停用非活跃的账户则存在较大的挑战，也是诸多风险的温床。
3、公用业务服务SOA化
可以考虑采用dubbo+zookeeper等SOA框架来实现服务集中统一管理
