浅析数字化转型.docx

文档介绍：大佬都在说数字化转型，但你真正理解什么是数字化吗？
充分理解数字化，明确数字化是什么以及不是什么，明确数字化转型成功的标准是什么，对于一个技术领导者来说非常重要。
我刚刚采访完一位架构师。采访中我问了一个自己最喜欢的问题：“数字化转型到是由数字化效劳定义业务过程，而非业务过程定义数字化效劳。数字化意味着业务过程需要作出改变，以便适应计算的世界，而非反其道行之。绝不能用在线的方式继续沿袭以往离线时代的做法。
定期改良。 你觉得AWS新功能发布的频率如何？我简单统计了一下2022年11月21日到2022年12月5日之间的改动，两周时间，28次发布！这就是AWS，可能是全球最大规模的数字化平台。大局部客户对技术并不十分精通，他们并不清楚进行这样的软件改良做起来到底有多难……其实他们也不需要关心这些。他们只是希望能看到改良。数字化平台应该尽可能以必须的频率完善自己。
数字化不是什么
批处理 。在数字化时代，我们不应该继续依赖离线的数据馈送和调度处理。机器之间的通信应该通过API进行，应通过推送方式在信息可用的那一刻立即进行。这样可以确保信息始终保持最新状态。
手工处理。，数字化过程的默认形态不应包含任何人工介入或处理。任何离线的介入都应视作一种例外，例如无法使用数字化效劳，或面对某些任务，机器学习／处理技术还不够成熟。例如欺诈检测，目前依然离不开人工的介入。
技术刷新 。技术并不能让你数字化转型。步入云端不能帮你数字化转型。使用微效劳架构不意味着你已经数字化转型了。使用NoSQL也不意味着数字化。如果你看到某家组织通过强调自己的技术成果表达对数字化转型进程的支持，那么也许可以假设他们的数字化之路选错方向了。
助力转型
云。—上一节内容已经明确提出：技术本身并不是数字化的目标，本节将开始〔并持续不断地〕介绍为什么技术的恰中选择可以帮你顺利实现数字化转型。众所周知，云计算可以帮助用户获得数字化效劳所需的缩放性，以及性能和规模。云计算的背后是一套复杂的分布式系统，但可以良好配合帮你确定最正确的方向。
持续集成／持续交付 。从我在1999年开始程序员的职业生涯以来，CI/CD也许是软件开发领域最大的收获之一。当时团队和团队成员需要分别编写代码，很少进行合并，最终上线前需要多天忙碌的工作，通过繁琐的操作将大家的代码合并到一起。然后他们悲剧地发现代码无法集成并配合工作。〔实际上我作为开发者参与的第一个工程甚至没有使用VCS，但这又是另一个故事了〕。CI/CD，配合定期进行〔通常至少每天一次〕的提交和小型〔如果需要的话〕合并，有助于快速平安地开发出高质量代码。团队将能有更多时间专注于开发客户真正需要的数字化功能。
敏捷 。作为一种方法论，也许并不完美。但该方法的根本原那么与数字化观念相当匹配，可以促进以客户需求为根底的定期交付。不以敏捷为核心的数字化程序必须付诸更多努力才能满足转型的需求。如果敏捷方法论不可行，至少一切行事需要首先考虑到敏捷的根本原那么。以人员而非资源为中心，即时〔Just in time〕设计，不断演化的架构。无论选择哪种方法论，这些根本原那么都是适用的。
用户研究 。虽然最近才开始研究这一点，但对这方面有很多第一手体验，同时与很多非常天才和娴熟的专家有过合作，他们向我证明了只要做得对，用户研究将成为数字化效劳的核心，甚至远比代码