作者：ThoughtWorks中国
出版社：浙江出版集团数字传媒有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
ThoughtWorks数字平台战略——构建数字平台 助力企业创新试读：
什么是数字平台战略？
传统企业正在面临IT新技术的挑战——单从“传统企业”这个居高临下的称谓，你就能读出“非传统企业”（也就是IT企业、互联网企业）满满的优越感。每天在各种新媒体平台上看着BAT们又掌握了什么黑科技、又颠覆了哪个行业，“云大物移”已经成了高频出现的热词，传统企业们愈发清晰地感受到IT的重要性与挑战。数字化浪潮躲不过，和BAT拼技术又拼不过，传统企业的出路在哪里？（图片来自网络）
目光投向大洋彼岸，最传统的传统企业、年收入数千亿美元的沃尔玛在过去几年中的数字化历程颇有可玩味之处。直到2011年，沃尔玛还不是出色的数字化玩家，只能算一个有电商网站的线下零售商而已。正因为如此，当沃尔玛的电商收入在2011年至2014年的三年间增长150%、从年销量49亿美元增长到122亿美元、超过史泰博（Staples）成为亚马逊和苹果之后的美国第三大在线零售商时，这一变化才更令人惊叹。像沃尔玛一样的数字化转型先行者，能给我们带来哪些启示？
数字化企业的三个关键字
首先，传统企业们需要清楚一件事：“传统”不应该是贬义词，它同时意味着数十年积累的宝贵资产，包括客户关系、数据、品牌形象、供应链、渠道等等。传统企业要在互联网时代的竞争环境中占得一席之地，靠的不是突破最高精尖的技术领域，而是以数字化的形式激活自己多年累积的核心资产，将核心资产转变为可以在互联网上使用的服务，使其焕发新的价值。
对众多成功的数字化企业进行的调研显示，这些企业有着一些引人注目的共性。在“激活核心资产”的过程中，他们对三个关键字的重视特别值得我们关注：IT效能、生态系统、创新实验。
首先，这些成功的数字化企业重视提升IT团队的效能。正如ThoughtWorks在第16期技术雷达中所指出的，技术人员的工作体验正在成为科技企业的差异化竞争优势。这里所说的“体验”不止是给程序员舒适的座椅和人体工学键盘，更重要的是消除IT团队在工作中遇到的阻力和摩擦，尤其是充分利用云计算的弹性能力大量简化和自动化与实现业务功能无关的基础设施性工作，让IT团队将注意力集中在真正与业务相关的工作上。这里涉及的一些技术和实践（例如技术栈管理）乍听起来可能困难重重，但为提升IT团队效能付出的成本终将物有所值。
随后，这些成功的数字化企业把他们的核心商业能力与资产以服务的形式在互联网上提供出来，构建本行业的数字化生态系统，使新的服务和产品能够在这些服务的基础上被创造出来。同样是在技术雷达中，我们看到了“平台的崛起”：几年前只有亚马逊这样的巨头企业能在互联网上提供各种云服务；而现在有更多原本不太有“互联网基因”的企业围绕自己的核心资产建立起了数字化平台，不仅对内、而且对外提供服务。在国内，我们看到华为把软件开发能力变成了云服务、海航建立了自己的云生态。我们相信，更多的企业也能从核心资产的服务化中受益良多。
最后但绝非最不重要的，这些成功的数字化企业养成了创新实验的习惯。在互联网中弄潮的经验让他们承认，自己不能预先掌握所有需求、做好所有设计。因此他们转而打造组织的响应力，致力于缩短精益创业的“构建-度量-学习”周期。他们知道成千上万的用户不会明明白白地说自己想要什么功能，于是他们监控用户行为、用A/B测试等方法进行受控实验，用“假说-实验”代替了“需求-实现”，在不断的反馈中完善自己的产品和服务。
数字平台战略的五大支柱
以提升IT效能、构建行业生态、促进业务创新为目标，有志于迈出数字化步伐的企业应该立即开始制订自己的数字平台战略蓝图。不要被“平台”和“战略”这样的大词欺骗：这个以增强企业响应力为目标的平台战略不应该是在漫长的规划之后建设出一个庞然大物，而应该是迭代的、精益的、价值驱动的。更多的时候，我们谈论的“数字平台”更像是一系列IT技术与实践的落地结合。这些技术与实践有机构成的五个支柱，让数字化的企业能快速交付IT系统、围绕核心资产构建云上生态系统、从线上系统和用户行为中获得洞察、开展受控实验、并为顾客创造全渠道统一的用户体验。在成功的数字化转型案例（例如沃尔玛的案例）中，我们就能看到这五个支柱的投影。
第一个支柱是支持云和敏捷的交付基础设施。为了让IT团队快速交付，他们使用的基础设施应该具有弹性，开发、测试、运维等不同角色应该可以随需动态获得完整的应用环境，从而统一环境、标准化研发实践、规范化研发能力。他们开发的应用程序应该用持续交付实践打通开发、构建、验证和部署流程，使软件随时处于可发布状态。他们的交付流程中应该内建对安全的考量，而不是依赖最后的整体安全检查。生产系统所使用的运行时环境应该前向拉通到验证和研发环节，保障运行时环境的一致性。需要对系统的IT运维和业务运营进行全面的监控，聚合起来了解系统整体状况。
第二个支柱是以微服务为核心的API和架构治理。为了鼓励不仅企业内、还包括企业外的开发者在平台上发挥创造力，平台架构和API的设计应该注重开发者体验。在API的背后，应该从业务功能的角度出发划分合理的限界上下文和服务边界，对外提供高内聚低耦合的服务。在服务边界之间，应该考虑使用异步的事件机制实现服务之间的通信，来客观地描述运行时间比较长、甚至本质上不可能立即完成的操作（例如涉及人工操作）。为了方便使用者，应该提供API网关作为所有服务使用者的单一入口点，在API网关背后去处理众多内部IT系统的复杂性。整个API架构应该以微服务的风格呈现，避免典型SOA架构中普遍存在的、过于复杂的ESB编排逻辑。
第三个支柱是允许开发团队数据自服务。为了让业务和研发团队获得关于生产环境、关于线上业务、关于顾客的洞见，他们需要首先定义数据流水线，使数据能够顺畅地流过收集、转换、存储、探索/预测、可视化等阶段，产生业务价值。他们需要用实时的架构和API在短时间内处理大量、非结构化的数据，从中获得洞见，并“实时”影响决策。为了提高应变能力，系统中的数据不做ETL预处理，而是以“生数据”的形式首先存入数据湖，等有了具体的问题要回答时，再去组织和筛选数据，从中找出答案。IT团队会更进一步把数据包装成能供外人使用的产品，让第三方从数据中获得新的洞见与价值。为了支持数据产品的运营，他们需要实现细粒度的身份认证，针对不同的用户身份，授权访问不同范围的数据。
第四个支柱是创新实验基础设施和监控体系。为了让创新真正基于数据（而非拍脑袋）来开展，IT团队需要从多种来源采集关于系统、关于顾客的数据。需要根据业务目标在系统中埋设监控点，并及时把监控结果可视化呈现给业务用户。为了降低实验试错的风险，在把新版本发布给全部用户之前，应该以“金丝雀发布”的形式首先发布给一小部分用户，确保新版本不造成重大损害。系统需要支持功能切换开关（toggle），允许团队在不修改代码的前提下改变系统的行为，再加上用路由技术支持蓝-绿部署和A/B测试，方可高效地开展受控实验。
第五个支柱是支持全渠道的用户触点技术。为了通过多样化的触点技术向顾客提供随时随地、连贯一致的用户体验，整个企业需要建立对其顾客和目标顾客的唯一、连贯、准确、整体的视图，从而更好地了解和服务顾客。他们需要结合顾客的特征和不同数字渠道的特征建立连贯的内容策略，在多种渠道（例如电脑、智能手机、门店等）之间引导顾客的消费旅程，与顾客产生正确时间、正确地点、正确方式的交互。基于从各种渠道获得的顾客本人及其行为的数据分析，他们可以向顾客提供定制化的内容、服务和产品推荐。作为必要的技术保障，所有数字渠道的软件应用（尤其是原生的Android和iOS应用）都应该实践持续交付，这样才能实现全渠道的快速响应。
小结
在数字化的浪潮面前，传统企业不必恐惧于互联网企业的技术优势。只要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱，逐步建设自己的数字平台，不断提升IT效能、构建本行业的数字化生态系统、养成创新实验的习惯，传统企业同样可以用数字技术激活自己多年积累的核心资产，在新的竞争环境中找到自己的一席之地。（更多关于数字平台战略的信息，请关注ThoughtWorks数字平台战略网站。）
第一支柱：数字化企业的交付基础设施
传统企业在逐步建设自己的数字平台过程中，需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。那么，当我们谈“交付基础设施”时，我们究竟在谈什么？怎样的交付基础设施能加速数字化项目的交付？
什么是交付基础设施
云时代的研发环境应该以原生支持云计算的方式来提供、管理和维护。在提供基础的弹性计算能力的IaaS平台之上，交付基础设施负责为交付团队提供便利的、最好是自助式的工作环境，让交付团队专注于交付软件的功能性需求，而不必操心软件功能之外的“脚手架”工作。按照ThoughtWorks数字平台战略的定义，这些脚手架包括：
●弹性基础设施：即交付团队使用底层云计算平台的方式，既包括各种虚拟机和镜像的管理，也包括生产环境的水平伸缩能力。
●持续交付流水线：交付团队编写的代码需要通过这条流水线最终变成可以上线运行的软件。
●部署运行时：软件在开发、测试、试运行、用户验收、培训、生产等各种环境需要部署的环境。
●监控：为交付团队提供生产环境（及其他环境）的可观测性，方便他们发现和解决问题。
●安全：把安全内建在软件的研发过程中，尽量避免因为人为失误造成安全隐患。
从前这些交付基础设施脚手架通常是由每个交付团队的技术领导者（Tech Lead）来负责搭建和维护的。并且由于软硬件资源的稀缺和不灵活，团队经常需要微调自己的实践来适应不同的环境。所以，即使在同一家公司，各支团队所使用的交付基础设施也可能大相径庭。交付基础设施不一致、不规范的情况会迫使团队花费额外的精力去操心脚手架工作，并且使最佳实践不易推广普及。走上数字化道路的企业必定有大量的软件项目，尤其是微服务架构风格的引入会使企业拥有数量更多、单体规模更小的软件应用，此时交付基础设施不一致、不规范的情况就会给企业的数字化进程带来更大的阻力。
云计算带来的弹性和灵活性让组织级的交付基础设施标准化、规范化成为可能。一个跨越项目团队的、组织级的交付基础设施团队现在可以在IaaS的基础上封装标准的脚手架，甚至把脚手架本身以PaaS的形式提供给交付团队。通过把整个企业优秀技术领导者的知识与经验内嵌在交付基础设施脚手架中，就降低了对单个交付团队的技术要求，帮助企业缓解优秀技术领导者难以获得的人才挑战。从这个意义上，以PaaS形式提供的交付基础设施本质上是技术领导者作为服务（Tech Lead as a Service）的云计算应用形式，它解决的是优秀技术人才的弹性和灵活性问题，让企业能够以一种创新的方式使用这些人才。架构师写代码吗？
关于“架构师是否应该写代码”这个问题，业界有各种不同的声音。在敏捷的社区里，意见倾向于认为架构师需要写代码，因为这是他们获得关于技术决策的反馈和建立技术领导力的重要方式。将交付基础设施明确提出来，就给了架构师又一个清晰的编程目标——他们需要用代码的形式描述软件交付中的基础设施和最佳实践。除了培训、开会、代码评审等我们已经知道效率并不太高的方式以外，架构师对交付团队的指导和监管现在可以用实实在在的代码来承载。当交付团队不理解架构师说的某件事应该怎么做，现在他们更有理由要求架构师“show me the code”。
交付基础设施解读
下面我们来看看，在“交付基础设施”这顶帽子下面，架构师/技术领导者们究竟应该关心哪些问题，又有哪些最佳实践应该被纳入他们的视线。弹性基础设施
允许交付随需获得计算能力。在微服务语境下，这种弹性有两层常见的含义：在生产环境下，服务可以随负载动态获得和释放计算资源，从而更高效地使用计算资源，更自动化地应对负载变化；在研发环境下，开发、测试、运维等不同角色可以随需动态获得完整的环境，从而统一环境、标准化研发实践、规范化研发能力，并且给研发提供体验更好的开发环境。
为了实现弹性基础设施，一方面基础设施需要支持弹性，例如使用支持弹性计算的公有/私有云，并且有对生产环境的监控和自动化手段；另一方面应用本身需要有可扩展性，例如服务能分别独立部署、无状态化、容器化、有透明的前端负载均衡机制。有状态服务（比如数据库服务）的弹性伸缩问题是特别需要考虑的重要挑战。持续交付流水线
用持续交付实践打通微服务的开发、构建、验证和部署流程。在数字化、服务化的背景下，众多互相依赖的微服务形成的系统架构，对构建、验证和部署造成更大的压力：各个服务有独立的代码库和构建流程，又需要随时能组合成可用的软件；构建产物需要有统一的存储管理；完整的运行时环境应该能按需获得；配置和部署应该能快速准确地完成。
为了应对这些挑战，交付基础设施中应该包含完整的持续交付概念：流水线、环境管理、构建产物管理等。应该鼓励对服务虚拟化，最好是每个主机运行一个微服务，而不共享使用主机。应该包含配置自动化工具，例如Chef、Puppet等。在服务化的背景下，持续交付流水线需要体现服务间的依赖关系和团队间的协作关系，设计一个运转良好的流水线不是容易的任务。部署运行时
交付基础设施应该包含生产系统所使用的运行时环境，并把生产环境前向拉通到验证和研发环节。为了在研发流程的出口得到服务化友好的交付物，最好是在整个开发过程中一直使用与生产环境近似的环境。例如开发人员应该使用全套环境随时验证，自动化测试和手工测试都基于全套环境开展。在这种情况下，环境的设置、管理、更新不可能由每个开发人员和测试人员自己进行，所以环境的管理更新必定是集中进行的，环境的设置必定是自动化的。
在《技术栈管理：云时代的研发环境》一文中，我们已经介绍过“一个平台、两个PaaS服务、三个运行时环境”的技术栈管理理念。特别需要注意的是，如何将生产数据拉通到验证和研发环节。监控
在微服务架构中，系统由多个小服务组成，且广泛使用异步通信，使问题和故障更难定位。因此交付基础设施需要提供全面可靠的监控机制，帮助交付团队了解系统的整体状况。
监控的实现涉及日志、服务指标跟踪、业务语义综合监控等方式。在云环境下如何划分和管理监控的层级，监控系统如何无侵入的在各个微服务体系中收集故障和信息，如何有效管理监控的反馈环，如何在前后端分离和移动应用情况下收集和监控客户端日志，都是常见的挑战。安全
当数字化、服务化IT系统的数量剧增，安全的设置会变得更加复杂。在微服务架构下，系统的安全性需要有一个整体的考虑。例如单点登录、服务间的身份验证和授权、各种防御措施等安全考量不应该下放到交付团队，而应该被涵盖在交付基础设施中统一提供、统一管理、统一更新。
交付基础设施还应该鼓励安全实践内建（Build Security In），例如团队应该熟悉OWASP安全列表和测试框架、需求分析中应该包含安全需求和恶意用户需求、测试过程中应该包含安全性测试、应该进行自动化安全性测试并纳入持续交付流水线。这些流程与工作方法虽然不能完全以软件代码的形式承载，但它们同样是交付基础设施的重要组成部分。
小结
数字化、服务化的IT大背景会让企业开发和拥有的IT系统数量剧增。当企业IT交付更多地以“两个pizza团队”的形式组织，依赖于每个交付团队的技术领导者来搭建和维护一套完整高效的交付基础设施脚手架，这种期望即使不是完全不现实，也会对企业的人才积累提出非常高的要求。因此，企业应该集中优秀的技术人才（包括架构师们），打造一套标准的交付基础设施，充分考虑生产环境与研发环境的弹性、持续交付、部署运行时的统一、监控、安全等因素，并借助云计算的弹性和灵活性将其提供给交付团队。用便利的脚手架赋能一支能快速交付的团队，这是企业的数字化旅程的第一步。第二支柱：数字化企业的API架构治理企业资源服务化
从1990年代起，企业资源计划（ERP）一直是企业信息化的核心议题。植根于供应链管理，ERP通过对企业内部财务会计、制造、进销存等信息流的整合，提升企业的计划能力与控制能力。然而近年来，在互联网的冲击下，传统企业开始面临全新的挑战。尤其是在互联网的去中介化效应影响下，原本在供应链上下游各安其位的企业突然间都被压缩到了“生产-流通-消费”这个极度精简的价值链中。药品购销两票制就是这个极简价值模型的直观呈现。在这个模型中，掌握技术优势和消费者入口的互联网企业有可能形成一家独大的超级垄断，挤死传统的流通企业，把生产企业变成自己的OEM厂商，这是传统企业对来自互联网竞争者恐惧的根源。
为了对抗互联网企业的竞争，传统企业最好的办法不是硬拼互联网上的技术和流量，而是在自己擅长的领域开战：把自己多年积累的线下资源变成线上服务，构建起本行业的线上生态系统，不仅支撑本企业的线上经营，而且为上下游周边企业提供线上经营的平台，从而把线下优势转化为线上优势，以资源优势对抗技术优势。
为了支撑企业资源的服务化，在设计在线服务的API和架构时需要考虑以下问题：
●平台架构和API的设计应该注重开发者体验。
●在API的背后，应该从业务功能的角度出发划分合理的限界上下文和服务边界，对外提供高内聚低耦合的服务。
●在服务边界之间，应该考虑使用异步的事件机制实现服务之间的通信，来解耦领域模型，客观地描述运行时间比较长、甚至本质上不可能立即完成的操作。
●为了方便使用，应该提供API网关作为所有服务使用者的单一入口，在API网关背后去处理众多内部IT系统的复杂性。
●整个API架构应该以微服务的风格呈现，避免典型SOA架构中普遍存在的过于复杂的ESB编排逻辑。ERP之后是什么？
进入2010年代以来，“后ERP时代”这个说法不断被提出。在谈到ERP的发展方向时，通常都会涉及业务与技术两个角度。例如一种观点认为，ERP需要从以流程为中心转变为以客户为中心，并且需要用好云计算、社交网络、大数据和移动化等新技术。
ThoughtWorks认为，ERP在互联网时代的发展方向将是企业资源服务化（Enterprise Resource Servicification，ERS），通过数字平台的技术能力，把一家企业的资源融入一个行业的互联网生态，为企业铺下明确的数字化道路。API和架构治理解
下面我们来近距离看看，在“API和架构治理”这顶帽子下面，有哪些具体的问题需要被考虑到。开发者体验
当企业资源以服务的形式对外提供，也就意味着不可能——像传统的IT系统建设那样——强迫别人使用这些服务。尤其是要把这些服务提供给第三方开发者、希望他们开发出形形色色的应用程序，那么服务的API是否易用就会很大程度上影响它能吸引到多少第三方开发者。ThoughtWorks第16期技术雷达还专门把开发者体验作为一个重要的技术主题。
试读结束[说明：试读内容隐藏了图片]