重新思考企业架构

Posted 2023-03-30 hzbooks

信息技术行业许多角色的名字都是从建筑行业借鉴而来的。因此，我们有开发高级设计的“架构师”，依据这些设计进行详细技术实施计划开发的“工程师”。

这些详细的设计交给系统“构建者”执行。扩展这一类比，企业架构师的角色更类似于城市规划师：定义组织的目标，与其他高级管理者合作制定实现这些目标的策略，为系统开发人员指定约束条件，监控进度和测量结果。正如城市规划师使用的方法和度量标准不同于建筑师，企业架构师也必须使用不同于系统架构师的方法和度量标准。

要定义适当的企业架构框架，我们必须了解企业架构的适当目的。企业架构的目的不是设计系统，而是帮助企业实现特定的业务目标。这些目标可能包括通过更有效的广告来提高品牌知名度，通过更好的福利管理来提高员工满意度，或者任何对企业重要的事情。

企业架构相关工作的所有内容都应该有助于实现企业的目标，对企业目标没有帮助的任务是对资源的浪费。我们必须明白，最终构建的系统并不是最终目的，它们只是达到目的的手段。最终目的是实现企业的业务目标，在任何企业架构的相关工作中，必须首先记住这一点。

许多业务带头人都不喜欢企业架构，因为他们认为这是一项致力于构建模型和图表的工作，而这些模型和图表只对构建它们的人有意义。在这里不要将企业架构与建模混淆。模型通常是有用的，但企业架构工作常常为了建模而建模。他们变得更关注于提供建模工具，而不是解决企业的核心问题。

此外，建模工具通常很复杂，并且学习如何使用它们并不容易，大型企业架构的模型可能非常复杂且难以理解。这可能导致“模型构建者”的发展，他们的工作是以建模工具为中心的。任何想使用架构做点什么（比如想了解哪些系统与工资系统交换数据）的人，都必须咨询模型构建者，希望他们的模型能够产生预期的结果。

本文介绍的企业架构方法体现了对这个主题的不同思考方式。虽然不可能消除中等及以上规模现代企业的复杂性，但已经开发了一种定义和管理企业架构的方法，这种方法能够更好地适应企业规模系统开发和集成的复杂性。

| 1　敏捷实现

大多数企业将企业架构工作视为信息系统架构的扩展，范围从单个系统扩展到企业内的所有系统。在30年前，这似乎是一次自然的转变，当时企业信息系统一般都是大型的、定制的事务，开发是集中管理的，只有大型企业或政府机构才有能力承担这样的工作。

但现如今的信息技术领域已经成熟得多，大量的商业性和开源产品可以直接使用，甚至小团队也可以在短时间内开发实现关键任务的应用程序，大型独立系统已经成为过去。如果试图定义企业中所有系统的实现细节，那么企业架构工作常常会陷入细节的泥沼，失去了敏捷性，而敏捷性对21世纪的组织来说是至关重要的。

信息系统架构的要点是逐步将高级需求分解为具有足够细节的规范，以便软件和系统工程师构建符合这些需求的系统。相比之下，企业架构的重点是帮助企业实现其业务目标，而不是设计或构建信息系统。企业可以使用信息系统来实现某一特定目标，也可以不使用。构建一个或多个信息系统可能有助于企业执行某些业务流程，但这是次要目标—子组织的目标，而不是企业的目标。

要实现任何目标，企业都必须有实现该目标的战略，系统可能有助于该战略的实现，但是任何系统都不能弥补不现实的目标或者缺乏实现该目标的连续战略计划。信息系统的存在是为了帮助人类更有效地处理信息，即使有了当今的先进技术，信息系统也无法做人类做不到的事情（尽管系统也许可以做得更快一些）。如果一个企业没有明确的目标和一个可执行的战略，那么再多的系统设计和实现也无法弥补这一不足。

专注于设计信息系统的企业架构工作将忽略最初的业务目标，而这些业务目标才是进行相关工作的目的。正如“企业架构”这个名称所暗示的，重点是解决整个企业的关注点，而单个系统通常只处理特定子组织的关注点。一个成功的企业架构工作必须始终专注于实现企业的目标。系统架构、设计和实现的具体细节超出了企业架构工作的范围。这些细节是单个系统开发工作的关注点。

| 2　指导企业

那么，如果企业架构将单个系统定义和实现的控制权交给较低级别的工作，那么企业架构师如何指导企业实现其目标呢? 答案是利用一个叫作复杂自适应系统的领域的研究成果。

现在，可以说一个复杂的自适应系统是一个独立实体的集合，其中每个元素都按照它们自己的规则和关注点运行，但是当把这些元素看作一个整体时，它们的功能相互协调，其行为有利于整个组织，并快速适应环境的变化，就好像它们是统一协调的。这里举一个简单的例子来对复杂适应系统进行说明，例如一群鸟，它们没有领导者，但这些鸟作为一个群体移动，看起来像是由一个领导者指挥的，这帮助它们有效避免了威胁，并朝着一个共同的目标移动。

正如没有详细的计划来指导鸟群中的每只鸟飞向何处一样，企业架构不需要指定或记录每个系统是如何实现的。规范和文档需要留给每个系统的架构师来实现。通过从企业架构中消除该级别的指导，企业架构变得更小、更集中、更容易理解。这使得企业架构师能够集中精力监督企业实现其目标的进度，并确保支持这些目标的系统能够在需要时进行互操作和共享数据。

这种企业架构的方法将详细的系统设计和文档委托给更接近实际工作、更熟悉系统预期用户需求的系统实现团队。将这项工作委托给系统实现人员，通过实现更新企业架构的过程，并在进行更改之前获得企业架构师的批准，使他们能够更快地适应不断变化的条件。这种方法更适合当今的敏捷开发实践，并且反映了大多数系统开发工作的实际操作方式。

与传统企业架构相比，以这种方式约束的企业架构更小、更简单。它不试图指定单个系统的实现细节：它指导和约束系统的设计和开发，以确保系统开发工作与企业目标一致并支持企业目标。在大型企业中，这意味着企业架构师必须放弃一定程度的控制，以实现组织的敏捷性。

企业架构规模的缩小并不等同于重要性的降低或对架构准确度需求的减少。相反，企业架构规模缩小了，但是它需要进行更加仔细的定义和约束，管理者可以使用它来管理企业。企业架构成为指导企业成功实现其目标的手段之一。这将企业架构从文档和图表的编译转换为可用于主动管理企业的操作工具。

与其他架构框架相比，这样的企业架构需要更少的构件，并且可以使用简单的建模工具来进行开发。传统的企业架构需要记录每个系统的所有实现细节，需要由团队在专用工具中维护复杂的模型，该团队的工作就是维护模型。这种“模型构建者”成为所有系统开发的核心，因为只有少数人了解模型，所有的更改或添加都需要他们的参与。这就形成了瓶颈，减慢了开发速度并限制了企业的敏捷性。缩小企业架构的范围可以大大减少记录企业架构所需模型的数量和复杂性。虽然这可能不会完全消除模型构建者的角色，但它将模型构建者从定义架构的中心角色中移除，并使企业的管理回归到关注业务目标、实现这些目标的策略和度量进度指标的角色。

| 3　与系统架构的关系

试图将企业架构进行分解，使其包含具体的实现细节，会在对企业层面价值最小的任务上花费大量精力，只有实现团队需要这些细节，而企业管理层不需要。成功的企业架构的关键是记录特定系统对实现每个业务目标的贡献。但是，该系统对目标的贡献（即系统的实现细节）超出了企业架构的范围。实际上，系统实现细节甚至不应该在企业层面直接可见。

解决方案架构应该显式地由企业架构派生，但是这种派生应该是企业和解决方案架构之间唯一的直接联系。企业架构只需定义一个系统，包括该系统对给定业务策略的支持、该系统的输入和输出以及该系统对企业的影响（即它是否执行了外部观察者可以检测到的任何功能）。任何额外的细节都是多余的，并且在每次更新单个系统时都可能过时。花费精力维护更详细的映射很少会带来等价的好处。

《现代企业架构：基于复杂适应系统的架构模式》一书中解释了企业架构应该构建什么，而不是如何建模（尽管我提供了一些示例）。企业架构应该如何构建取决于企业特定的需求和目标。然而，有一个重要的因素必须考虑，特别是对于大型企业：架构必须作为正式的模型进行记录，这意味着架构是一个可以由计算机分析和评估的数学表示。

像Visio这样的绘图工具可以生成漂亮的图片，但它们是图片，而不是模型。必须使用适当的架构工具，如Sparx Enterprise Architect、NoMagic的MagicDraw或类似的工具。如果工具支持行业标准建模语言和数据交换格式（使用非标准建模语言和数据交换格式会导致供应商锁定，这是有风险的），那么使用哪一个工具都可以。

避免使用图表工具来支持架构工具并不意味着模型是不可见的。可视化建模语言，如系统建模语言（SysML）是构建在支持自动处理和评估的数学基础上的。这是至关重要的，这使得架构不仅仅是书架上一堆满是灰尘的文件。通过使企业架构成为正式的模型，我们可以利用自动化处理能力。

手动比较不同系统的图和文档以理解它们的关系并衡量它们是否符合企业的指导方针，是一项困难而耗时的任务。使用正式模型就可以应用自动化工具将解决方案架构模型与企业模型进行比较，还可以更容易地将企业活动的结果与企业架构中记录的目标进行比较。这将企业架构从一堆晦涩难懂的文件转变为一个有价值的、积极的管理工具。

|　小结

目前使用的大多数企业架构框架都源于Zachman框架，这种方法在30多年前就已经被首次描述过。从那时起，系统变得更加复杂和相互关联，软件开发实践已经从构建和部署过程演变为在操作过程中不断更新软件的过程。

这些系统复杂性和开发实践的变化暴露了传统企业架构框架的弱点。传统框架的产品既复杂又笨拙。企业架构不是作为操作管理工具，而是常常成为阻碍企业敏捷性的瓶颈。因此，许多企业认为企业架构已经失败了。

传统的企业架构框架侧重于开发一个或多个系统，本书描述了一个专注于实现业务目标的新框架，系统开发被降级到适当的次要角色，作为达到目的的手段，而不是目的本身。

采用这种新方法能够将企业架构从静态的、以文档为中心的资源使用者转变为活动的、可操作的管理工具。将企业架构的重点从定义系统细节转变为实现业务目标，将企业架构置于其适当的位置上，作为帮助实现业务目标的手段。

|　推荐阅读

想更多了解关于企业架构不同思考方式和企业架构不同建模方法，欢迎阅读《现代企业架构：基于复杂适应系统的架构模式》一书。

大多数企业架构倡导使用现有的系统架构框架，如Zachman或The Open Group架构框架，但它们对于现代社会中基于敏捷开发的企业架构来说并不合适。本书中的新方法是作者结合在大型企业架构开发中的工作经验，基于对复杂适应系统和涌现行为的研究而提出的，它能够通过一些简单的规则产生复杂和高效的企业行为。

简化企业架构的构建和维护工作，可以降低构建和维护架构的成本，并将这些资源释放出来用于追求更高的目标。系统实现人员可以快速适应不断变化的用户需求，无须担心烦琐的企业建模任务。架构从静态模型和文档转化为可以用于主动管理企业资源的运营框架，能够更好地实现业务目标。企业架构师可以不再专注于构建和维护模型，而是专注于实现业务目标。

通过阅读本书，你将学习：

• 通过消除大多数企业级模型，重新将企业架构的重点放在业务需求上。

• 将任务委派给负责系统实现的开发团队。

• 记录业务目标，制定实现这些目标的策略，并衡量这些目标的进展情况。

• 衡量结果并判断企业架构是否正在实现其目标。

• 利用企业架构中有效的建模技术。

更多精彩回顾

书讯 | 4月书讯（上）|  上新了，华章

书讯 | 4月书讯（下）| 上新了，华章

资讯 | 视频时代的大数据：问题、挑战与解决方案

书单 | 金三银四求职季，十道腾讯算法真题解析！

干货 | TypeScript 中的“类型”到底是个啥？

收藏 | 终于有人把Scrapy爬虫框架讲明白了

上新 | NLP大牛菲利普•科恩机器翻译权威著作

赠书 | 【第99期】边缘计算比云计算强在哪里？终于有人讲明白了

点击阅读全文购买

关于 Serverless 应用架构对企业价值的一些思考

作者：寒斜

前言

对于企业方而言，最关心的核心诉求就是如何能获取更多的营收，更高的利润，通俗点说就是如何赚更多的钱；企业赚钱的方式主要是通过出售企业服务，当用户购买更多的企业服务，企业赚的钱就越多；而出售企业服务所付出的成本越低，企业获取的利润收益就会增加。进一步总结下来就是，企业最希望的事情是他们的企业服务在效率，成本，体验上可以不断地提升，因为企业服务体验做的好，购买他的客户自然便会增加；企业服务效率高的公司，在同等单位时间内提供的企业服务就会更多；而企业服务的成本降低，单个企业服务的利润营收就会变高。

明确企业服务价值后，我们了解到成本，效率，体验是营收利润增长的关键。

何谓 Serverless 架构？

我们可以简单地理解为，构建应用中需要的计算，存储，网络，数据库，中间件服务等都实现了 Serverless 化，各个系统实现了最精细化的用云，并且该架构体系在安全，高可用方面以及处理高并发的能力，可扩展性都达到了价值的最大化。下面我举一个实际的例子：_Serverless 架构实现的 Websocket 集群场景-弹幕应用 _来为大家更详细地解释一下。

该项目综合运用了计算，存储，网络，数据库，中间件全部件，用企业的标准构建，同时具备安全，高性能，稳定性，可扩展等能力，且实现了云，边，端的现代化访问架构思路。

其中 websocket.serverless-developer.com 主域名通过全球加速 DCDN 管理，主域的请求会被转发给边缘节点中的 ER 程序，ER 程序进行缓存处理和动静态分流，动态的资源转发到阿里云函数计算网关。函数计算网关弹性启动实例，处理业务逻辑以及访问 MNS 消息中间件和 tablestore 数据库存储，静态资源则尽最大限度进行缓存，必要时从 OSS 对象存储进行回源。其中 DCDN 可以进行边缘防护，防止 DDOS 攻击，并且增加了 Https 安全证书进行网站的加密传输，边缘节点的 ER 程序是 Serverless 化的启停，可以达到毫秒级响应时间。同时函数计算会对更复杂的业务算力进行弹性，访问量大的时候多弹实例，无访问数据则释放至 0。

barrage.websocket.serverless-developer.com 则单独提供 websocket 服务，由 DCDN 自动回源到函数计算，因为本身 websocket 协议无法被边缘应用程序转发。

值得一提的是，笔者作为一名前端程序员，几乎没有高可用，高并发，安全等专业方面的知识，但是这并不妨碍我把这些能力构建到自己的应用上，Serverless is More ，这句话越品味越有感觉。更详细地介绍可参考《人人都是Serverless 架构师-websocket 集群实践》[1]

企业数字化转型中 Serverless 架构的优势

现在我们能够达到的一个基本共识就是：期望通过企业的数字化转型来优化企业服务的成本，效率，用户体验。但是我们暂且先不去讨论企业方因此需要在组织文化方面做的改变，单纯去看数字化管理工具，具体而言就是业务软件部分。构建软件的基本架构在慢慢的发生变化，从 IDC 到容器集群，今天 K8s 已经帮助企业在基础软件架构层面进行了运维体验，效率，成本的提升。下一个阶段的进化是 Serverless。这里需要明确一点是，现在寻求的是 效率，成本，体验三者整体的最佳平衡点，并不是单一项的绝对值提升，因为这三者中存在互斥的现象，比如你提升体验的前提可能是把成本和效率增加了，而降低成本或者提升效率本身也可能会影响体验。我们期待 Serverless 架构能够在适合领域中相较于容器集群管理，去实现三者更优的平衡。

成本

从计算资源成本方面：Serverless 具有比容器化更细粒度的计算抽象。可以做到按量付费，从而极大的节省计算资源的浪费。

**开发成本： **Serverless 架构应用随着分布式的拓扑节点增多，开发运维成本会提升上去，另外市场上因为新的应用架构相关的人才缺乏，从而也会影响 Serverless 架构的应用落地。不过值得注意的是，Serverless 开发者工具正日渐完善，Serverless 应用的开发范式也会更加明确，市面上 Serverless 应用架构的实践案例将会越来越多，相信开发成本会很快被弥补上来。

效率

1.数字化工具本身的迭代更新效率

Serverless 架构本质上是一种精细化用云的架构。传统服务器中的网络，计算，存储，数据库，中间件等都被单独的划分出来，每一项都只关注自己最擅长的部分。比如边缘节点提供的网络能够降低用户的访问时延和流量资费，Serverless 化的计算服务提供极致弹性，存储则提供了无限容量的可能，数据库高性能读写分离，中间件可以提供应用高并发的处理能力，总结下来 Serverless 架构中的组件体系解决了应用逻辑以外的各类复杂的 IT 问题，使得开发人员不必关心非业务开发以外的东西，这实际上能够大大提高数字化工具的迭代更新效率。

再结合 DevOps、AIOps 这些现代化的开发工程体系，Serverless 可以进一步提升开发效率。

2.通过数字化工具提升的企业服务效率

未来对于企业发展而言，会越来越依赖企业级的数字化服务能力，包含性能，高可用，高并发，安全这些属性在内。但是通常对于业务型的研发团队而言，很难处理这些非业务并且很复杂的软件工程问题。Serverless 的应用架构本质上是一种组装范式，其中的组件是被高度抽象化之后并且由专业团队花费数年打造出来的具备企业级能力的技术方案，所以对于业务研发而言不必掌握其技术底层细节，只需要能够将其利用起来去服务好业务本身即可。这样组装出来的软件应用天然具备企业级的能力。

Serverless 架构的组装式研发

用户体验

这里主要指数字化服务体验，更具体一点就是企业业务中涉及软件应用的使用体验。比如软件功能本身亦或是软件的易用性。软件功能除了跟业务的抽象定义相关，也跟技术团队的实现相关。丰富的原子化能力使得 Serverless 架构能够帮助企业跨越技术鸿沟，在构建更复杂的数字化服务软件上有着天然的优势。

还是以上面 webscoket 集群为例，企业相关业务推出弹幕应用，但是因为受限于技术实现无法做到大规模高并发实现，势必会影响希望使用这项服务的用户，但是有了 Serverless 架构可组装实现高可用架构，那么即使公司没有高可用高并发领域相关的专家，也可以实现具备高性能，高并发的业务诉求。

另外，得益于 Serverless 在全链路地扩展，使得开发人员可以在网络层面介入性能优化，利用边缘 Serverless 计算能力，我们可以做边缘渲染和边缘的缓存，让数字化服务触达用户的时间更短，提升数字化服务的访问体验。

---

场景体验：

更多内容关注 Serverless 微信公众号（ID：serverlessdevs），汇集 Serverless 技术最全内容，定期举办 Serverless 活动、直播，用户最佳实践。