中台和架构，企业级软件产品设计绕不过去的两个话题

万众瞩目的英雄联盟S14全球总决赛，于9月25日，正式拉开帷幕。来自全球各大赛区的种子战队，以及众多的外卡战队，将于德国角逐出本年度最强。在经历了四日的入围赛后，MDG和GAM成功晋级瑞士轮；VKE和SHG失去世界赛资格，R7，PNG，PSG和100T则要争夺最后的出线机会。

在数字化转型的浪潮中，企业级软件产品的设计面临着两大核心议题：中台构建与架构规划。这两个话题不仅关系到企业的技术战略，更直接影响到业务的创新能力和市场竞争力。本文将深入探讨中台在大型企业数字化转型中的价值，以及在设计整体架构时需要考虑的关键方面。

十几年产品经验，一路走来见的系统、做的系统已经多的自己都记不清了，从最开始在初创型公司里只有几个核心业务系统，各种被业务催着上系统；到成长型公司各种业务创新导致系统百花齐放，迷失在落地产品项目失败再落地产品再失败的无限循环；再到成熟型企业（四十年历史的上市公司）里面各种历史陈旧系统、半线上化系统，不断的在给前人填坑和给后人挖坑的过程中；到如今在一家大型央企的销售板块做企业级系统，做系统既需要“脚踏实地”又有需要“高瞻远瞩”。

以前对企业级应用从单体到 化到中台化（服务化）没有太多的感触，近期回顾这十几年的经验略有感悟，故把做企业级软件产品中关于中台、架构方面的内容稍作总结。

中台这个概念已经不是一个新概念了，从15年开始算到现在也差不多10年了，经历了从最开始的普及验证阶段，到18、19年市场盲目追捧中台概念，各种类型的中台层出不穷一下子感觉中台就是企业数字化的银弹，上了中台包治百病，再到疫情这几年市场氛围逐步冷却下来，甚至出现了中台已死的论调，不断有人抨击中台，认为其是创新的阻碍、投入产出极低的IT投资。其实不管市场、专家怎么看，中台还是在适合它的企业逐步落地生根，发挥它应有的价值。

在中小型企业落地中台实际意义不大，投入产出比也是不高的，原因在于中小型企业没有那么多的应用系统需要整合，也没有那么庞大的IT团队需要管理，更没有那么强的业务标准化能力。中台需要在大型或超大型企业进行落地，在这些企业里面IT的投资都是巨大的，IT团队的人员都是几百上千人，如何能够有效的去进行IT团队的管理，如何能够让统一的IT架构能够落地、迭代发展这些都是需要有一套方法去指导实践的。另一方面，大型企业建设的系统繁多，大多都会面临软件系统“烟囱”问题，跨系统之间的业务流程脱节、各系统之间的链接交互不顺畅、数据不规范不标准等等问题。另外大型企业基于其核心的竞争力，会大力发展多种多样的业务模式，新业务模式的出现大企业都会投入资源去进行尝试、验证，以加强其感知市场、引领市场的能力。

中台帮助大型企业在 以上几个方面的问题上，不失为一个可行的方案，至少是被部分企业验证过可行的方案。

通过中台化我们能够更合理 的管理IT团队，能够对IT团队的组织分工进行合理的划分，能够通过需求结构化的方式把业务和IT良好的串联起来，让团队效率最大化、质量更可靠。通过中台化我们可以在企业内部总结业务标准、规范，并把这种标准规范通过代码的形式进行固化，而且能够从IT和业务团队从全局的角度去分析、设计业务流程和系统功能，再逐步把存量系统接管，在其上去“生长”增量系统，能够有效的 “烟囱”问题和数据不标准的问题。最后在中台化的过程中我们要能够把IT资产化，能够不断的把业务中通用的服务和能力沉淀下来，变成一种在企业内部可以随时随地可获得、可使用的资源，在降低IT系统建设成本的同时，提升IT系统建设的效率，能够有效的去支持业务的创新。

关于中台的产品设计可查看之前这篇文章《详解电商中台产品设计》。

在 ISO/IEC/IEEE-42010:2011 标准中对于架构的定义是：架构是系统在其所处环境中的基本概念或属性，体现为它的元素、关系，以及系统设计和演进的原则。在数字化转型中所说到的架构设计指的是软件架构，一般来说包括这几个部分：业务架构、应用架构、数据架构和技术架构。

在大型企业做数字化转型的时候架构设计是绕不开的话题，架构设计是一个内涵 丰富的东西，又是一个看着很美好但落地却又不那么美好的东西，有时候它就像使命、远景一样看不见摸不着又好像无处不在。架构设计的出发点是业务，软件架构需要能够有效的考虑当前业务中所面临的可以通过IT的方式进行 的问题，同时还需要有一定的超前考虑（一般为业务发展的三到5年的眼光来看待），太超前的架构难以落地，只基于现有的问题域进行设计则没有指导意义也很难落地。

在做架构设计时一定要充分考虑业务的现状以及未来一段时间的发展，我们既需要站在整个业务价值链的角度去进行系统和子系统的设计，也需要站在业务需求的角度去进行具体功能设计，还需要从技术的角度去考虑架构整体的稳定性、扩展性和安全性，架构设计有时候更像一门艺术。

在当前数字化转型的大环境下，架构设计出了满足企业内部各个业务部门的业务要求外，还需要考虑如何与客户、供应商、合作伙伴等进行链接，任何一家大型企业在整个市场上都不是孤立的存在，需要和成千上万的上下游及合作伙伴进行系统层面的交互，这种交互可能是直接给它们提供系统也可能是给它们提供可自主使用的API接口、消息或数据库查询服务等，在这种市场环境下对企业级的架构设计的要求就更复杂了，既要能够熟练的掌握软件架构的方法还要能够对互联网大并发架构有深刻认知，我们要能够合理的设计业务协同 、开放 以及集成 ，还需要考虑类SaaS、PaaS的多组织/多租户架构，可参考如下架构：

笔者当前所处企业是一家大型央企，在整体的组织架构上属于总部+省市的两级组织架构，各省都有较强的业务开展和IT建设能力，各省在历史上建设了大量自研的IT系统，且多为在各省本地部署，而集团总部也建设了大量的统建系统正在进行使用，而当前所处的阶段则是集团总部需要把主要的核心业务系统都统一进行规划设计实现一体化的目标，要求在架构设计时也能够充分预留给各省份自主创新的能力。

架构其实很多时候不是规划设计出来的，是从系统不断迭代升级的过程中演化出来了，而我们要做的就是为这种演化提供环境、找到方向。

在这些年做企业级软件的过程中有很多不同的经历，以上两个方面的一些思考是对近期工作开展过程中一些疑问的总结，希望也能够对各位稍有启发，也希望能够与更多的通道中人进行交流，共同成长。

专栏作家

不可分类者，微信公众号：数字化产品，人人都是产品经理专栏作家。专注于电商中台的产品设计，擅长产品规划及需求分析；热衷于研究中台、SaaS等领域的 产品形态。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议