寻找架构师：从企业架构的角度看需求的满足

传统的IT架构使用了这么多年，所有的监控设备以及网络架构都是基于此打造，那么在传统架构虚拟化、云化后的今天，如何针对虚拟化、云计算的环境如IAAS、PAAS进行运维？

传统监控系统主要是基于传统的环境构建。主要是针对基础的硬件设备、业务系统的监控，对于虚拟化环境的覆盖是不足甚至可以说是零覆盖的，特别是在虚拟化技术引入之后，每台宿主机里面的众多虚拟机怎么去运维？众多的容器 、微服务 、APP怎么运维

如何监控是云化后运维监控面临的挑战。

博睿数据依托完整的IT运维监控能力，公司利用大数据和机器学习技术构建的先进智能运维监控能力，可基于自身的通用性，满足最为广泛的用例，有效控制企业成本，确保数字化业务平稳运行，保证成功交易，保障良好的数字化体验，更有针对性地向客户提供服务。

截至2023年3月1日，博睿数据已经拥有17项已授权发明专利、111项软件著作权、27项核心技术，在应用性能管理领域实现了多项技术突破，具备较强的技术先进性。如今，公司已经与CNNIC、CFCA、IATA、中国互联网协会、数据中心联盟、中国信息通信研究院、中国金融产业科技发展联盟、华为等机构和企业达成了多元合作，并成为中国信息通信研究院AIOps标准工作组、中国电子工业标准化技术协会信息技术应用创新工委会等行业权威组织的会员单位。

博睿数据秉承“让IT运营更智能”的品牌理念，成立15年以来，公司已在北京、上海、广州、深圳、武汉、成都等地设立了营销中心，在北京、武汉、厦门等地设立有研发中心。持续对IT运维监控技术的专注，使得公司的解决方案覆盖了IT运维监控管理所有分支领域（DEM、APM、ITIM、NPM和智能运维管理），并被广泛应用于互联网、金融、制造业、电信相关服务、电商等多个领域，客户包括阿里巴巴、腾讯、百度、华为、国泰君安证券、中信银行、中国南方航空等行业巨头，覆盖IT运维人员、开发人员、技术支持人员、前端业务人员等多种职业角色。

EA（Enterprise Architecture）是一个系统的基本组织，具体表现为系统组成的组件（component）、组件之间的关系，及其设计和演进的原则。目前国际上最为成熟和流行的EA架构方法即为The Open Group提出的TOGAF架构框架。TOGAF通过架构开发方法（Architecture Development Method，ADM），指导企业从无到有的开发架构。ADM从架构预备阶段和架构愿景开始，逐层开发业务架构、信息系统架构（应用架构和数据架构）、技术架构。那么在ADM方法中，对于最先开发、也是最重要的业务架构给出了哪些详细开发路径呢？

 选择参考模型、视角和工具（见TOGAF92 731 节）

开发基线业务架构描述（见TOGAF92732 节）

开发目标业务架构描述（见TOGAF92 733 节）

 进行差距分析（见TOGAF92 734 节）

定义候选路线图组件（见TOGAF92 735 节）

化解贯穿整个架构全景中的影响（见TOGAF92 736 节）

 进行正式的利益攸关者审视（见TOGAF92 737 节）

最终确定业务架构（见TOGAF92 738 节）

 创建架构定义文件（见TOGAF92 739 节）

看起来是不是有点简单，作为其他架构开发的输入和先决条件的业务架构，居然只用9个步骤进行描述，而且其中最关键的业务架构开发过程也只是用了“开发基线/目标业务架构”这样比较笼统的说法。我们再来看看“开发基线业务架构描述”的详细内容，TOGAF92中是这样定义的：

定义的范围和细节层级，将取决于现有的业务元素有可能延用到目标业务架构中的程度，并取决于架构描述是否存在，如 75 节所述。尽可能地利用架构存储库（参见第五部分第 37 章）识别相关的业务架构构建块。当需要开发新架构模型以满足利益攸关者的关注点时，使用步骤 1 中识别的模型作为创建用于描述基线架构的新架构内容的指南。此套方法实际上是用来指导复杂组织体如何建立和维护其复杂组织体架构的一套流程化的架构开发步骤。

是不是还是觉得有些简单？TOGAF定位为架构框架标准所决定的，为了保证最广泛的适用性和中立性，TOGAF没有给出（也不可能给出）具体的业务架构开发方法。同理在应用架构、数据架构和技术架构层面也是如此。所以企业在应用TOGAF开发架构时，必须要补充适宜的工具和方法，结合企业实际情况开展业务架构设计。 在企业架构视频课程中，我们通过第一个真实的项目案例，《某电子产品生产制造企业业务架构设计与实践案例》向大家系统的介绍了如何通过科学的方法和严密的逻辑推导得出组织的业务架构。在开展具体的架构项目之前，必须先了解架构思想的本质，这样才能保证具体项目的实施过程中整体方向的准确和目标对准。这是架构理论的“道”。我们结合项目实际情况介绍了架构方法的精髓是对组织开展正向设计，并通过通俗的产品和软件的开发过程进行类比。见下图。

     在深入理解架构思想的基础上，确定了项目的整体目标，按照TOGAF的ADM架构开发方法，确定了描述现状——系统的回答企业业务现状（在哪里），设定未来——确定企业目标业务（去哪里），规划路径——确定迁移路径和治理（怎么去）共三个阶段。这是架构理论的“法”。见下图。

确定了架构的“道”和“法”，还要在项目执行过程中注重“术”的运用。本项目在业务设计中，采用了IBM提出的“组件化业务模型”CBM的方法，通过业务组件结构化梳理企业业务构成，系统的反应企业业务全貌。

关于业务组件的设计方法，我在以前的文章中（例如《组件化业务模型》、《组件化业务模型（CBM）在企业架构和流程架构中的应用》）已经有过介绍。文章中就不再赘述了，我会在视频中结合具体项目讲解如何使用。见下图。

当然，结合项目的实践经验，创造性的提出了从业务组件的“科学性”到“艺术性”再到“科学性”的设计方法，不仅用严谨了逻辑推导业务架构设计过程，还提出了针对业务架构设计结果的校对和验证过程，从根本上确保业务架构设计结果的正确和逻辑性。见下图。

事实上，在具体的项目过程中，存在大量需要注意的细节和技巧。例如在业务组件定义过程中，每个业务组件都应有较为清晰的业务范围定义，成本构成、测评指标、产生的业务对象，对外提供的服务和接口等。我们结合项目真实情况，详细介绍了业务组件推导过程中每一个步骤的设计细节，这些内容都是既满足了CBM方法的要求，又对具体的 *** 作过程进行了补充和细化。同时运用业务组件分析方法，将企业的业务组件层次进行梳理并重新进行标准定义。见下图。

在现状业务架构设计过程中，还通过对现有业务的梳理、分析和提取，形成业务组件分析矩阵。对业务组件进行系统分析，找出“热点”，从组件的重要程度、变革紧迫度、业务关联度等多个纬度进行分析，得出当前企业架构需要重点改善的 “热点”组件，同时对这些“热点”组件的能力需求进行提取，形成了后续局部改进项目和未来目标架构设计改进目标和落脚点。热点组件图见下。

这些业务组件的接口和交联关系、所用的资源、提供的服务、依靠的 IT 系统等方方面面的能力都以模型化的方式描述出来。通过相应的标准对业务组件进行评判，得出的“诊断单”，就是当前架构下的业务运营现状及存在的问题。

在确定企业业务现状的基础上，进一步通过分析战略，确定企业未来想成为什么样的企业。战略的选择所带来的组织运营模式也决然不同。企业基于对自身技术、人才以及对外部市场、环境的长期经验和敏锐判断，设定适合企业发展的战略选择。基于未来战略，需要在当前业务上做出什么样的调整，如增加什么业务来实现新的战略或砍掉什么非关键业务，来适应新的战略。

这些业务组件的接口和交联关系、所用的资源、提供的服务、依靠的 IT 系统等方方面面的能力都以模型化的方式描述出来。通过相应的标准对业务组件进行评判，得出的“诊断单”，就是当前架构下的业务运营现状及存在的问题。

在确定企业业务现状的基础上，进一步通过分析战略，确定企业未来想成为什么样的企业。战略的选择所带来的组织运营模式也决然不同。企业基于对自身技术、人才以及对外部市场、环境的长期经验和敏锐判断，设定适合企业发展的战略选择。基于未来战略，需要在当前业务上做出什么样的调整，如增加什么业务来实现新的战略或砍掉什么非关键业务，来适应新的战略。这些战略调整工作，通过业务组件顶层管理视图，实现从高层领导感性的判断转向基于业务组件模型的理性推演。实现基于战略的业务能力及组织的重新布局，对一系列业务组件模型的再设计，就形成了企业未来的目标业务架构，即企业未来的设计蓝图。

基于企业未来架构的这张设计蓝图，进一步确定业务蓝图实施的先后顺序，比如 ：房屋建设的规划路径是先打地基、再盖主体、最后装修等工作，以及相应的资源、组织安排等一系列详细策划。架构的规划路径，就是根据企业目标业务架构，确定实施的步骤，其原则是充分考虑战略目标、当前业务架构与目标业务架构的差距，以及外部环境等因素，综合分析，确定业务架构、信息化架构调整实施的解决方案和路径。

整工作，通过业务组件顶层管理视图，实现从高层领导感性的判断转向基于业务组件模型的理性推演。实现基于战略的业务能力及组织的重新布局，对一系列业务组件模型的再设计，就形成了企业未来的目标业务架构，即企业未来的设计蓝图。

基于企业未来架构的这张设计蓝图，进一步确定业务蓝图实施的先后顺序，比如 ：房屋建设的规划路径是先打地基、再盖主体、最后装修等工作，以及相应的资源、组织安排等一系列详细策划。架构的规划路径，就是根据企业目标业务架构，确定实施的步骤，其原则是充分考虑战略目标、当前业务架构与目标业务架构的差距，以及外部环境等因素，综合分析，确定业务架构、信息化架构调整实施的解决方案和路径。

本项目依据TOGAF企业架构方法论，聚焦业务架构，落地了战略变革，提升企业管理成熟度，助力企业塑造核心竞争力。更重要的是在TOGAF方法基础上，融合CBM业务组件设计方法，探索了业务架构的开发路径，为TOGAF的理论方法提供了有力补充和实践案例。

本项目详细技术路径、实施过程、架构制品等内容，请关注《企业架构视频课程项目1：某电子产品生产制造企业业务架构设计与实践案例》。

近年来，随着互联网尤其是移动互联网技术在各行各业的渗透逐步深入，部分传统行业也从最开始的排斥互联网到现在急迫的想拥抱互联网，努力学习互联网思维，学习互联网技术，希望借助互联网技术来完成企业的转型或者升级。而互联网应用的发展，在“以用户为中心”理念的指引下，带来的最直接变化便是用户需求的升级，一方面来自被动接收的用户需求升级，另外一方面来自企业主动提供服务满足用户需求的服务升级。To C用户需求自不用说，在互联网的影响下，伴随着To B 用户需求的升级，其价值空间已经越来越得到关注。

如何快速响应用户诉求，验证用户需要在企业信息化的过程中，很多公司或多或少都做过不少尝试与探索，甚至已经取得了不错的成果，如敏捷开发转型、DevOps建设、双模IT、系统产品化建设，微服务架构等等。这些当然都是很好的方法，都能够直面用户需求，直接提供用户需求的解决方案，各有千秋。然而纵观各种方法，大都是自下而上的直接解决问题型，今日笔者想从另外一个维度，即企业架构，自上而下的角度和各位探讨一下看看如何更好的满足用户需求。

信息化建设存在的问题

企业架构框架理论最早是由美国架构规划专家约翰·扎克曼（John Zachman）于1987年提出，扎克曼（Zachman）也因此被誉为EA之父，在此之后，EA的框架和方法论不断的被提出。目前影响比较大，使用比较广泛的企业架构框架和方法论主要有Zachman、TOGAF、FEA和DODAF等。其中TOGAF 由国际标准权威组织The Open Group制定，也是目前应用最广发也最主流的架构框架，FEA是有美国联邦政府预算管理办公室提出的适用联邦政府行政管理体系，而DODAF则是由美国国防部于1996年首次发布。

在企业的信息化发展过程中，普遍存在一种现象，即“信息化”就是若干个“信息化系统建设项目”的总和，采购或者开发一个系统也并不是对业务需求的IT解决方案。相信几乎所有的公司都会制定短期、中长期的总体规划和分步实施计划，但大都是“项目导向”型，这种模式在互联网的时代当面临着不断变化的需求时总是有一种力不从心的感觉。在证券基金行业，信息化系统尤其是核心系统又大都以招标采购为主，自主研发为辅，信息技术部也大都定位为中后台支持服务部门，从公司到部门的关注点更多的是在业务具体需求的技术实现上面，而忽略了对企业需求获得能力和信息化感悟能力的造就。特别是当IT人员缺乏对公司战略目标和业务规划全面了解的时候，IT人员也只能把视角放在技术层面。

随着企业业务的发展，公司组织结构也逐渐变得复杂，为满足业务运作逐步建立了很多分割的部门、流程、和系统，由于边界的模糊经常会出现各种冲突，导致运营效率较低，业务与IT人员沟通不顺畅，系统建设滞后，用户需求无法及时响应的情况。总结下来信息化建设的过程中普遍存在以下问题：

1、烟囱式的系统建设。这种建设模式主要有三大弊端，第一，重复功能建设和维护带来的重复投资；第二，打通烟囱式系统间交互的集成和协作成本高。第三，不利于业务的沉淀和持续发展。其中前面两个弊端是基于成本和效率的角度，第三个弊端则是基于发展的角度，危害最大，不利于企业业务服务能力的积累与建设。烟囱式的系统建设在很多时候不得不打破“以用户为中心”的服务理念，不是不想，而是不能。

2、对信息化建设的认识不够。企业信息化一直处于手段和工具层面，认为信息化的主要工作仅仅只是改进工作效率，提供系统支持，认为只是信息技术部一个部门的工作。但实质上企业信息化建设应该是一个企业全局性的工作，从管理层到各部门骨干应该要有一些对企业信息化基本的共识。

3、IT不懂业务。IT人员不懂业务主要体现在三个方面，第一，对基本的业务流程，业务规则和业务模型不了解，导致业务与IT人员沟通成本高；第二，IT人员不仅要懂业务流程和规则，还需要对业务的发展提出自己的理解与看法，并对如何优化业务 *** 作，提高流程效率能够提出一些创新的想法（可大可小），在门槛相对较高的金融行业，要能够达到这一点，需要对应的IT人员在相关的业务领域中有足够长时间的沉淀和积累。第三，能够识别关键业务，所谓关键业务就是能够产生相对较大的经济和社会效益以及能够产生公司核心竞争力的业务。资源总是有限的，IT人员需要权衡将有限的资源正确的投放到满足关键业务的需求中。现实情况是在证券基金行业能够满足第一点已实属不易，能够达到第二点要求已实属难能可贵，而第三点对IT决策层与管理层提出了更高的要求。IT的价值体现往往更多的是表现在对业务的理解与把握上，IT与业务、用户对需求能够更快速的达成共识。

在企业的信息化发展过程中大大小小的问题很多，在这里就不再一一列举。而架构其本质是一门“描述语言”，通过架构让管理层、业务部门、IT部门对战略、规划、计划在同一个维度进行表达，是业务与信息技术之间的桥梁，是业务、应用、数据、和技术之间的协同。企业架构从企业的业务和战略出发，制定企业的整体信息化蓝图，希望能够在对业务战略和业务流程的理解上能够对信息化进行顶层设计，逐层设计，形成灵活稳健的IT结构，企业的战略、业务和技术的变化都可以反映在企业架构之中。

如何构建良好的企业架构

在开始进行企业架构工作之初，首先我们应该清楚IT工作在企业架构内部的定位如何（此处不是单指IT部门），由于各企业业务模式的不一样，其IT工作在企业内部的定位也会不同，IT的定位一般可以分为如下四种，而传统证券基金行业一般都属于第一种模式，由业务运营来驱动。

在清楚了IT的基本定位以后，便清楚了企业架构的工作方向，业务战略，业务架构，和IT架构构成了工作的核心，而其中IT架构又包括应用架构、数据架构和技术架构。

企业架构的工作的第一步便是对现状的调研与分析，从对公司战略的解读，到业务现状的梳理，以及信息化现状的分析，了解基本信息并形成基线架构，对于业务愿景从业务目标和业务战略入手，梳理当前存在的业务问题及业务发展方向，并对相关问题达成共识。

业务架构是企业架构的重中之重，通过一种结构化的方法将业务目标与业务具体需求结合在一起，形成业务需求框架，可以清晰的描述业务需求，使得业务与IT对需求的理解保持一致，可以达成共识，同时通过整个企业范围内的需求整合工作梳理了企业全部的业务方向，明确了各业务的业务价值，可以清晰IT对业务支持的重点和支持边界。

业务架构框架可以以价值链为基础，进行流程的逐级细化，主要包括4层：

一、业务价值，即（价值链视图）

二、业务管理视图

三、业务流程视图

四、流程活动图

在业务架构设计框架中，可以把企业内外价值增加的活动分为基本业务域和支持性业务域。其中基本业务域涉及企业对外服务的活动；支持性业务域涉及人事、财务、研究与开发、采购等内部支持活动。

基本业务域和支持性业务域构成了企业的价值链。不同的企业涉及的价值活动中，并不是每个环节都创造价值，实际上只有某些特定的价值活动才真正创造价值，这些真正创造价值的经营活动，就是价值链上的"战略环节"。

根据业务价值链设计的业务能力，每一种能力都可以用业务域来表达。

按照业务域的划分，逐步丰富和完善业务，形成公司的业务组件模型（CBM），同时从流程的角度对业务进行分层分级描述。

通过对业务架构的梳理与设计，整合后的需求是未来项目开发的需求指导，可以提供更多的信息给架构师，让他们可以以更高的视角、更远的场景、更合理的方法进行架构设计，保障系统的先进性、稳定性、可扩展性。当接收到新的需求时，可以直接与业务架构进行匹配，也可通过业务架构的设计主动产生需求。

应用架构可以描述各个部署的应用，它们之间的交互，以及与核心业务流程之间的关系。应用架构不是对某个具体系统的设计或者需求分析，而是定义企业向业务部门提供的整体的IT应用系统和功能，即IT对业务的信息化解决方案。通过它明确了业务功能的边界和划分，并且展示了不同划分以及之间的关系。

在应用架构中应通过不同的应用域、应用组件等来集中表现，通过应用域视图来描述应用架构中域的划分，以及应用域与应用系统的关系。对应用组件，可按照基础组件、通用组件和业务组件来进行分类设计。

对于大部分在传统证券基金行业的公司而言，其IT解决方案，尤其是核心系统大都仍然以从供应商采购为主，而部分供应商的一些系统随着其产品的成熟度提高和市场的发展，已经基本发展成为行业的标配，如在资产管理行业，投资管理系统O32几乎已成标准配置，在涉及相关应用域的架构梳理与规划的过程中，也需要考虑此类行业通用的系统，充分融合其架构。只有在此行业通用的架构基础上规划和设计的本公司内部的专有架构，才具有更高的可行性和更稳健的架构演进路径。

在数据架构阶段，以业务架构为基础，设计数据主题域视图，以展示数据域与数据主题以及数据主题对业务能力的支撑关系；设计概念数据模型视图，展示数据主题下的数据实体，并展示数据实体之间的业务关联关系。

通过数据架构的规划，能够确保应用与数据之间的关联性，保证数据的唯一创建从而保证数据的准确性，明确数据源及数据保存机制，保证数据的一致性。数据本身是一种资产，需要能够真正做到可共享，同时符合安全性要求等。

而技术架构的核心工作即是通过技术的手段把前面设计的架构蓝图实现出来，技术架构由支持企业应用的、以及各种IT基础资源和设施为描述对象的技术域构成。通过技术架构来建立一个IT运行环境以支持数据和应用架构以保证业务的正常开展。

企业架构创造需求

回到关于需求的响应，需求管理的能力一般可分为3个阶段：管理需求，发现需求和创造需求，而企业架构就是一种创造需求。企业架构在企业信息化的过程中起着承上启下的作用，如下图，在满足用户越来越个性化需求的同时，不仅需要自下而上的直面需求，更需要自上而下的全局把控，双管齐下来满足需求，而个性化需求的满足能力也正是一家公司竞争能力的表现，需求与个性化需求，从需求的提出到需求的实现，均可有对应的架构规划来更好的支撑。

在本文中笔者并未对具体如何详细开展企业架构工作（如何做调研，如果做现状梳理，如何做架构设计等）做过多深入的讨论，仅仅从企业架构的必要性角度进行了阐述，抛砖引玉若有兴趣欢迎一起探讨。

由此引发了笔者进一步的思考，当互联网/移动互联网已经成为基础设施的时候，人工智能时代的序幕已经拉开，你又准备好了吗？或许企业架构设计的思维也能够助您一臂之力。

注：本文发表在《恒生世界2017年第6期》

以上就是关于企业建立支持数字化转型的组织架构，IT部门应该如何应对全部的内容，包括:企业建立支持数字化转型的组织架构，IT部门应该如何应对、如何从“0”到“1”的设计业务架构、寻找架构师：从企业架构的角度看需求的满足等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！