对企业数字化转型的思考
有幸在IT行业混了20年，有幸在2年前就关注了企业数字化转型这个话题。但当我看到行业内对数字化转型所采取的对策时，内心有一种深深的担忧。
参与数字化转型的决策部门或者决策者们或许正在不知不觉中犯了左倾的错误。以为现在正在砸碎传统IT这个旧世界，在重建一个新的IT世界。而在决策和执行过程中，“专家学者靠边站，革命小将放卫星”的现象已经屡见不鲜。
而那些推波助澜者，
- 要么对所谓的双速或者叫双模的真实用意一知半解
- 要么没有能力看到IT的生态圈和全生命周期，一叶障目。
- 要么只是想趁乱抢块红烧肉吃
实际上，数字化转型的需求和IT技术的发展相辅相成互相促进。IT技术的发展是在外因推动下的内生性发展，是在传统IT坚实基础上，追求更高效、更精益化的变革。就如，爱因斯坦离不开牛顿，牛顿离不开欧几里德一样，巨人是因为他站在了巨人的肩膀上。绝对不是推倒重来。
从IT建设的大处讲，
- 敏捷的软件开发依旧以CMMI为成熟度度量模型
- 敏捷的运维管理依旧以ITIL为IT服务框架
- 信息系统规划依旧以TOGAF为指导…
而DevOps的方法和工具的目的是要把他们拉得更近，而不是抛弃它们。
从IT建设的小处讲，一个系统的实现，最终还是要落实到事务、进程、线程等的信息传递与反馈。
IT技术就像一潭平静的水，而水中的生态在默默地进化。而互联化就像向水里扔一块砖，甚嚣尘上，激起一阵波澜；但当尘埃落定，最终会沉入水底，融入到IT的生态圈中。
对于传统IT部门来说，一个最大的挑战是，对新型的业务需求的准备不足，这种业务需求的特点往往是这样的：客户数量巨大,业务复杂，需求和变更迭代提出而非一步到位，交付要快，客户端多屏化，全天候全球化地提供服务，而系统成本要低。
而传统IT部门在应对大量的企业级和部门级需求的时候，往往采取购买软件进行实施或者外包团队开发的方式，逐年制造出大量关系并不紧密的竖井式的单体应用或者巨石应用。这种“借腹生子”的方式使得“平均一个IT人员承担2至3个系统的开发运维”成为可能，同时IT部门无法也无需建立统一的开发支持体系，系统架构的非平台化也成必然。
由于业务从“唯稳不破”上升到“唯快不破”的格局，传统IT应该从这几个方面去破局：
1，建立开发支持体系（稳定的开发运行团队和可靠的支持系统及敏捷的流程），全方位支持需求分析架构设计CICD，使得复杂应用的敏捷开发快速交付成为可能（成百上千个服务模块假如不进行有效管理，后果会是很吓人的），能自动化的尽量自动化，有规范的尽量按规范进行标准化，抓住客户核心诉求（需求定位，过滤需求,抓核心KPI），
2，建立新型业务架构，前端技术支持多屏移动，全面解耦业务需求，模块化微服务化，后端平台云化，云平台PaaS化和CaaS化，
3，对已有企业应用，从数据层进行整合，提供统一的数据和业务服务接口以备新型业务的需要。
看起来任务好重，好在业内在开发支持平台和实践方法论，前端技术，新业务架构（如用户行为分析，大数据处理，消息处理，微服务架构等），外围系统（支付、物流、交互等），主数据服务，内部系统服务接口改造，等等领域已经有了相当积累和成熟的解决方案。只要领导层把握时机，掌控大局，投下资本，各部门敏捷合作，加快战略部署，提高采购、招人的速度，一两年内，传统IT转型成“又稳又快”的双模IT是乐观可期的。
又稳又快地交付IT产品，就如快速交付有质量保证的轿车一样，不进行精益生产是不行的。冲压、焊接、油漆、总装，（开发、测试、部署、运维）；设备和人员的先进性、流程的标准化和执行的自动化是速度和质量的保证。
- 加大从左到右的工作流的流量，将需求分级过滤，迭代实现，通过自动化的构建、集成和部署，建立一致的开发、测试、预发和生产环境，实现自动化的测试（需求、代码、功能、安全、非功能），及早发现和隔离缺陷，不让缺陷和不必要的需求注入生产线。（让每个车间流出的半成品都是基本符合质量要求的）
- 加大从右向左的反馈流的流量，突破各个车间各个工序之间的壁垒，建立共同目标和共同解决机制，加强对已交付产品的业务和运行监控，及时向左侧反馈。（当交付产品有质量缺陷或者安全问题的时候，统一行动，迅速解决）
- 创造勇于创新和高信任度的团队文化，不断尝试，重复训练。使得正向流和反向流运行顺畅
由此可见，又快又稳地交付产品，实现精益生产，当务之急，就必须像汽车生产线建设一样，加大软件制造流水线整体建设和各个点的自身建设，提高技术水平和自动化程度；同时紧紧抓住用户和客户的核心需求，以提高系统的用户满意度。有效开展IT内部项目建设，提高业务功能的上线速度和上线率、变更的成功率，减少因不恰当需求和无序的变更而导致的计划外工作和救火行动。