IT系统架构师课件.ppt

1、IT系统架构师培训计划系统架构师培训计划启发性的问题回答以下问题：什么是系统架构?为什么系统架构重要?在一个项目里为什么需要系统架构?系统架构师的角色是什么?谁是在一个项目里对系统架构要负责任的?谁是负责系统架构文档资料的?一般来说,用什么样的图或模型来表示系统架构?什么是系统架构思维?IT架构师的侧重点 IT架构师负责提供如何利用IT技术帮助一个企业或组织开展业务和支持业务发展 系统架构师侧重于如何架构支持业务系统实现的IT基础设施 IT产品专家侧重于产品开发和项目的实施系统架构思考方式 它可以把复杂的系统简单化 它可以分析需要的功能,从而找出需要的模块 它提供了建设具体物理系统的基础 它定

2、义如何连接系统各个部分的结构和策略 它提供组合以及拆散系统元素或模块的规则 它帮助分析系统非功能性的需求从而设计达到这些要求的方案 它提供了做架构决策的记录,从而可以在未来进一步扩展系统功能优秀IT系统架构师的诀窍 永远都把自己放在不断学习新东西的位置。(my experience)寻求最好的团队一起工作。不但你所参加的项目成功机会大,而且在团队中学到更多的东西。不断学习的心态可使你成为一个优秀的系统架构师。即使你不想成为系统架构师,也可以成为一名优秀的技术骨干,从而增加你在团队中的价值。成功的架构师必备的特征l 沟通的能力(communication)l 富有激情地去做自己需要做的事情(pa

3、ssion)l 判断别人的能力和做事的特性(character)l 技术知识和能力，了解技术发展趋势(technical trend)l 对一两个技术方向具备精深的掌握。(technical specialty)l 行业知识(industry knowledge)了解客户,明白客户需求 从客户的角度思考和理解l 具备很好的个人,销售,场景和能力技能(4 quadrant skills)l 最重要的是具备结果导向的执行能力(result-oriented approach)如何沟通 增加销售说服力如何定义“系统架构”?IBM Architectural Description Standard(

4、ADS)定义:IT系统架构是一种包括软件和硬件模组的结构。它描述了这些模组对外的接口属性以及模组之间自身的关系.F.Brooks&W.Buchholz in Planning Computer Systems:Computer architecture,like other architecture,is the art of determining the needs of the userand then designing to meet those needs as effective as possible.IT目前比较接受的定义:IT系统架构师通过使用合理的IT技术来制定解决客户商

5、业问题的方案。这个方案是通过系统管理架构来展示和描述的,它包括系统,应用和应用模组之间的流程。类似一个建筑设计师,IT系统架构师的工作是侧重于方案设计阶段的工作。在方案实施过程中,系统架构师扮演了一个与客户沟通的桥梁,确认系统是按照所规划的架构来实施的,并且对施工方提供技术指导和引导.归纳一下系统架构师是个什么样的人?实际做事的人不同意见和选择的协调人结果导向的知识广而多,而不是少而精是个技术专家是一个产品专家,但知道产品的能力不是项目经理不仅仅是个设计高手绝对不是个孤独的思想家对于系统架构的误解(myths)系统架构和系统设计是一回事架构和基础结构是一回事系统架构等同于硬件组合好的系统架构是

6、靠一个架构师独立做出来的系统架构凌驾于软件架构之上架构是不可以衡量和确认的架构是门科学架构是技术,基础结构,数据和网络的组合架构决策决定于要解决的问题和涉及到的方面什么是系统思考?(System Thinking)系统和系统架构思考系统性思考是一种架构设计过程,为了解各个部分是如何工作的它是被人们认为在事件的背后,寻找事件和功能的模式从而找出系统之间负责功能模式和事件的关系系统性思考是为了阐述一种宏观的看法。宏观的看法是要代表如何解释系统组件之间关系的最基本基础 负责系统之间的关系以及方式 系统之间的关系使得我们可以理解不同事件的处理模式选择系统的边缘界线有助于理解系统之间的互动如何系统边缘的

7、定义或选择是错的话,我们的理解就会受阻思考的方法是循环性的,架构师要学会如何调整系统边缘,从而更深理解整体系统架构设计的思考是基于以下几方面建立在系统思考之上的:使用从上到下和满足需求的方法 有能力把一堆乱麻整理成清晰的线条 利用结构来确认系统需求是可以满足的系统架构思考支持系统架构把复杂的系统简单化分析需要的功能,从而找出需要的模块建设具体物理系统的基础定义如何连接系统各个部分的结构和策略提供组合以及拆散系统元素或模块的规则帮助分析系统非功能性的需求并设计达到这些要求的方案提供了架构决策的记录,可在未来进一步扩展系统功能从不同的角度看IT架构思维IT架构概念可以想成是某种程度的提炼和封装(h

8、iding of details)把在一定场景或状况下的细节隐藏起来。一旦场景发生变化,所要隐藏的细节也会改变IT架构设计需要考虑多方面的因素和质量。但经常这些质量之间会有冲突。因此决定架构时,我们要不断进行选择平衡(trade-off)从不同角度看IT架构时,都会觉得需要改变。这是自然的因为任何一个角度看都只是一种架构的表示而已.所以,IT架构思考涉及到内容输入,思考和结果输出IT架构设计使用的语言功能方面的架构组件 它是软件功能单元。它的使用是通过一个或多个接口达到的 子系统 任何一种在IT系统里组件的组合组件协同使用(collaboration)使用场景的代表,它的实现是通过多个组件按一

9、定顺序使用来达到的组件互动(interaction)代表两个组件之间的交互,通过接口来执行的.部署方面的架构节点 架构中的物理单元,软件在其之上运行连接 代表节点与节点之间的物理连接,如局域网,广域网等部署单元 代表一个或多个组件,共同部署在同一个节点上 部署单元的执行,状态和部署三个方面都可以是分开来考虑的(execution,state,installation)描述和标示架构方法描述和标示架构方法 4+1视图逻辑视图（逻辑视图（Logic View）逻辑视图主要是用来描述系统的功描述系统的功能需求能需求，即系统提供给最终用户最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象、功能分

10、解与功能分析，这些主要来自问题领域（Problem Definition)。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。如下图:构件构件(Components)：类、类服务、参数化类、类层次 连接件连接件(Connectors)：关联、包含聚集、使用、继承、实例化 开发视图开发视图(Development/Module View)开发视图主要用来描述软件模块描述软件模块的组织与管理的组织与管理（通过程序库或子系统）。服务于软件编程人员编程人员，方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。

11、要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：Java SDK，图像处理软件包）。进程视图进程视图 进程试图侧重系统的运运行特性行特性，关注非功能性的需求（性能，可用性）。服务于系统集成系统集成人员人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。物理视图物理视图 物理视图主要描述硬件配置描述硬件配置。服务于系统工系统工程人员程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬

12、件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。场景场景(Scenarios)场景用于刻画构件之间的相互关系刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。文本、图形表示皆可。IT架构设计方法Asset-based设计与其他方法比较 One-of-a-kind设计方法每次都从头开始设计，耗用大量人力 Systematic-use-of-assets设计每次仅利用系统概念 Asset-based设计方法，每次最大可能地重用资产，可以最大地节约成本，扩大利润 必须采用Asset-based设计方法，以保障市场竞争

13、力Asset-based设计方法知识资产（Assets）资产必须基于通用方法描述（ADS）公司必须有一组通用的Assets 公司必须知道怎样得到Assets 技能（Skills）ITA必须具有技能将知识资产与客户需求对应，形成解决方案方法论（Methods）方法论是怎样重用Assets的规则只有遵循统一的方法论才能有效地重用Assets 只有遵循统一的方法论才能有效地建立Assets 架构设计方法论及工作文档架构文档分类架构设计交付必须的文档业务分析工作文档 项目描述 信息来源:客户访谈,标书内容 价值:基本信息。帮助了解项目概况以及要解决的业务问题 业务的目标 信息来源:客户访谈,与客户业务

14、部门交流,标书内容 价值:对架构师非常重要,对说服客户内部也是重要的 业务关系图 信息来源:你自己或是别人对这个客户业务的分析 价值:对架构师非常重要,对客户有时也是重要的 遵循的IT标准 信息来源:客户访谈,与客户IT部门交流,标书内容,你的建议 价值:基本约束。决定了建议的方案架构是否被客户拒绝 目前客户IT环境 信息来源:客户访谈,与客户IT部门交流,标书内容,客户IT文档 价值:基本知识。帮助你设计方案架构,帮助客户理解你的架构理由项目描述与目标 与客户共同制定客户的要达到的最终目标,宏观远景,和关键项目成功因素 有一个与客户达成共识的决策基础。在项目执行过程中,许多决定都要基于这个基

15、础 定义了如何衡量项目是否成功的标准 每一个跟项目相关的团队成员都应该对项目目标有共识。这对项目执行过程中涉及到问题的解决事关重要业务关系图 业务关系图是用来描述一个IT方案涉及到的业务范围以及范围内的业务内容。并且也描述这个范围内的内容和其它相关联业务方面的关系。这些业务单元之间的关系解释了它们之间的信息是如何流通的以及通过何种手段流通的。对这些问题的明白和理解才能使架构师知道要建设的系统在业务中的位置，从而更好地满足业务需求。另外,业务关系图还提供:业务单元之间所发生的事件。这会对系统模块之间接口的制订有很大的帮助 它也提供了一个框架,使我们可以获取业务范围内的流程以及它们之间的业务“界面

16、”,从而明白这些流程背后的理由和原因 具体描述需要建设系统所要覆盖的业务范围。不同的业务关系图可以用来和客户沟通讨论。这也是确认最终系统实施范围的关键依据和步骤。讨论的结果包括哪些业务功能是在项目范围之内的,哪些业务功能是在范围之外的,以及哪些是潜在未来的业务需求。IT技术遵循标准与目前IT系统环境 IT技术遵循的标准文档具体列举了所有项目必须遵循的标准和使用的技术,甚至具体的产品.这些标准可能是来自之前的工作,企业内部的IT规范.IT标准总是存在的,无论是公开的还是不言而喻的.这些事实的记录会帮助IT架构师规划系统方案架构.这个文档也记录了在方案规划或者执行过程中要绕过这些IT标准的理由和原

17、因 另外,任何系统模块还没有标准遵循时,这种信息也要记录下来.这是为了将来这些实施的标准可以变成企业IT标准 目前系统环境文档是个系统清单,包括硬件,软件和其它IT功能环境,如防火墙,网络地址分配,等等可行的 vs.不可行的人-机分工平衡以取综合最优THANK YOUSUCCESS2023-1-1可编辑非功能需求 非功能需求用来:针对要建设的IT系统,定义关键系统特征和限制要求.用来估算系统容量和成本 评估系统的可行性和生存能力 用于系统部署模型的重要依据 非功能需求经常是系统架构的重要因素之前描述的非功能性需求是用这个工作文件记录下来的可行性分析 可行性分析报告是探讨,解释和描述建议的方案是

18、否可行。编写可行性报告的过程就是思考和组织建议方案的不同部分。可行性分析经常是针对某部分系统需求,功能或某种技术的使用。可行性分析也是用来找出潜在可能存在的问题和风险.这对与客户沟通以及架构师设计时都是一个重要方面。可行性报告应该是不断更新和审核的.同时它是作为质量保证审核以及实施计划的重要依据。可行性分析举例 使用不同的颜色(红/黄/绿)来标示不同程度的问题 不要把风险,问题,假设和依赖因素混为一谈 提早从客户获取信息进行风险分析 例如,如果客户不提供所需要的资料或信息,这个问题带来的风险是高的.可以有依据向客户尽早获取资料系统运行模型 提供宏观的系统逻辑运行架构,用来理解整体系统是如何满足

19、业务需求的用来考虑系统主要基础架构是如何部署的以及系统组件应该如何部署 用来确认客户对系统实施的倾向和限制因素 用来执行早期的系统基本功能的流程执行验证(walk-through)基于以上几个方面,用来考虑系统的非功能性需求应该如何满足 用来选择实施系统组件功能的产品或应用,衡量它们的可用性 用来估算相关系统硬件和基础建设的成本 作为选择软件和硬件产品的选择基础系统运行模型图举例 用来估算硬件的成本及软件license的数量系统运行模型图举例 系统LPAR的节点配置方案系统运行模型图举例 系统节点描述Q&AIT Infrastructure 架构设计 逻辑层面的运营架构模型 规范层面的运营架构

20、模型 物理层面的运营架构模型 总结运营架构模型八步规划法八步法是按顺序来讲的.但在实际制作过程中,有些步骤是同步进行的或重复使用的.是否是这种情况决定于限定因素或条件,以及是否使用参考架构在做每一步时,关键的非功能性需求对架构模型的影响一定要不断核实 系统可用性,性能,系统管理,安全这个做法也包括如何制作以下工作文档:部署单元 更新的架构决定 可行性报告第一步:找出业务功能的位置和区域 信息来自于：业务角色和位置 系统关系图 目前IT环境第二步:找出逻辑节点逻辑节点举例第三步:为了满足系统管理需求的特殊逻辑节点第四,五,六步:找出展示,执行和数据部署节点第七步:找出需要的连接节点第八步:回顾目

21、前所达到的结果建议以场景进行验证IT Opertion 架构设计 逻辑层面的运营架构模型 规范层面的运营架构模型 物理层面的运营架构模型 总结规范架构是把逻辑架构改变成一个技术规范架构技术规范架构过程1.在限制因素范围内和满足非功能需求的前提下,找出必要的技术需求和功能服务用来提供业务功能2.考虑一些不同的选择或方法满足同样的需求,进行选择平衡,对目前的架构做适当的修改3.设计逻辑技术连接4.评估目前架构的可行性,对相关的架构文档进行更新输入-组件模型,非功能需求,用户需求和逻辑模型寻找技术规范节点 系统管理考虑 不同节点是如何运作的 监控(系统状况监控,性能监控,可用性监控)任务执行(开机,

22、关机,日志控制,配置控制等等)安装,配置,变更管理 数据分布,同步,备份,回复 系统使用以管理记录 问题处理 做法 从每个节点,层次,位置和整体方案角度找出不同系统管理的考虑因素 找出每个涉及到系统管理流程和数据存储的节点 在不同层次和区域中找出其它涉及到系统管理和数据存储的节点参考架构是逻辑和技术架构的结合IT Infrastructure 架构设计 逻辑层面的运营架构模型 规范层面的运营架构模型 物理层面的运营架构模型 总结物理架构模型描述技术规范架构物理架构模型是通过下面的五步做出来的:1.找出需要使用的硬件和软件2.描述软件和硬件的配置方案,从而满足功能和非功能的需求3.确认和验证所选

23、的硬件和软件是可以满足需求的4.描述应该如何管理这些所配置的硬件和软件5.评估所设计的完整方案的可行性,并且记录所做的架构决定物理架构里包含什么 物理节点 硬件 所有硬件具体配置 软件 软件产品的配置和版本,如WebSphere Application Server 6.0 具体描述软件的配置是如何来满足非功能性需求的,如WAS cluster,DB2主副配置等等 物理连接 包括网络连接模式和具体配置部分物理架构配置(home shopping)何确认物理架构的正确性 建制系统原型 使用系统测试工具统流程分别检验 执行关键系统流程的分检 根据之前制定的使用场景验证最终物理架构,特别是考虑到非功能需求 考虑当系统出现问题时应该如何处理 可以监测到问题吗?最终用户会收到通知吗?如何回复交易和数据 谁来修复系统 分析系统问题会如何影响服务水平协议的执行制定系统管理计划如何使用物理架构系统部署需要什么 具体系统细节的配置 具体系统操作规程 系统管理流程及规则 有技能的人员 系统移植方案,特别是数据移植方案以及人员培训小结 系统运营层面系统架构 描述部署单元的布置方法,从而满足系统非功能性需求 列举和考虑系统管理方面的方案因素 侧重于系统运营环境的考虑Q&ATHANK YOUSUCCESS2023-1-1可编辑