圆桌会议：云世界的企业架构角色_云计算_Richard Seroter

ArchSummit全球架构师峰会门票9折倒计时中~ 了解详情 



 写点什么

关键点

企业架构和 IT 架构在许多组织内部是同义词。

EA 角色对于推动技术和组织变革很关键。

随着组织寻求成为学习型组织，会期望 EA 角色改变，并且改变会成为常态化。

对于架构师而言，维护 / 建立相关的技术能力，具有很高的价值。

企业架构应该把注意力集中在价值和输出结果，而不仅仅是战略目标。

企业架构师依然重要吗？拥有一个本地云端发展模式，不涉及 DevOps 和 SRE 操作方式，是否从根本上改变了我们对于企业架构的认识？InfoQ 想要去理解关于这个话题的更多相关知识。我们邀请了四位架构师，想要弄清楚是否软件云端方式已经改变了他们的思维。参与这次圆桌会议的嘉宾包括：

Brian Chambers，Chick-fil-A 的企业架构师
Kent Weare，TransAlta 的 IT 执行总经理
Ian Sutcliffe，一家欧洲公司的富有经验的企业架构师
Dan Young，英国 EngineerBetter 咨询公司 CEO

InfoQ：目前而言，是否“企业架构”等同于 IT 架构，或者说是否企业架构师依然关注业务本身的设计？今天的企业架构看上去更像什么？

Kent：我认为企业架构等同于 IT 架构。就我的理解，想要做好企业架构，你应该置身于 IT 部门之外。我见了很多专注于 IT 的架构团队。我不是说他们不用创造企业的最大利益，而是指他们的核心职责是支持业务流程对应的 IT 系统，而不仅仅是全身心专注于构建业务流程本身。

我有一种感觉，在组织规模和正在运行的企业架构之间存在关联关系。我曾经在 1000 人到 3000 人之间规模的组织中工作，在这样的组织内部，不存在一个独立于 IT 之外的企业架构团队，虽然这些架构团队也被称为企业架构团队，但是我更多认为他们充当了 IT 或者解决方案的角色。

当今的企业架构领域，在展示自身价值时会有些难度。企业架构很难被衡量，因此团队也在和这些相关事情做着斗争。不幸的是，人们趋向于最终由 EA 角色承担，因为毕竟之前他们做的挺好的。随着业务和技术的实时变化，我担心这类相关的问题会变得越来越难以攻克。做到这一点，除非人们开始根本性地改变，适应新的 IT 服务上线。

Ian:这个问题在业内已经是一个类似于哲学上的、宗教上的争论话题了，但是我想说当前的企业架构确实是 IT 架构的同义词。这是 EA 唯一的原生来源。我想说，一个只关注 IT 的 EA 不是真正在做 EA 的工作。EA 的一个主要价值是能够带来业务和技术架构的结合，并且针对跨两个领域提出和执行优化措施。我很少看到一个企业架构师纯粹投身于设计业务本身，而是看到他们做着业务设计与技术设计相结合的工作。我相信这两个领域的结合，输出的一个整体的价值会大于单一领域的价值。对我而言，一个 EA 在功能和业务架构结合后就迈出了重大的成熟一步，我认为现在越来越多的 EA 团队正在做到这一点。

Brian：整个业务中具有凝聚力的技术战略会比较有价值。这一切都不是偶然发生的，最快的方式往往是在挖坑，限制了商业敏捷发展可能性或者在最糟糕的时候造成巨大的混乱。为了打造这种凝聚力，一群具有把事情做好能力的人需要坐在一起。首先，了解业务及其目标。其次，了解 IT 当前技术能力。第三，了解新兴技术的影响。真正意义上理解它们是怎么工作的。第四，驱动改变。不仅仅是针对技术的改变，也对组织级和战略级改变。不仅仅在 IT 部门，也在业务部门。要做到这一点，需要一个人特别的能力，一个需要能够做到前一分钟和开发人员交流，下一分钟和业务领导交流的人。

在我们的组织内部，这是一个企业架构师的角色定位。我们也会希望构建超越相关业务单元的平台 / 生态系统，让企业能够满怀信心地快速发展。例如自服务数据访问 / 分析策略或者物联网平台。我们提供简单和轻量级使用规则的平台，然后邀请业务部门参与到这样的生态系统。这是由业务目标直接驱动的技术方案，如果正常工作，那么 EA 角色就在业务战略和 IT 战略之间找到了合适的位置。

相比之下，我看到了问题“我们如何把 IT 工作做好”或“我们怎么解决问题”的答案。在我们组织内部，我们已经承担了 IT 架构的大部分责任，例如关于解决方案、工具、流程的选择等等，我们的 DevOps 团队成功率很高。

Dan:我还遇到过 EA 角色置身于企业 IT 或软件开发以外的情况。我曾经为金融服务企业工作，我认为时至今日，EA 仍然认为自己很大程度上是一个看门人角色，即保证所有人都在一定的约束条件下工作，以上的思维源于 EA 这个角色所处的时代是一个指挥和管理的时代，所以在数量庞大的受管制行业进行改变的代价仍然非常高昂并且困难。但是，时代进步到云世界之后，这个概念开始遇到了挑战，也对它们提出了新的要求。今天，对于一个企业架构师的角色要求是领导改变，专注于业务中的输出，并且能够具备在不同团队之间交流共同问题的能力。

InfoQ：一些企业正在复制“本地云”概念，并且走向全面方法论、基于团队的架构，优先考虑速度和客户体验。这会改变一个架构师角色吗？他们如何参与到这些基于产品的团队？

Brian:我们正在 DevOps 实践中使用这种模型，每个团队都拥有自己的设计、交付、运营一个产品所需的所有资源，包括解决方案架构师角色，从拥有解决方案的完全所有权和自主权上，产品团队受益颇丰。

企业架构师可以通过以下方式为团队带来价值：

理解技术人员。

在问题 / 模式 / 架构上作为团队的技术资源（当前和新兴技术）。

类似于 Spotify 协会，更流畅的团队组织背景沟通和协作环境中的团队合作。

促进常见问题处理的一致规则性（非强制要求）。

在我们内部，企业架构团队伴随着我们向云端方案交付，驱动组织设计和 DevOps 模型交付，并且手把手地帮助了几个团队 / 产品的交付。

Ian：我不认为这个观念从根本上改变了企业架构师角色。
EA 工作的一部分内容是理解企业架构并管理好它的演进过程。企业架构是一套复杂的系统，我们对于该系统的看法是，它是以应用为中心的细粒度划分，以项目为中心的改变。现在我们的观点是以客户为中心、围绕产品由细粒度的容器组成、微服务化。改变更像是一个功能不断增强的连续的流式进展过程。

过去我们多采用按照功能垂直地和按照技术边界水平地切分大型企业架构方式。现在我们更多围绕客户垂直切分，并且更多沿着产品和服务方向思考，水平分割并不一定会超越产品边界。

所以，EA 仍然需要管理复杂系统，但是变化为由不同类型的积木组成，且沿着不同边界切分的复杂系统。知识需求、设计范例、架构原则，以及管理方式，需要拥有改变这四点所必须的能力。

Kent：我认为有必要对这个问题中的架构师术语作出区分。当然，团队中一定存在架构师角色，我只是不确认他们专注于的关注点。这些团队的设计部分工作是减少外部依赖，转而由重点、速度和自主性取代。但是在监管、管理、技术扩张管理、投资回报率和组织变更管理等领域，企业架构师仍有一席之地。

Ian：我明白你的意思。假设这个问题是第一个问题的延伸，所以我们仍然讨论企业架构师角色以及云端影响对该特点角色所造成的影响。我特意回顾了自己的经历，我曾经帮助一家大型工厂改变运营模型，并且帮助找出如何能让 EA 从管理应用程序，转变为管理相关服务 / 产品组合。这一切还在继续进行，我们还没有针对每一个产品的对应资源进行转型，更多的是落后的产品组合。

Brian：我同意架构师定位清晰至关重要，如果我们是在谈论解决方案架构，我们可以和专注于产品的团队坐在一起讨论细节。针对这一角色的过渡我们需要大约两年时间。

如果我们是在讨论企业架构师，角色改变如你所描述的那样。我认为关键是对 EA 而言，仍然需要参与到业务战略制订里面去，并且作为知识渊博的技术专家，和产品团队一起工作，需要着眼于跨组织的关注能力。

Dan：在 EngineerBetter 公司，我们寻求的是在与客户一起工作时，建立这种类型的产品团队。这些 XP 或关键团队由产品经理和两位工程师组成。在这种环境下，‘架构’可以被认为是一个动词，不是名词。通常来说，正确的设计是通过实际构建产品、学习和调整架构等一系列过程实现的。如果你单独来看这个团队，那么你很可能会认为架构师角色不再需要了。但是，企业过往与敏捷合作的艰辛历史告诉我们，团队之间的接口人及围绕他们的一些人是至关重要的。因此，一位架构师对于理解不同面向产品团队之间的技术分界是很有价值的，他们为企业领导提供了指导，发现问题并寻找机会。由于 EA 角色通常对相关特定领域和历史有大量知识沉淀，他们可以与产品经理合作，减少摩擦、明确需求，创造与客户和股东之间更好的关系。

InfoQ：前一个提问我们故意没有标准化“架构师”类型，想看看讨论的结果，你们的回答震撼了我！“企业”架构师是否需要基于公司的成熟度或是公司变为云端公司这个改变因素？当公司变成云端时，期望有什么变化？

Ian：在我的脑海中，有两个方面。事物变迁过程中的 EA 角色，以及我们产品就位之后的 EA 角色。

从“云迁移”到“本地云”是一个大的组织和技术迁移。这是一个很好的 EA 功能的产出。我不认为角色时至今日有多大的区别，我们只是在做着 EA 的工作。

然后我认为问题转化为云端如何改变一个组织或想要怎么样的“云端”。

我可以看到所有的东西都是基于产品并且自主化的，然后是 EA 角色的变化，或者是减少 EA 的角色。EA 很有可能不会像今天这样深入技术，但是依然会主要专注于管理当前产品和对未来产品的展望。

我不确信是否大型的 IT 公司最终会变为完全的“云端”公司。他们和单机型的 ERP 系统绑定太过于紧密了。所以我认为对于当前的 EA 领域而言，仍然会有很多共享的技术和复杂场景需要去管理，可能存在混合的以客户为中心的自主产品存在，它首先依赖于敏捷，其次是核心 IT。例如我们接收 BI 模型 IT。

我认为至少在我脑海里，对于一位优秀的 EA 的结论是，他会使用相同的技术做好工作，无论云端是否到来！

Brian：我同意 Ian 的观点。EA 角色对于驱动技术和组织转型很关键，因此在本地云化过程中也会很重要。必须重新考虑许多经典范式、废弃的工具和框架，以及职责的转变。这个变化不是很容易完成的，也不会是空穴来风的。随着组织越来越云化，EA 角色可能变得和大势不符，对于明确的“云中心”趋势，或许 EA 会成为反方向的角色。那就是说，真正的云端化改造永远不会“完成”，新的架构模式会出现。需要构建新的云平台和工具。新的服务上线速度很快。EA 需要保持技术与新兴商业机会之间的对等关联。一天工作完成后，EA 需要确保内部变化率（技术和组织），保持跟进或者领先于外部变化率。

Kent：是的，企业架构师（EA）角色仍然需要将组织迁移到云端。无论环境如何，围绕风险、管理、商业价值以及技术扩张等许多原则依然存在。
我期待改变。EA 角色处于影响的地位。如果与 EA 合作的产品，或者项目、团队没有看到价值，或者认为 EA 和当前的愿景无关，他们会避免 EA 加入到解决问题中来。相应地，象牙塔架构师（用于形容设计的架构脱离实际，更像是传达高层的宏伟计划，通常设计过于复杂和耗时）出现了。

Dan：绝对是的。对于 EA 角色的改变期望是组织寻求转变为学习型组织的依托，我只在这里进行解释。一些传统的 EA 关注点仍然存在，但是一些工作模式消失了。变化为‘云端’等同于从基础设施和服务中移除改变的所需要付出的代价。为了平衡这一点，你需要哲学思想帮助你拥抱改变和管理方式，而不是强制型命令方式。所以，对于 EA 来说，事实上是对整个项目管理办公室来说，应该习惯于持续改进的心态。与其做了大量的前期努力、规划和设计，不如尝试新的理念：让我们构建一些实际可以运行的工作，围绕它做些测试，然后迭代。在这个例子中，EA 会表达它们测试的需求，这样可以持续验证遇到安全性和合理性需求。

InfoQ: 云带来了新的技术、工作和模式。是否一位企业架构师可以在没有深入了解云端知识的前提下，决定指定标准或者批准应用架构方案？是否企业架构师需要编写代码，并且使用他们自己推广的技术？

Ian: 企业架构正在逐渐变成标准的监护人，但是并没有独立完成定义它们的工作。通过 PoC（Proof of Concept，即概念证明）和时间安排序列表方式，指定计划从技术列表迁入新的技术。工业化往往是事物分崩离析的原因，只有在技术成熟之后，组织的成熟度才会成为标准。

不同组织内的企业架构师参与的方式可能有所不同。最小程度是他们带来的业务维度，评估这种技术如何可以帮助企业 / 客户。他们评估技术如何可以融入其他的规划里。

企业架构师是否需要编码，这个问题很可能取决于组织规模、组织文化以及架构师的能力。企业架构师可能卷入 PoC 环节，并且实际上为未来的使用编写解决方案代码，或者也可以由对应技术范围内的技术架构师完成。我个人认为有一些底层的经验很有价值，所以我仍然喜欢编写 PoC，但是我认为很多不会这么认为。

Dan: 是的，这样做肯定有帮助，但是在不同背景下学到的深入的技术知识也会有害。我认为对于企业架构师来说，拥有技术实践经验的主要原因，是当他们为工程师引入约束时，有利于互相建立信任。带着这种思维，在双方之间建立信任的最佳方式，是让企业架构师与开发团队中的每一位员工轮流合作。我强烈建议所有的企业架构师，放下一天的会议安排，做一些手头积压的工作并写点代码。我保证你会悟道的！

Brian: 我不认为企业架构师会在定义技术工具、模式或者标准上富有成效，除非他们可以手把手操作这些。这些需要有一个标准的步骤，深入到细节，然后新兴产业会基于事实定义战略方针。你必须保留编码的能力。你必须使用手把手地基于 POC 之上使用新的技术。你可能不会想要出现在交付过程的关键点上，但是你应该有能力做这些事情。这样有利于获得从产品部门来的尊重，有利于组织内部的技术对话，并且帮助你保持较新的架构模式。这样做会让 EA 成为一个极富挑战的工作，但是同时也极其让人崇拜和有自豪感。我认为一位成功的 EA，他需要对业务和技术充满了好奇心，并且致力于探索构建最佳的解决方案。

Kent: 我很喜欢来自 Gary Vaynerchuk 的一个比喻，他是 Vayner Media 公司的数字战略官和 CEO，比喻来自他谈及利用社交媒体扰乱传统市场行为。想法是人们需要在云端花费时间。我认为当我们谈论扰乱传统 IT 时，会有很多的适用性。当一些人处于云端时，他们应该聚焦于视图、战略和目标。“The
dirt”是一个从业者，他为了真正地基于战略实施而理解详细内容。关键是要限制任意两点之间的活动。

我认为这个比喻对于企业架构师来说正合适。为了避免变成技术迁移和“标题朗读者”，真正意义上的起作用，企业架构师需要有能力在光谱的两端执行并提供价值。

让我们带着这些回到问题上，架构师应该花费一些时间在编码上，或者在实际操作上，这样做是为了弄清楚和验证架构中所包含的技术。否则，你怎么知道是否这些技术可以工作？仅仅因为你阅读了厂方的白皮书？

在我看来，挑战是不要在光谱的两端花费不对称的时间，这对不架构师来说很难做到。要做到这一点，需要极强的纪律性和天赋。

InfoQ: 对于当前雇佣企业架构师的公司，你有什么建议吗？这些公司应该观察什么，他们的优先次序是怎么样的？对于为企业内部构建云迁移的企业架构师你有什么建议？

Kent: 公司应该对传统企业架构师提出任何问题。我真的认为组织需要去专注于价值以及询问别人“生产的这个神器怎么产生价值？”如果这个神器很容易过时，我们到底需不需要生产它？是否在一个动态工具里会更好地反映？我也认为人们应该专注于收益，停止奖励他们构建战略的行为。除非执行战略，否则它就是无用的。

组织应该寻找这样的人，那些天生具有好奇心、拥有沟通和技术能力、可以领导和指导别人、愿意动手干活的人。随着组织迁移到了云端，企业架构师需要去主动拥抱这个改变，询问正确的问题，并且变得具有竞争力。云已经在这里了，你极有可能需要去拥抱它。

Ian: 当一家公司开始迁移项目，至少需要具有一些迁移项目经验的架构师。如果迁移仅仅涉及 IT 组织，这很好。如果目标 IT 操作模式是针对更多的中心组织架构的服务 / 产品，那也不错。如果这些产品和服务是基于云端技术的，雇佣一些这样的人吧。

对于已经迁移到云端的公司来说，你需要期望架构师既很好地理解和评估新的技术，又能有很好的业务认知。他们想要去理解业务方向、解决客户的问题，这样可以更好地评估新技术的可行性，并且应用这些技术到已有或新的产品上。然后你可能想要一些能够将新的技术带入公司的实际经验。

技术上的优先级排序大多与核心 IT、基础设施相关联。

对于那些企业内部早已完成云端迁移的企业架构师而言，多于其他公司的同行交流获得见解。了解并评估类似于 IT4IT 这样的参考架构的可行性。完全地理解目标操作模型或者优先帮助定义它。理解当前的和新兴的云端技术，评估可行性，然后提出想法并参与到 PoC 环节，以证明你的看法。

Brian: 雇佣企业架构师的企业，应该着眼于雇佣能力全面的员工，能力覆盖包括编写代码以及使用“概念证明”技术，结合业务领导力一起证明新技术并启动战略方针。动手能力、技术经验，以及过往的领导力经验这三条都很重要。具有指导技术天才的能力也很重要。大多数这样的人都充满了好奇心，持续学习并经常会问“下一步是什么？”。

对于当前正在执行云端迁移的企业架构师来说：1) 动手使用云端技术。如果你不这么做，你不会知道如何有效地向公司介绍云端影响。2) 如果你最近没有开发，需要做这些。3) 得到安全部门的支持，做一些事情改变。4)
认识到技术其实是容易的环节，企业的转型才是最大的挑战。尝试从第一天开始就带领大家一起执行。

Dan: 一些传统的技能仍然还在使用，例如团队业务场景之间的切换能力。基于新的技术，我同意 Kent 的观点，我建议公司雇佣那些有能力专注于收益的员工，而不是专注于架构行动的人。其他关键技能包括持续学习能力。当你开发尝试在工作中使用新的方式时，你会发现很多障碍。在 EngineerBetter 公司，每当开始新的团队或者客户时，我们经常打趣发现了‘草坪上的靶子’。向云端迁移的想法会揭露这些障碍，但是并没有解决它们。公司应该对架构师相关的常用的计划和设计技能进行优先级排序，但是应该产生共鸣，避免出现瀑布式开发模式和敏捷哲学之间的冲突。

当前企业架构师可以在潜在的不稳定环境里找到自己的身影，在公司内部尝试改变。企业架构师需要在外交官、律师、说客、软件开发人员、产品经理之间变化思维。如果你是一位知道有更好办法可以探讨问题的架构师，没有其他人站出来的时候，不要害怕领导大家。目标是创建更好的关键行为；前进的领导会带来更多的领导者。

关于受访者

Kent Weare目前是 TransAlta 公司的 IT 部门执行总裁，TransAlta 公司是一家权威的发电和能源交易组织。获得这个职位之前，他在 TransAlta 公司领导企业架构和集成团队。

Dan Young 已经在多个领域拥有 15 年的工作经验，跨越工程、售前、产品管理等多个领域，他致力于寻找解决组织间冲突的方式。他目前是英国云端制造咨询公司 EngineerBetter 的 CEO，合作的软件团队包括全球范围内的银行、医疗管理、富时 100 零售（伦敦证券交易所上市的最大的一百家公司的股票指数）以及软件生产商。

Brian Chambers 是亚特兰大 Chick-fil-A 公司的企业架构师。他专注于交付新平台和业务的能力，类似于自服务分析、云、电子商务业务等。最近，他开始关注本地云、DevOps 交付实践。他也花费时间在研究和了解新兴技术，寻找正确的方式将这些新兴技术集成到 Chick-fil-A 公司的技术战略。