文档介绍：: .
期待着自己的请求能够立刻
获得反馈。客户不会再等待几分钟、几小时甚至数天，仅仅为了
知道自己的请求是成功或失败。数字化世界的响应时间已经开始
用毫秒作为单位来衡量。
5• 实时。数字化系统应该能全天候接受请求，应该能按需可用，应
该能使用／返回最新数据。最终一致性是一种行之有效的架构方
法，但应该按照网络和自动化处理延迟，而非业务过程延迟进行
衡量。
• 自动化。听起来很明显，数字化服务应该包含尽可能多的计算机
处理过程（最理想状况是 100%由计算机处理），需要的人工介
入越少越好。
• 智能。繁琐的工作都应交给数字化服务处理，将客户或其他方面
人员需要付诸的精力和所需的理解减至最低。这里说的“智能”
是指服务应当能够帮助客户处理最原始的信息并进行相关运算、
汇总、提炼和转换，这一切都无需用户操心。同时这种智能也意
味着服务应当能预测客户的下一步操作，并提前做好准备，提供
建议。
• 在线。数字化系统应该能通过互联网从任何地点访问，不应对设
备和使用情况进行任何限制。
• 美观。美观的界面和构造优美的 API，数字化时代的任何服务都
应具备这样的特征。某种程度来说，美观与否是观察者的主观结
论，但也意味着易用、直观，以及能满足客户的需求。这意味着
可以将对客户而言最重要的内容直接交付到客户面前。
6• 推进改变。应该是由数字化服务定义业务过程，而非业务过程定
义数字化服务。数字化意味着业务过程需要作出改变，以便适应
计算的世界，而非反其道行之。绝不能用在线的方式继续沿袭以
往离线时代的做法。
• 定期改进。你觉得 AWS 新功能发布的频率如何？我简单统计了
一下 2016 年 11 月 21 日到 2016 年 12 月 5 日之间的改动，两
周时间，28 次发布！这就是AWS，可能是全球最大规模的数字
化平台。大部分客户对技术并不十分精通，他们并不清楚进行这
样的软件改进做起来到底有多难……其实他们也不需要关心这
些。他们只是希望能看到改进。数字化平台应该尽可能以必须的
频率完善自己。
数字化不是什么
• 批处理。在数字化时代，我们不应该继续依赖离线的数据馈送和
调度处理。机器之间的通信应该通过API 进行，应通过推送方式
在信息可用的那一刻立即进行。这样可以确保信息始终保持最新
状态。
• 手工处理。，数字化过程的默认形态不应包含任何人工介入或处
理。任何离线的介入都应视作一种例外，例如无法使用数字化服
务，或面对某些任务，机器学****处理技术还不够成熟。例如欺
诈检测，目前依然离不开人工的介入。
7• 技术刷新。技术并不能让你数字化转型。步入云端不能帮你数字
化转型。使用微服务架构不意味着你已经数字化转型了。使用
NoSQL 也不意味着数字化。如果你看到某家组织通过强调自己
的技术成果表达对数字化转型进程的支持，那么也许可以假设他
们的数字化之路选错方向了。
助力转型
• 云。—上一节内容已经明确提出：技术本身并不是数字化的目标，
本节将开始（并持续不断地）介绍为什么技术的恰当选择可以帮
你顺利实现数字化转型。众所周知，云计算可以帮助用户获得数
字化服务所需的缩放性，以及性能和规模。云计算的背后是一套
复杂的分布式系统，但可以良好配合帮你确定最正确的方向。
• 持续集成／持续交付。从我在1999 年开始程序员的职业生涯以
来，CI/CD 也许是软件开发