浅析数字化转型

1、大佬都在说数字化转型，但你真正理解什么是数字化吗?充分理解数字化，明确数字化是什么以及不是什么，明确数字化转型成功的标准是什么，对于一个技术领导者来说非常重要。我刚刚采访完一位架构师。采访中我问了一个自己最喜欢的问题：“数字化转型到底有什么意义？” 类似的问题我们也经常听到， 人们本应该 对“数字化”这个概念理解得更充分，但实际上并非如此。在大量不同情景下把这个问题问过多遍后，我可以很确信地说，大家对这个概念还没有达成统一共识。 实际上很多时候大家被问及这个问题后， 更多的表现是困惑或盲目的恐慌。对于抛出这样一个棘手的问题，我感觉有些愧疚。同时我也觉得，如果 没有经过彻底的深思熟虑，自己被问到

2、这个问题后一样会感受到相同的 恐慌。有时候，无法清晰表达出数字化转型的真实含义，并不一定说明 对方真的没想过这个问题。充分理解数字化，明确数字化是什么以及不是什么，对于一个架构师来 说非常重要。毕竟我们需要向董事长、 CEO、CTO、分析师、开发者， 以及其他所有相关人员解释这些概念。 同样重要的是明确数字化转型成 功的标准是什么。而充分理解数字化转型的具体定义， 理解数字化这个 概念本身，至少可以确定出正确的方向。那么如何才能正确“数字化转型” ？组织如何能实现数字化转型并从中 获益？本次采访对这些问题提供了很棒的答案。先来看看字典上对于“数字化”是这么说的吧。形容词：数字化.以一系列数字0

3、和1的形式呈现（的信号或数据），通常由电压或磁性 极化强度等物理量的值所代表。.以数字信号的方式关联、使用，或存储数据或信息。.需要或涉及计算机技术的使用。最后一条解释很有趣对吧！或大或小不同规模的组织使用“计算机技术” 已有数十年的历史，如果这就是“数字化”的含义，那么现在的组织为 何还要花费大量时间和精力进行数字化转型？很多东西字典是无法给 出足够解释的。我在2016年对“数字化”的定义“数字化转型”实际上就是对业务过程进行的重塑，通过重塑使其默认 就更加适应更全面的在线环境， 从最终用户的接触到后端的办公室工作， 全面实现无需人工介入的过程自动化。为何要数字化转型任何组织都应该首先问问自

4、己这个问题。 通往数字化的道路并不是免费 的需要大量投入，因此出钱的人必须能全面理解数字化所能带来的收益。投资回报这种东西非常难以计算，并且只能针对每家公司的具体情况分别进行衡量。原因可以列出很多条，然而最终还是要由你自己来 归纳，并汇总成一点：如果不进行数字化转型，业务就完蛋了。如果不 能认真对待数字化，就会被竞争对手超越然后业务一样会完蛋。Blockbusters 的故事你总听说过吧！（译注：Blockbusters 是一家线下的VHS录象带和DVD影碟租赁连锁店，2004年全盛时期有6万员 工和8千家店，客户横跨全北美。Netflix曾主动提出被并购但被拒。Blockbusters 已于

5、2010年破产，Netflix如日中天。）数字化到底是什么.客户为先的文化。你的客户是谁？他们是你数字化服务的用户。那么为 什么把他们称作“客户”而非“用户”？长久以来我们都坚持“客户始 终是对的”这样的心态，如果将自己的用户视作客户，无论对方是否为 服务付费，那么我们就会尽一切努力吸引他们，维系他们，取悦他们。为了数字化转型，必须打造可以满足客户需求的企业文化， 可以另客户 获益的功能，可以快速改变客户或帮助客户降低成本的服务。 无论做什 么，必须将客户放在首位。*即时反馈？。在数字化世界中，客户都期待着自己的请求能够立刻获得反馈。客户不会再等待几分钟、几小时甚至数天，仅仅为了知道自己的 请

6、求是成功或失败。数字化世界的响应时间已经开始用毫秒作为单位来衡量。.实时？。数字化系统应该能全天候接受请求，应该能按需可用，应该能 使用/返回最新数据。最终一致性是一种行之有效的架构方法，但应该 按照网络和自动化处理延迟，而非业务过程延迟进行衡量。.自动化？。听起来很明显，数字化服务应该包含尽可能多的计算机处理过程（最理想状况是100%由计算机处理），需要的人工介入越少越好。.智能？。繁琐的工作都应交给数字化服务处理，将客户或其他方面人员需要付诸的精力和所需的理解减至最低。这里说的“智能”是指服务应 当能够帮助客户处理最原始的信息并进行相关运算、汇总、提炼和转换,这一切都无需用户操心。同时这种

7、智能也意味着服务应当能预测客户的 下一步操作，并提前做好准备，提供建议。在线？。数字化系统应该能通过互联网从任何地点访问，不应对设备和使用情况进行任何限制。美观？。美观的界面和构造优美的 API，数字化时代的任何服务都应具 备这样的特征。某种程度来说，美观与否是观察者的主观结论，但也意 味着易用、直观，以及能满足客户的需求。这意味着可以将对客户而言 最重要的内容直接交付到客户面前。-推进改变？。应该是由数字化服务定义业务过程，而非业务过程定义数字化服务。数字化意味着业务过程需要作出改变，以便适应计算的世界，而非反其道行之。绝不能用在线的方式继续沿袭以往离线时代的做法。.定期改进。？你觉得AWS

8、新功能发布的频率如何？我简单统计了一下2016年11月21日到2016年12月5日之间的改动，两周时间，28 次发布！这就是AWS，可能是全球最大规模的数字化平台。大部分客 户对技术并不十分精通，他们并不清楚进行这样的软件改进做起来到底 有多难其实他们也不需要关心这些。他们只是希望能看到改进。数 字化平台应该尽可能以必须的频率完善自己。数字化不是什么*批处理？。在数字化时代，我们不应该继续依赖离线的数据馈送和调度处理。机器之间的通信应该通过 API进行，应通过推送方式在信息可用 的那一刻立即进行。这样可以确保信息始终保持最新状态。手工处理。，数字化过程的默认形态不应包含任何人工介入或处理。任何

9、离线的介入都应视作一种例外，例如无法使用数字化服务，或面对某些任务，机器学习/处理技术还不够成熟。例如欺诈检测，目前依然离 不开人工的介入。-技术刷新？。技术并不能让你数字化转型。步入云端不能帮你数字化转型。使用微服务架构不意味着你已经数字化转型了。使用NoSQL也不意味着数字化。如果你看到某家组织通过强调自己的技术成果表达对数 字化转型进程的支持，那么也许可以假设他们的数字化之路选错方向了。助力转型云。一上一节内容已经明确提出：技术本身并不是数字化的目标，本节 将开始（并持续不断地）介绍为什么技术的恰当选择可以帮你顺利实现 数字化转型。众所周知，云计算可以帮助用户获得数字化服务所需的缩 放性

10、，以及性能和规模。云计算的背后是一套复杂的分布式系统，但可 以良好配合帮你确定最正确的方向。持续集成/持续交付？。从我在1999年开始程序员的职业生涯以来， CI/CD也许是软件开发领域最大的收获之一。当时团队和团队成员需要分别编写代码，很少进行合并，最终上线前需要多天忙碌的工作，通过 繁琐的操作将大家的代码合并到一起。 然后他们悲剧地发现代码无法集 成并配合工作。（实际上我作为开发者参与的第一个项目甚至没有使用 VCS，但这又是另一个故事了）。 CI/CD，配合定期进行（通常至少每 天一次）的提交和小型（如果需要的话）合并，有助于快速安全地开发 出高质量代码。团队将能有更多时间专注于开发客户

11、真正需要的数字化 功能。敏捷？。作为一种方法论，也许并不完美。但该方法的基本原则与数字化观念相当匹配，可以促进以客户需求为基础的定期交付。不以敏捷为核心的数字化程序必须付诸更多努力才能满足转型的需求。如果敏捷方法论不可行，至少一切行事需要首先考虑到敏捷的基本原则。以人员而非资源为中心，即时（Just in time ）设计，不断演化的架构。无论选 择哪种方法论，这些基本原则都是适用的。.用户研究？。虽然最近才开始研究这一点，但对这方面有很多第一手体验，同时与很多非常天才和娴熟的专家有过合作，他们向我证明了只要做得对，用户研究将成为数字化服务的核心，甚至远比代码、架构、方 法论更重要。用户研究可

12、以引导你实现数字化涅槃。为什么？因为如果“用户”觉得更易用，你的服务就会更可用，被更多人所使用最终 你也会更加成功。这里用了“用户研究”而非“客户研究”这个词，因 为业界就是这样称呼的。简化设计？。作为架构师，我经常会拥护一件事：我们的设计要尽可能 简洁。若非必要，不要让设计变得更复杂。不要试图去解决那种绝对不 会自行显露出来的问题。网上有很多文章解释了原因， 但从数字化的角 度来说，简单的设计可以让每个人更加关注手头的事情，进而改善客户 体验。复杂的设计意味着需要更多维护，可能出错的东西变得更多，用 于确保服务正常运转所花费的时间远多于改善数字化体验所用的时间。是时候数字化转型了组织迈向数字

13、化世界的旅途充满了挑战和艰辛，甚至可能存在不小的争议。在这段旅途中，肯定需要面对针对各种收益所提出的质疑，实际上 你可能一开始也有不少疑问。心态从非数字化到数字化的转变可能是其 中最难的部分。任何能够屹立不倒的组织都有多年来一起同舟共济的核 心员工，这些员工很了解业务，对企业很忠诚，正是这些员工树立了组 织的文化和观念。然而这些员工面对变动也是最不容易动摇的，需要说 服他们相信客户不是组织内部的“业务”，而是组织所提供服务的用户。他们需要习惯于每周定期发布，甚至每日发布。他们需要理解，以往的 业务过程是针对巨型机的世界，而非针对互联网或智能手机创建的。那 个世界中的所有查询都是通过代理程序（

14、Age nt ），而非设备进行的。 这样做并非因为他们缺乏智能和能力，而是因为已经获得成功，现在希望实现数字化的组织，恰恰都是曾经以某种特定方式成功过的组织，因 此他们可能会问：为何还要改变？此外还会遇到技术挑战。运行诸如云端微服务RestFul架构这样的分布 式系统当然能获得不菲的收益，但还会在延迟、数据一致性、无状态， 以及下游服务失败等方面遇到挑战。你的组织中肯定还在使用一些必不可少的遗留系统，这些系统从开发时就没有考虑过大容量低延迟事务。 你的数字化战略中考虑过如何替换这类系统吗？如果考虑过，又打算如何进行切换或将数据从老系统迁移到新系统中（想想Strangler模式吧） 但这个过程代

15、价不菲，因此如果不打算替换，遗留的平台又如何融入你的数字化愿景？也许数字化平台已经全面做到了实时低延迟运转，但你依然在使用古老的记录系统。在考虑对数字化转型进行投资时，CEO、CIO，或其他CXO需要抓住机会将组织所获得的成功下沉到员工身上。让产品负责人的所有工作都 以客户为中心，并要跳出定势进行创造性思维。理解这些信条重要性的 技术和软件架构师，同时也要更深入地意识到这些信条会受到业务和客 户目标，而非其他因素的驱使。开发者不能将高质量代码视作一种负担， 而是应该视作创作和创新方面的自由。测试驱动的开发（TDD ）可以提 供最无拘无束的Bug修复和支持。同时业务分析师需要能够将需求解 释为数

16、字化过程，而不是反其道而行解释为离线的过程。数字化转型，这本就不易，但只要具备恰当的人员和耐心，所有在时间 和精力方面的投入都会获得回报。待到老去的那一日，偶尔有回忆念及了过往，依旧还会有初初的心动，流转了眉眼。而那一路迤逦而来的美好，一步一步写就两个梅花小楷一一日常。暖阳小窗，无事此静坐。杯盏光阴，又在指间如风轻过，回首，依稀还是那年秋，低低一低眉，却已是春光葳蕤。光阴荏苒，而流年从来也不曾缺少错乱和犹疑。是否在这样一个万物复苏的季节里，一切的纷扰是非，终究会给出一个水落石出的答案。轻倚初春的门楣，且把盏清风，问心明月，让来者可来，去者可去，宿命里的拥有，一一欣喜悦纳。而我也只需以花香绕肩的美，步履从容的，走过生命里的山山水水。若说，那一程走旧的时光，已然温暖了我的眉眼。那么，在明日那个花满枝桠的清晨