企业架构的一点碎碎念

一、企业架构是什么

按照百科定义:

企业架构（Enterprise Architecture），简称EA。是指对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。 复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。 有效的企业架构对企业的生存和成功具有决定性的作用，是企业通过IT获得竞争优势的不可缺少的手段。 https://baike.baidu.com/item/%E4%BC%81%E4%B8%9A%E6%9E%B6%E6%9E%84/31037

这个名词和一般IT人搞的有些差异.虽然IT架构的影响会贯穿始终，但更多会在阶段D 技术架构 进行讨论。

TOGAF几个主要阶段

企业架构的框架有多种如TOGAF、DoDAF（美国国防部体系架构框架 The Department of Defense Architecture Framework）、Zachman等。每个框架都有其适用的领域和对应的模型。

个人感觉模型的主要作用有两个：

1、提供了一个全景和多角度的视图，让我们可以对问题有多角度和分阶段的讨论，避免遗漏。

2、一般会提供一套方法论和工具（大部分场景需要裁剪)

二、技术强度

微软掌门人Satya提出了关于 Tech Intensity和其 模型计算公式：

Tech intensity=(Tech adoption*Tech capacity)^Trust

Tech adoption：知，意识觉醒，拥抱技术，刷新企业新价值

Tech adoption 指的是企业/个人对市场上的新兴技术和工具的接纳及使用程度。

数字化转型，始于企业对新兴技术的拥抱和理解的态度，但从意识的觉醒到运用技术工具创造企业价值之间还有一段艰难的过程，其中企业 Tech adoption 的程度对企业实现价值创造的速度和获益的多少密切相关。

1、初阶接受度：直接应用现有技术工具，实现单位劳动效率的提升。如使用 OA、CR、ERP 等系统软件提升生产效率。

2、中阶接受度： 从企业整体业务流程出发， 应用当前技术工具定制适用于企业业务模式的系统或工作流（Working Flow），解决企业内部及企业与上下游之间端到端的协同运作，从而实现企业在当前模式下的生产效率最大化。

3、高阶接受度：基于企业在数字化转型中数据积累，通过对大数据的分析、洞察及度学习进行商业决策，并挖掘新的商业价值，创造新的商业模式。

每一个企业都需要拥有科技属性，运用技术工具开发适用其业务的软件应用系统。

三、存在什么问题

• 企业问题复杂度高、环节多

这些业务、技术、(人机料法环）问题不会随着一个框架和方法论的采用而消失, 最近听到中医界讲究"一人一策，一人一方" 其实企业更是这样，更需要"一企一策，一企一方"。

• EA 框架落地难

TOGAF的 “王八（形式乌龟）” 图说明了企业要把战略落地需要经历的九个阶段，除了每个阶段需要专业的人士参与之外还需要有熟悉EA的人能针对企业制定适合企业的框架。在此过程可能会有两个主要问题：

1、我知道更好的做法是A,但是我们现在的资源只能选择B，最终导致EA框架不能落地，企业的能力不能形成复用。

2、因为EA本身对流程和基础设施有一定的要求，也会涉及很多专业领域的知识。会陷于其中，导致其价值还未体现就被"靠边站"

技术强度也不是指技术主导业务还是业务主导技术，其本质是双方的自我互相迭代以及协同配合，双方都不会一直停留在舒适区，中间肯定会涉及各种磨合和融合。

• 企业协作的问题

一个企业要解决问题肯定需要其供应商，一个企业会有多个供应商。企业关注的是业务价值的创造和最大化。而供应商关注的自身利益的可持续和最大化。这二者本身就未必统一的。

由于各个企业的差异性，或多或少都会要求供应商做一些定制开发，对于定制开发的成功率和交付的确定性来讲，其实一直是不太高的，但是定制开发的成本确是高昂的。

单就服务来讲，企业肯定希望服务是可以迭代和升级的，所以其需求就是变化的；而对供应商来讲，需求的最好是不会变的，我才能控制实现、交付的成本和确定性。

企业需要快速的变化适应种挑战，供应商希望有商务流程、需求变更流程来满足工时的控制和成本的控制。

企业的数据是流程和数据在供应商那里是割裂的，需要做各种协作和定制开发维护...

• 价值交付

对于企业来讲，我只是知道我有这么一个痛点，但是解决痛点的路径企业未必是清楚的。目前在需求管理中有个坑就是很多IT 供应商希望客户能把痛点说清楚同时把解决痛点的路径也描绘清楚，并且能落到文字上，最好不要变。

其实这是不现实的，有点类似我这里是大药房，我这里各种药都有，你就说你要来点什么药吧；项目失败之后药房可能也蛮委屈，你是自己点的药方不行，不是我的药不灵啊。在个场景里我们明显感觉缺失了一些环节，就是没有医生，没有诊断； 病人需要的也不是药，需要的是恢复健康呀；但是目前TO B业务有一个比较奇葩的地方就是企业不愿意为诊断和开药方这个环节付出相应的费用；这个案例比较像的就是很多人觉得检查费和医生的挂号费有点不值，是药治好了自己病。

真实的情况是用户大部分情况下都是不知道解决痛点的路径的，甚至描述的痛点是不是一个真正的痛点都是一个问题（就像很多疾病的表现和病因一样）。

就价值交付来讲，企业需要需要的供应商能把企业需要的能力落地；而供应商可能会觉得我这儿有一把很厉害的锤子，你告诉我钉子在哪儿？

• 此处省略三万五千字

四、可能会有什么解决方案

以下纯属个人呓语

• 技术强度 企业自身技术强度和EA的能力的增强。
• 行业SAAS 这个其实也有点类似中医，需要足够多的案例和足够长时间的浸淫，才会有动力和能力去真正了解一个行业，研究行业的痛点。SAAS这个商业模式也保证了企业的收入的相对可持续性。 同时SAAS也降低的初期服务交付的周期和成本，可以服务更多的客户，理论上有形成一个良性循环。
• 低代码 在"一企一策，一企一方"的要求下，低代码主要解决的问题是定制服务交付的成本、周期和确定性。在今天的技术成熟度的前提下，低代码理论上可以把定制化这一地鸡毛整成一把鸡毛掸子。 面向不同的群体对低代码的要求 1、用户 需要具备的特点是易用性(比如足够多的模板)、链接能力(打通多个环节、真正解决问题) 2、专业人士 协作、效率、确定性、链接、迁移能力 更多细节下次再聊。
• Serverless 有人认为Serverless 会是下代saas，但就Serverless 自身提出的口号

免运维、按需使用、按量计费的特性

除了降低saas的使用的成本和门槛之外，还会在服务连通领域有很多新玩法，可以各个供应商的互通的难度显著降低(当前供应商自身API化的能力是逐渐增强）, Everything through api。低代码和Serverless会互相增强。