专访企业架构学者Svyatoslav Kotusev
编者按：今年 5 月份华为的企业架构与变革管理部推出了一本著作《华为数字化转型之道》，「企业架构」和 TOGAF 由此受到了越来越多企业的关注。但企业架构的理论庞杂，无论对组织还是个人，它的学习、理解、应用都不是一件容易的事。而在企业架构领域，却有一位很特别的国际学者，他多年从事企业架构的研究，不趋同，有着非常鲜明而独到的见解。让我们看看他是如何阐述为什么学、怎么学、如何应用企业架构的，应该会对您有所帮助（或许会改变您的认知）。
介绍
Q1：请向 Thoughtworks 的朋友介绍一下您自己好吗？
我是一位企业架构（Enterprise Architecture，简称 EA）的研究学者。从 2013 年至今，我一直在从事这个领域的研究。我的研究成果包括了畅销书《企业架构实践》（The Practice of Enterprise Architecture）、50 余篇关于 EA 的学术和实践论文/文章，以及一些其他企业架构师相关的材料（例如参考指南、速查手册、教程）。有关我研究成果的更多信息，可访问我的个人网站。
为什么要学习企业架构？
Q2：您是在什么时候接触 EA 并决定开始研究 EA 的？
我的职业生涯始于软件研发，之后晋升为软件架构师，并希望进一步发展成为一名企业架构师。然而，一路走来，我意识到「研究和分析」事物比「实际做」对我来说更有吸引力。因此，我从工业界转向学术界，成为了一名 EA 研究员，而不是一名职业的企业架构师。
Q3：EA 到底是什么（尽管您的书中已提过）？
事实上，「企业架构」这四个字有无数的定义和衍生含义，很难准确解释 EA 究竟是什么：全景（landscape）结构、规划方法、决策理念或仅仅是一堆架构文档。
在我自己的文章中，我倾向于以传统方式将 EA 定义为**对齐业务和 IT 规划的文档集合**。
但是，我还使用了一些补充术语来表示相关概念：「EA 实践」表示组织级的规划实践，「EA 工件」（EA artifacts）表示具体架构文档，「EA 职能」表示负责规划的组织部门，「EA 领域」（EA Discipline）是关于 EA 的所有理论基础。
重要的是，虽然这一整套定义不是唯一或最好的，但它们内部是一致/统一的，可以清晰地引用与 EA 相关的特定概念，不再是那些模糊抽象的「企业架构」了。
Q4：Open Group 前段时间发表了一篇文章《企业架构是工科学生的「基础技能」》。Thoughtworks 每年招收大量工科应届生。您认为 EA 对毕业生有帮助吗？为什么？
以我个人的意见和观察（但我不假装在这件事上是权威的），没有行业实践经验的大学生应该只能粗略地了解一下 EA 的概念。这是因为大多数本科生，至少是我遇到的那些，几乎不了解大型组织及其 IT 环境的复杂性，因此几乎无法理解 EA 的作用和价值。除此之外，理解 EA 肯定不是像 The Open Group 文章所建议的那样研究 TOGAF、IT4IT和 ArchiMate标准就够了。
Q5：Thoughtworks 是一家 IT 咨询公司，我们主要做 IT 咨询和交付项目。每个项目将包括各种角色（Role），例如业务分析师、项目经理、产品经理、QA、UX、技术主管、开发人员、数据科学家等等。您认为哪种类型的角色最应该学习和掌握 EA，为什么？
有趣的是，在你的角色列表中，你没有提到任何架构师（例如直接参与项目工作的解决方案架构师），架构师应该是学习 EA 的主要候选人。
因为您列出的角色都不是架构性的，所以我相信您的问题的最佳答案可能是：项目经理、产品经理、技术主管和开发人员等人应该了解 EA，以了解组织中的每个项目的实施匹配更广泛的组织上下文。因此，应该具有企业级范围的考量，而不是仅仅受局部动机的驱动。
例如，在规定的期限内走捷径可能会取悦项目经理和产品负责人，但最终会因为架构次优、目光短浅的选择而最终对公司有害，而这些都不得不在未来亡羊补牢。或者，允许开发人员选择自己喜欢的技术（方案）进行项目实施，在短期内可能是一个好方法，但从长远来看，肯定会因为不可控的技术扩散（Technology Proliferation）给企业打来更多危害。
简而言之，各种非架构项目参与者都应该学习 EA，在很大程度上，这是为了明确整体组织的上下文，并在他们的工作和决策中融入全局的视角，这才会为组织带来价值。
如何学习企业架构？
Q6：如果从零开始学习 EA，您认为一个好的方式或路线是什么？
对于项目经理、软件开发等角色来说，阅读我的书或其他相关主题的研究材料，对 EA 有一个基本了解，就已经足够了。
但是，如果一个人想成为一名企业架构师，那么任何正规的教育恐怕都是不够的。作为一名架构师，需要非常优秀的软技能，概括下来就是一个词「沟通」，这只能通过实践获得。
出于这个原因，在我看来，成为架构师的唯一真正的方法是「观察」，观察有经验的架构师做了什么，他们是如何做的，并留意他们的绝活（Tricks of the Trade）。
总之，要成为一名架构师，就要向其他架构师学习。
核心的关键点是，在没有真正实践 EA 的组织中工作是根本无法学习到 EA 技能的，所以这将是一个可遇而不可求且漫长的过程。
Q7：对于有工程（engineering）背景的和没有工程背景的人，您认为他们在学习 EA 的过程中会遇到哪些挑战？如何应对这些挑战？
对于具有工程背景的人来说，关键的挑战是要意识到「找到组织上可接受的解决方案」根本不是工程任务，因为这无法通过他们熟悉的严格分析方法来解决。相反，在复杂的利益相关者（stakeholder）之间达成一致，需要的却是工程师欠缺的「政治技巧」。
为了应对这一挑战，工程师必须明白，组织环境中的最佳解决方案不是那些看起来最合理的解决方案，而是那些其他人可以同意并相应地改变他们态度的解决方案。
对于没有工程背景的人来说，最重大的挑战可以说是要意识到技术是复杂、僵化的，并且包含很多错综复杂、隐藏的依赖关系，这使得几乎每一次改变它的尝试都变得复杂。
为了克服这一挑战，非技术人员可能应该尝试详细研究任何「严肃」的技术，以亲眼看看 IT 世界是多么复杂，并开始对与技术相关的问题给予应有的尊重。
有趣的是，成功的企业架构师既是工程师又是政治家，能够设计出体面的技术解决方案，并将这些解决方案「推销」给组织。
Q8：除了您的网站/著作，能推荐一些学习 EA 的好资源（网站/视频/书/期刊）吗，特别是我们可以在哪里找到一些真实的 EA 案例？
由于多种原因，在我看来，关于 EA 的大多数可用材料都非常肤浅和不值得，对现实世界 EA 实践的深入分析仍然非常稀缺。
我认为有价值的一些资源包括（如果我忘了提及某人，请原谅我）：非常有名的《Enterprise Architecture as Strategy: Creating a Foundation for Business Execution》，堪称宝藏资源的《Managed Evolution: A Strategy for Very Large Information Systems》，还有这两本《Strategic Enterprise Architecture Management: Challenges, Best Practices, and Future Developments》和《Chess and the Art of Enterprise Architecture》。所有这些书籍都分析了真实组织的经验（而不是虚构的 ArchiSurance），并对 EA 进行了多维度的、非常有价值的分析。
Q9：如何测试我学习 EA 的效果？或者，换个角度，如何测试一个人的 EA 能力和水平？
这是一个非常困难的问题，因为无论是单一架构师的有效性（effectiveness）还是组织中整个 EA 实践的有效性都无法轻松评估，更不用说衡量了。
从成果的角度来看，这件事情只能根据对个人或组织的成效进行主观评估。
很难想象任何正式的测试来评估一个人的 EA 能力，但是一个人观察到的成功和失败可以作为衡量他们的指标。
如何应用企业架构？
Q10：您对目前的 EA 框架有什么看法？您能否以 TOGAF 为例，谈谈它的优势、局限和存在的问题？
总的来说，我对当前 EA 框架（例如 Zachman、FEAF、DoDAD 和 TOGAF）的看法在我的一篇文章《Enterprise Architecture Frameworks: The Fad of the Century》有过详细的总结。这些框架在围绕 EA 的炒作浪潮中脱颖而出，浪费了试图使用它们的组织的时间和金钱，只具有纯粹的象征意义。
TOGAF 就好比占星术（horoscopes）。从科学的角度来看，星座没有任何预测能力，在此基础上，无疑应该被认为是无用的。然而，许多人使用星座是因为他们更愿意相信自己的预测，或者仅仅是因为他们灌输了错误的确定感，他们觉得星座很有趣、获取内心安慰。
以上就是 TOGAF 的现状。TOGAF 显然与成功的 EA 实践没有任何关联（除了确实产生了一些 EA 工件和其他琐事），除此之外，理应被认为是无用的。然而，许多人却研究它并试图「正确地」解释它，想弄清楚该怎么做。
令人惊讶的是，根本不存在真正的 EA 最佳实践——这一事实并没有阻止公众继续在 TOGAF 中寻找 EA 成功的关键。
与占星术一样，TOGAF 与现实「明显且完全」脱节，但这并没有妨碍人们相信它的实用性，这与任何逻辑和常识相悖。
有鉴于此，谈论 TOGAF 的「优势」或「局限性」完全没有意义，而只能承认其唯一的关键问题：TOGAF 与现实经验没有任何相似之处。其余的只是猜测或巧合。
Q11：您能告诉我们 CSVLOD 模型的故事吗？这个模型是如何形成的？它的优点和缺点是什么？
CSVLOD 模型它背后的故事相当简单。当我开始研究 EA 时，我意识到现有的 EA 模型（例如 BDAT —— 业务、数据、应用和技术）无法真正对 EA 工件进行分类，许多工件涵盖多个领域，更重要的是，没有解释它们的组织背景中的职能。
我对 EA 工件及其在组织中的使用进一步分析得出的结论是，尽管它们具有复杂的多样性，但它们都可以简化为只有六种具有独特属性的通用类型，我将其命名为考量（Considerations）、标准（Standards）、愿景（Visions）、全景（Landscapes）、纲要（Outlines）和设计（Designs）—— CSVLOD。
关于 CSVLOD 模型的优缺点，我将它们表述如下：
- CSVLOD 模型是同类模型中唯一源自对组织中的事实经验的分析，而不是源自「圣经」（holy scriptures）的模型。
- 它解释了很多关于 EA 工件的信息内容、展示样式、目标受众、使用场景、生命周期和许多其他属性。
- 与任何模型一样，它的缺点是它只能做到对现实的近似或简化，从这个意义上说，它本质上是不准确的。
Q12：掌握了 EA 的理论之后，如何应用 EA 是我们项目中的一个痛点。例如，我们帮助客户交付一个「售后运营系统」。如果客户有比较明确的需求，那么按照我们成熟的敏捷项目需求和开发流程就可以完成。 EA 是否只对企业级的数字化转型项目起作用？
根据定义（尽管它有无数的定义），EA 主要应用于高级别的架构类工作，而不是独立的项目，并且发生在项目上线之前。因此，如果您的任务是交付具有明确需求的系统（即项目已经成型），那么与 EA 就不太相关了。这意味着客户已经应用了一些或其他与 EA 相关的技术来指导需要实施是哪个项目哪个供应商。简单地说，在您的示例中，EA 类工作发生在客户方，而不是顾问/供应商一方。
然而，EA 意识可以帮助顾问通过请求其架构原则、指南、模式和全景图来满足客户，以使新系统与客户的标准保持一致，并将该系统正确地集成到其现有 IT 环境中。虽然顾问不直接使用 EA，但对它的认识可以帮助顾问更好地为客户服务。
文/Thoughtworks 刘申
原文链接：专访企业架构学者Svyatoslav Kotusev