大数据技术架构的问题？
面对市场上的日益丰富的产品选型中，技术架构有多种，我接受了SOA和中台的产品，SOA的产品线是基于总线型的，在各应用系统之间， SOA 依靠 ESB 实现系统集成，ESB 是治理点对点式的系统集成的核心手段它肩负着如下重担
1.实现系统间的连通；
- 数据转换；
3 智能路由；
4安全控制；
5可靠性控制；
6服务管理；
7.服务与监控
SOA 针对医院业务系统架构的治理主要依赖于两个方面：一方面
立足千每个应用系统，要求系统对提供的“服务” 进行提炼和抽象， 确保其灵活、可重用，这
是让服务满足外部复杂需求的根本保障；另一方面是通过中心化的交互媒介一—ESB 来约束系
统间的交互，消除点对点式集成的负面影响。
但令人感慨的是：走到今天，回看医院曾经在SOA 上做出的
尝试和努力，最后的效果多数都不够理想。在完成SOA 改造之后的若干年间，受到后续各种新
系统的冲击，很多医院都没能坚守住自己的SOA 体系，最终又回到了烟肉架构下的野蛮生长状
态，这其中的原因主要是：
1.沟通与协作成本高：新系统迫千业务需求和市场压力，急需上线，对负责的团队而言， 与周边系统的对接和调试属于外部不可控因素，团队总是倾向千在内部可控的范围内解决问题，因此会刻意避开对外部服务的依赖，选择自建相关功能，这样一来，系统间的交互会向着衰减的方向发展，重复建设也因此随之蔓延；
2.组织架构制约：团队往往缺乏为响应其他系统的诉求而改造和升级自身服务的意愿，因为新系统与他们没有直接的利益关系，医院也缺乏适当的奖惩机制促使各团队之间的积极协作， 本质上，这是组织架构决定的；
3.缺乏长效机制：SOA 改造常常是作为一个项目实施的，项目结束之后就不再有专门的组织和团队对 SOA架构进行持续把控了，后续新的系统在融入 SOA 生态时受到的支持就减弱了，而新系统本身提供的服务也缺乏必要的梳理和管控，有的新系统甚至不对外提供服务。
后来发现提出来了数据中台
数据中台就是一个什么都能装的篮子，除了原有数据平台内的技术框架、应用场景、其它的或许跟大数据一点边的场景、数据内容、框架都会往里装，以及站在更高的组织结构上去思考数据的全局化、统一化、一致化的设计与实施，强调复用性、共享式的服务。
我们如果太依赖中台，产生这样的问题，中台为了做规模强制向业务线推行，业务线被迫削足适履，消耗严重。1.每次中台升级，小的 BU 更是叫苦不迭，故障频发 2.中台能力一旦发布， 独家专供， 哪怕功能不完善， 设计不合理也不允许业务团队复制或分支。3
我们面对这样的问题，如何做业务和产品的迭代，请专家给予讲解