你们公司/部门 有没有遇到这种场景，你们的一个工作台，需要集成很多其他事业部/部门/小组的能力，这个能力可能是接口，组件。这种你们有没有统一的解决方案

这个叫 Web portal

中台大佛爷可做不得这个

不就是一个统一门户吗，支付信息，用户信息，账单信息，补偿券信息可以看作是单独的子系统，不同小组独立开发，然后子系统地址放到你这统一门户里面通过超链接跳转过去，当然了，考虑到用户登录、权限之类，集成之前要先规划好单点登录、页面风格之类。

个人理解，中台是个人力组织结构概念，可以把各个业务方向需要的共通能力交给中台部门来做，交付给各个业务部门灵活运用，从而节省整体开发成本。

中台的核心目标在于只做通用化的工作，所以像题主描述的对接各个业务部门需求的情况应该不属于中台的职责范围内，因为并不能通过统一开发通用功能来降低整体开发成本。

题主所描述的更像是一个单独的后台部门，单纯把各个其他部门的后他开发需求包过来（内部外包？），如果每个部门的后台开发工作量不值得专门配备一个开发团队的话，这样可以集中管理和最大化利用后台开发人力。

其实如果每个部门有必要单独拥有一个后台开发团队的话，也可以由中台团队维护一个后台框架，制定框架中组件的开发接入标准，以文档的形式提供给各个业务部门，中台团队不需要单独对接每个系统，而是每个系统主动接入到这个统一后台平台上来，中台只负责整体框架的运营和管理，做好各组件之间的隔离。

我这边因为要对接的系统都是其他部门的，自己这边是使用方，日常使用要跳转 N 多个系统。最终我们是自己写了套 sdk 对接所有的三方（有做一些并发控制等），之后在上面按自己使用的需求做了一层 api 抹平了所有的三方（主要是数据格式转换统一，接口风格统一），开发的前端对接我们自己的接口。

@Haujilo 我理解前端是你们来开发，其他部门是来开发接口，然后接入你们这个统一的 sdk 吗

@wangxiaoaer
@janxin
@libook
举中台有些不恰当，想象有这么一个业务部门，他们的业务运营就是需要集成集团内其他各个事业部的数据能力，比如客服业务，坐席客服处理工单的时候需要很多辅助类的工具，这些工具一般就是一些查询能力的载体，数据来自各个部门，这里面就涉及到跨团队协作和一些技术问题了

@chenshun00 事实业务可能会有几百个这样的需求，而且不可能要求每个事业部都为你的业务做一个单独的能跳转过去系统

@LawlietZ 前面的对，但是 sdk 不是他们来接入，是我们自己拿其他系统接口，自己写代码实现调用。这么说吧，假设有 100 个外部系统，我们就要自己接完 100 个系统。没办法，其他系统方的都不做。

@Haujilo 诶，那如果业务诉求就是很多，你们这种协作方式搞不定吧。最好的就是下游打包接口和页面，你们只负责接入，这个诉求你们业务方可以推动。老哥是哪家公司呀

iframe ，请

amis

@LawlietZ 都是排期做，并且我们自身需求对三方虽然要接入也只是小部分功能，主要还是把工作流对各个三方之间打通，所以还好。你们公司下游愿意做当然是最好，跨部门之间，做这些对他们没有 kpi 要求和或者没有绩效就不会做了，最终都只能自己做，有些三方连 api 都没有，要求公开 api 都能扯个把月的。

@LawlietZ 这个名字叫 web portal ，几十年前比较流行。Java 有个规范对应的，不过我猜现在也没人实现这玩意。剩下的你可以自己慢慢 Google 。解决方案好像是有商业版本，不过还需要推动内部接入

@janxin 你应该没懂我问题。web portal 我知道，不是一回事。你可以看下你楼上，问题场景类似。我描述的是一个业务问题，不是一个后端技术就可以解决的

@Haujilo 嗯，场景应该和你们类似了。但感觉你们没当做一个场景问题去专门来解决啊，我理解你们现在就是按部就班的排期搞。by the way ，你们是什么业务呢，一般能遇到这种场景的业务也不多见