什么是系统架构师-如何成为系统架构师

近年来，随着互联网尤其是移动互联网技术在各行各业的渗透逐步深入，部分传统行业也从最开始的排斥互联网到现在急迫的想拥抱互联网，努力学习互联网思维，学习互联网技术，希望借助互联网技术来完成企业的转型或者升级。而互联网应用的发展，在“以用户为中心”理念的指引下，带来的最直接变化便是用户需求的升级，一方面来自被动接收的用户需求升级，另外一方面来自企业主动提供服务满足用户需求的服务升级。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期》

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：某电子产品生产制造企业业务架构设计与实践案例》。

什么是系统架构师-如何成为系统架构师

系统架构师是在某一个技术领域有深刻专研的技术达人还是在技术面上涉猎广泛的通才抑或有个五六年的工作经验之后就自动变成了“架构师”相信下面的文章对你的疑惑有所帮助!

新入门或没有架构设计经验的程序员刚开始的时候会有种不知所措的感觉，但其实架构设计是件很容易的事，它只是软件系统开发中的一个环节而已，整个软件系统的开发和维护以及变更还涉及到很多事情，包括技术、团队、沟通、市场、环境等等。

虽然架构设计是件容易的事情，但也不是大多数没有架构设计经验的程序员想象中的画画框图那么简单。把几台服务器一摆，每一台服务器运行什么软件分配好，然后用网络连接起来，似乎每个企业级应用都是如此简间单单的几步。

但现实生活中的软件系统实实在在可以用复杂大系统来形容，从规划、开发、维护和变更涉及到许许多多的人和事。架构设计就是要在规划阶段都把后面的事情尽量把握进来，要为稳定性努力，还要为可维护性、扩扩展性以及诸多的性能指标而思前想后。除了技术上的考虑，还要考虑人的因素，包括人员的组织、软件过程的组织、团队的协作和沟通等。

另外，架构设计还需要方法论的指导。这些方法论的思路包括，至上而下的分析，关注点分离，横向/纵向模块划分等。

有时候觉得架构设计决策就像是浏览Google Earth，实际上反映的是一种自上而下的决策过程。对问题的分解是软件思维的基本素质，可以有横向分解、纵向分解以及两者的结合。能不能有效快速准确的分解问题，是软件开发人员需要首先训练的项目。

另外，架构设计中图形化的工具非常有用，它能把系统的结构和运作机制以图形化的方式表达出来。也正因为这样才有了架构设计就是画框图的误会。再者，架构设计是一个工程性质的工作，对当事人的实际从业经验要求较高。只有对市场上的各种技术有较全面的了解之后才有可能设计出一个尽可能满足各种设计约束的架构。

在架构师需要具备的能力上，架构师首先必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。

另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进(重构)方案(也就是通常说的反模式)。这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。

在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信(对象访问、函数调用、数据交换、线程同步等)以及进程外(包括跨计算机)的通信(如RMI、DCOM、Web Service)。

在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图;而进程内的通信是模块实现的骨架，它是基石的基石。如果具体到一个基于Net企业级架构设计，首先需要的是语言级别的认识，包括NET的CLR、继承特性、委托和事件处理等。

然后是常用解决方案的认识，包括ASPNET Web Service、NET Remoting、企业服务组件等。总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。

其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。

有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。

这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。

再次，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。

大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。

另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。

另外，架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。

但对新技术的探索应该在一个理性的`范围内进行，不能盲目的跟风。解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。

但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。对于新东西需要以一种比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。

另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。

构架师不是通过理论学习可以搞出来的，不学习并且亲自实践相关知识肯定是不行的。就像前面说到的，架构设计是一个工程性质的事情，只有在不断实践的基础上才能逐渐熟悉起来。

实践的内容并不是去深挖各种语言的特性，因为系统架构师是设计应用系统架构而不是设计语言(除非你是要实现DSL)。更多的时候需要带着一种比较的眼光去实践，把不同的实现方式下的优缺点做个总结，做到自己心里有数，等具体的上下文环境下才好判断采用什么样的方式方法。

把基础打牢的同时掌握一定的方法，架构设计不是想象中的那么难。 ;

不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。

比如希赛推的ADMEMS架构体系，分为以下几种视图：

1 数据架构：描述数据的存储结构、格式等方面。

2 物理架构：描述机器的物理部署、网络拓扑方面。

3 运行架构：描述运行期线程、进程间的交互工作机制。

4 逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。

5 开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。

目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。

想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。

另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。像SAP、Oracle ERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。

当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。

总的来说，一说到架构，如果你懂软件，那么你会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务。。。但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及他们如何链接在一起。我倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。而采取分离式设计时，最容易的错误就是各自为政，集成困难。那么以数据为中心的架构设计，会自然提供集成的基础。我提到过，企业最重要的资产是数据，甚至不是信息，是数据。企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。这有点象自然演进，考古那种，啥都会消失，唐朝可以无比先进，但都会变，我们唯有找到反映当时情况的数据，才可以把握当思的面貌。

系统架构设计师属于软考高级资格考试，系统架构设计师综合知识科目在上午考试，考试题型为客观选择题，满分为75分，考试时间为9:00-11:30。

软考高级系统架构设计师上午考试科目为综合知识，满分为75分，题型为客观选择题。根据系统架构设计师考试大纲，综合知识科目考试范围如下：

1计算机软件与网络基础知识；

11 *** 作系统；

*** 作系统的类型和结构；

*** 作系统基本原理；

网络 *** 作系统及网络管理；

嵌入式 *** 作系统与实时 *** 作系统；

12 数据库系统；

数据库管理系统的类型、结构和性能评价；

常用的关系型数据库管理系统；

数据库模式；

数据库规范化；

分布式数据库系统，并行数据库系统；

数据仓库与数据挖掘技术；

数据库工程；

备份恢复；

13 嵌入式系统；

嵌入式系统的特点；

嵌入式系统的硬件组成与设计；

嵌入式系统应用软件及开发平台；

嵌入式系统网络；

嵌入式系统数据库；

14 数据通信与计算机网络；

数据通信的基本知识；

开放系统互连参考模型；

常用的协议标准；

网络互连与常用网络设备；

计算机网络的分类与应用；

15 多媒体；

多媒体的类型、特点及数据格式；

多媒体数据的压缩编码；

16 系统配置与性能评价；

多层结构、分布式系统；

系统配置方法（双份、双重、热备份、容错、集群）；

性能计算（响应时间、吞吐量、TAT）性能设计（系统调整、Amdahl 解决方案、响应特性、负载均衡）；

性能指标（SPEC-Int、SPEC-Fp、TPC、Gibsonmix、响应时间）；

性能评估；

2信息化基础知识；

21 信息系统工程总体规划；

总体规划目标、范围；

总体规划的方法论；

信息系统的组成；

信息系统的实现；

22 政府信息化与电子政务；

电子政务的概念、内容和技术形式；

中国政府信息化的策略和历程；

电子政务建设的过程模式和技术模式；

23 企业信息化与电子商务；

企业信息化的概念、目的、规划、方法；

ERP 的主要模块和主要算法；

企业业务流程重组（BPR）CRM、PDM 在企业的应用；

知识管理；

企业应用集成；

全程供应链管理的思想；

商业智能；

电子商务的类型、标准；

24 信息资源管理；

25 国际和国内有关信息化的标准、法律和规定；

3系统开发基础知识；

31 开发管理；

项目的范围、时间、成本；

文档管理工作、配置管理；

软件开发的质量与风险；

软件的运行与评价；

32 需求管理；

需求变更；

需求跟踪；

需求变更风险管理；

33 软件开发方法；

软件开发生命周期；

软件开发模型（瀑布模型、演化模型、增量模型、螺旋模型、原型，构件组装模型、RUP，敏捷方法）；

构件与软件重用；

逆向工程；

形式化方法；

34 软件开发环境与工具；

集成开发环境；

开发工具（建模工具、分析设计工具、编程工具、测试工具、项目管理工具等）；

35 设计方法；

分析设计图示（DFD、ERD、UML、流程图、NS 图、PAD）结构化分析与设计；

模块设计；

面向对象的分析与设计；

I/O 设计、人机界面设计；

设计模式；

36 基于构件的开发；

构件的概念与分类；

中间件技术；

典型应用架构（J2EE、NET）；

37 应用系统构建；

应用系统设计与开发（分析与设计方法的使用、外部设计、内部设计、程序设计、测试）；

软件包的使用（开发工具、运行管理工具、业务处理工具、ERP、群件、OA工具）；

38 测试与评审；

测试评审方法；

验证与确认（V&V）测试自动化；

测试设计和管理方法；

4软件架构基础知识；

软件架构的概念；

软件架构的风格；

特定领域软件架构；

基于架构的软件开发方法；

软件架构评估；

软件产品线；

设计模式；

5安全性与可靠性技术；

41 信息安全与保密；

加密和解密；

身份认证（数字签名、密钥、口令）；

访问控制；

安全保密管理（防泄漏、数字水印）；

安全协议（SSL、PGP、IPSec）系统备份与恢复；

防治病毒；

42 系统可靠性；

可靠性设计（容错技术、避错技术）；

可靠性指标与评估；

43 安全性规章与保护私有信息规则；

信息系统安全法规与制度；

计算机防病毒制度；

保护私有信息规则；

6标准化与知识产权；

标准化意识，标准化的发展，标准的的生命周期；

国际标准、美国标准、标准、行业标准、地方标准、企业标准；

代码标准、文件格式标准、安全标准、软件开发规范和文档标准；

标准化机构；

知识产权；

7应用数据；

概率统计应用；

图论应用；

组合分析；

算法（数值算法与非数值算法）的选择与应用；

运筹方法（网络计划技术、线性规划、预测、决策、库存管理、模拟）；

数学建模；

8专业英语；

具有高级工程师所要求的英文阅读水平；

掌握本领域的英语术语。

温馨提示：因考试政策、内容不断变化与调整，猎考网提供的以上信息仅供参考，如有异议，请考生以权威部门公布的内容为准！

下方免费复习资料内容介绍：2018年系统架构设计师上午真题汇总

格式：PDF大小：4763KB 希赛2021系统分析师考前必备4页纸（内部资料）

格式：PDF大小：165525KB

资格考试有疑问、不知道如何总结考点内容、不清楚报考考试当地政策，点击底部咨询猎考网，免费领取复习资料

《高并发Oracle数据库系统的架构与设计》（侯松）电子书网盘下载免费在线阅读

链接：> 提取码：MEDB  

书名 ：高并发Oracle数据库系统的架构与设计

豆瓣评分：

作者: 侯松

出版社： 机械工业出版社

出版年: 2014-11-1

页数: 388

内容简介：

这是国内第一本深度讲解如何架构与设计高并发Oracle数据库系统的著作，也是国内第一本系统讲解内存数据库TimesTen的专著。作者是拥有10余年Oracle从业经验的资深数据库架构师，本书的内容也得到了业界以盖国强为代表的数位数据库专家的一致认可。本书秉承大道至简的思想，技术与艺术并重，从技术、方法论、原理和思想等角度讲解了如何架构与设计高并发Oracle数据库系统。

全书主要内容从三个维度展开：首先是内部扩展的维度，深入探讨了高效B树索引、高效表设计、查询优化器等数据库架构设计与优化的核心技术，以及高并发Oracle数据库系统架构与设计的方法论和常见的高并发案例；其次是纵向扩展的维度，国内首次详细讲解了内存数据库TimesTen的基本使用、高可用架构设计、缓存应用、监控方法、数据备份与恢复、数据迁移以及高并发场景；最后是横向扩展的维度，详细讲解了

作者简介 ：

侯松（网名：麻袋爸爸）

资深数据库架构师、PMP、北美寿险管理师，现就职于中国平安保险集团，拥有10余年数据库开发、管理和运维经验。精通Oracle数据库相关技术，掌握ITIL运维体系，擅长金融行业（银行、保险、投资）的项目管理和数据库系统的架构设计，有世界500强IT团队管理与大型项目管理的经验。活跃于ITPUB等技术社区，2013年中国数据库大会演讲嘉宾。个人网站：>

以上就是关于寻找架构师：从企业架构的角度看需求的满足全部的内容，包括:寻找架构师：从企业架构的角度看需求的满足、如何从“0”到“1”的设计业务架构、什么是系统架构师-如何成为系统架构师等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！