数字化落地的四个核心问题 | 自建决策，摩登架构，中台赋能和重塑人才
最近读到两篇报道，两家全球性大公司在数字化转型中遇到巨大挑战，用鲜活的例子给大家展示了，在数字化时代：
不上中台是等死 👉 1 亿欧元的 SAP 项目实施失败：ERP 系统的“整块性”与更灵活的要求不兼容
上中台是找死 👉 两年花费近两亿，构建不出统一 API 系统？
从这两个故事中，我觉得企业数字化转型落地要想清楚四个核心问题：
一、套件和自建决策
从九十年代后期开始，企业信息化的软件选型策略一直存在两个流派：套装软件派和自开发系统派。两者各有千秋，前者强调“最佳实践”，用“削足适履”的方式实施；后者贴合业务需求，大型系统开发风险高、周期长，部门级系统形成“信息孤岛”，到21世纪初，财务、CRM、HR等管理型系统逐渐形成套装化软件潮流，核心系统方面，即使是零售、银行、保险、电信等对流程信息化要求较高的行业，核心系统的套件化也逐渐成熟。
数字化时代，套装软件产业转变为SaaS交付模式，企业运用多个SaaS服务，需要进行云上集成，云上的集成平台就是API系统，也就是说，即使企业采用多个套装软件及SaaS，仍然是有中台的概念。
另一方面，不少企业追求独有的数字化能力，自开发系统有所回潮。在软件技术上，当今软件开发主流是遵循了新一代的、以基于API和微服务的现代化架构标准，某些传统的使用套装软件的企业甚至返回了自开发路线。
企业数字化转型策略的首先要在使用套件或SaaS服务，以及自开发系统之间做出明确的选择。
二、软件架构现代化
微服务是一种业务元素的数字化抽象范式，这样的范式使得软件开发者可以方便地发现、使用、分享、创造各种业务服务。
传统的企业核心业务系统的业务逻辑、以及应用前后台之间都是紧密耦合，所以既不能做到业务逻辑的灵活组合，也无法灵活地调整用户界面前台，前述的LeasePlan案例就是典型的传统企业遇到的架构现代化的挑战。
从核心系统进行细颗粒度的“解耦”，并且封装为前台可以利用平台中立的技术来调用的业务服务，这样连接前台和后台的服务体系就是“中台“。传统行业企业存在较为明显的前中后台之分，而原生互联网企业，业务都是从前台驱动产生的，某种意义来说，并不存在明显的后台。
中台存在两个层面的服务：一层是细粒颗粒度的、从核心业务向外解耦的原子级服务，其上一层是按照一定的业务逻辑将这些业务原子进行组装，形成粗颗粒度的，支持前台调用的服务。对这些服务的定义、编排、注册，则体现了业务与技术匹配的思想。
三、中台赋能前端的组织保障
软件是业务元素（组织、流程、信息、规则）的数字化抽象对象 。当软件架构上做到中台上的“服务”抽象沉淀业务能力，并能够被搜索、被前台方便调用，而现实的业务元素能做到如此柔性吗？
怎样让组织柔性化，从而使得“组织-软件”这对“数字化孪生”能以数字空间的规律来运行，就是数字化实施中对应的组织变革。前文中的2500万美元构建API系统的失败案例，根本上是没有明确的组织治理，也缺乏API治理体系。
信息化时代的组织变革典型表现是“业务流程再造”或“业务流程管理”，而柔性、基于服务的数字化组织，典型的组织变革表现形式是“大规模敏捷”。
数字化服务可以通过搜索发现，而现实的业务元素能够在貌似无规则运行的“敏捷组织”环境中被发现吗？抛除文化变革因素，我觉得有巨大挑战。我在思考，所谓的“中台赋能”，是否存在某种组织形式，来帮助前台组合服务的“服务”，就像淘宝天猫店的商品销售，并不是无人操作自然发生的，仍然需要“小二”来陈列商品、服务顾客；那企业的中台背后，是不是也应该有支持前台人员（前台开发程序员和业务人员）来选用“商品”，即业务服务，的“小二”呢？
四、数字化人才——培养全栈工程师
除了理顺中台和前台的业务关系外，对于“中前台”模式的建设者，亦即IT工程师，也提出了全新的要求。产品经理、敏捷教练、用户体验设计师、安全工程师和开发工程师是新型数字化组织中最重要的几类角色。
中台模式下的开发工程师，和传统的开发人员相比，不仅是他们使用的开发工具、技术平台的变化，而是技术工作者本身的个性特质和工作方式的转型。除了前端工程师、后端工程师、数据工程师、DevOps平台工程师等角色分工外，为了适应快速、敏捷的数字化开发模式，“全栈工程师”是数字化组织中最宝贵、也是最稀缺的人才，他们的工作方式和个人特质是：
他们编写的代码的可读性、可维护性高
动手能力强，对于开发和交付高质量数字化产品充满激情
搭建通用的组件、框架和代码库
他们是活跃的技术社区的贡献者和消费者
持续学习者，紧跟技术潮流
对于技术、平台没有个人偏见
对于各种老旧技术和新技术都有浓厚兴趣
能创造性地解决问题
有效的书面和口头的沟通能力
企业推进数字化转型，需要建立一套重塑工程师的人才培养体系，方能在前述的现代化的架构环境下工作。
数字化转型战略，请关注