IT系统架构师课件.ppt

《IT系统架构师课件.ppt》由会员分享，可在线阅读，更多相关《IT系统架构师课件.ppt（69页珍藏版）》请在三一办公上搜索。

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

2、它可以把复杂的系统简单化它可以分析需要的功能, 从而找出需要的模块它提供了建设具体物理系统的基础它定义如何连接系统各个部分的结构和策略它提供组合以及拆散系统元素或模块的规则它帮助分析系统非功能性的需求从而设计达到这些要求的方案它提供了做架构决策的记录,从而可以在未来进一步扩展系统功能,系统架构思考方式它可以把复杂的系统简单化,优秀IT系统架构师的诀窍,永远都把自己放在不断学习新东西的位置。 (my experience)寻求最好的团队一起工作。不但你所参加的项目成功机会大, 而且在团队中学到更多的东西。不断学习的心态可使你成为一个优秀的系统架构师。即使你不想成为系统架构师, 也可以成为一名优秀

3、的技术骨干, 从而增加你在团队中的价值。,优秀IT系统架构师的诀窍永远都把自己放在不断学习新东西的位置,成功的架构师必备的特征,沟通的能力(communication)富有激情地去做自己需要做的事情(passion)判断别人的能力和做事的特性(character)技术知识和能力，了解技术发展趋势(technical trend)对一两个技术方向具备精深的掌握。(technical specialty)行业知识(industry knowledge)了解客户, 明白客户需求从客户的角度思考和理解具备很好的个人,销售,场景和能力技能(4 quadrant skills)最重要的是具备结果导向的执行

4、能力(result-oriented approach),成功的架构师必备的特征沟通的能力(communication,如何沟通 增加销售说服力,如何沟通 增加销售说服力,如何定义“系统架构”?,IBM Architectural Description Standard (ADS)定义:IT系统架构是一种包括软件和硬件模组的结构。它描述了这些模组对外的接口属性以及模组之间自身的关系.F. Brooks & W. Buchholz in Planning Computer Systems:Computer architecture, like other architecture, is th

5、e art of determining the needs of the userand then designing to meet those needs as effective as possible.IT目前比较接受的定义:IT系统架构师通过使用合理的IT技术来制定解决客户商业问题的方案。这个方案是通过系统管理架构来展示和描述的, 它包括系统, 应用和应用模组之间的流程。类似一个建筑设计师, IT系统架构师的工作是侧重于方案设计阶段的工作。在方案实施过程中, 系统架构师扮演了一个与客户沟通的桥梁, 确认系统是按照所规划的架构来实施的, 并且对施工方提供技术指导和引导.,如何定义“系

6、统架构”?IBM Architectural D,归纳一下,系统架构师是个什么样的人?实际做事的人不同意见和选择的协调人结果导向的知识广而多, 而不是少而精是个技术专家是一个产品专家, 但知道产品的能力不是项目经理不仅仅是个设计高手绝对不是个孤独的思想家,对于系统架构的误解(myths)系统架构和系统设计是一回事架构和基础结构是一回事系统架构等同于硬件组合好的系统架构是靠一个架构师独立做出来的系统架构凌驾于软件架构之上架构是不可以衡量和确认的架构是门科学架构是技术, 基础结构, 数据和网络的组合,归纳一下系统架构师是个什么样的人?对于系统架构的误解(myt,架构决策决定于要解决的问题和涉及到的

7、方面,架构决策决定于要解决的问题和涉及到的方面,什么是系统思考? (System Thinking),什么是系统思考? (System Thinking),系统和系统架构思考,系统性思考是一种架构设计过程,为了解各个部分是如何工作的它是被人们认为在事件的背后, 寻找事件和功能的模式从而找出系统之间负责功能模式和事件的关系系统性思考是为了阐述一种宏观的看法。宏观的看法是要代表如何解释系统组件之间关系的最基本基础负责系统之间的关系以及方式系统之间的关系使得我们可以理解不同事件的处理模式选择系统的边缘界线有助于理解系统之间的互动如何系统边缘的定义或选择是错的话, 我们的理解就会受阻思考的方法是循环性

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

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

10、个或多个接口达到的 子系统 任何一种在IT系统里组件的组合组件协同使用(collaboration) 使用场景的代表, 它的实现是通过多个组件按一定顺序使用来达到的组件互动(interaction) 代表两个组件之间的交互,通过接口来执行的.,部署方面的架构节点 架构中的物理单元, 软件在其之上运行连接 代表节点与节点之间的物理连接, 如局域网, 广域网等部署单元 代表一个或多个组件, 共同部署在同一个节点上部署单元的执行, 状态和部署三个方面都可以是分开来考虑的(execution, state, installation),IT架构设计使用的语言功能方面的架构部署方面的架构,描述和标示架构

11、方法,描述和标示架构方法,描述和标示架构方法,4+1视图,描述和标示架构方法4+1视图,逻辑视图（Logic View）,逻辑视图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（Problem Definition)。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。如下图: 构件(Components)：类、类服务、参数化类、类层次连接件(Connectors)：关联、包含聚集、使用、继承、实例化,逻辑视图（Logic Vi

12、ew）逻辑视图主要是用来描述系统的,开发视图(Development/Module View),开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编程人员， 方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：Java SDK，图像处理软件包）。,开发视图(Development/Module View)开,进程视图,进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调

13、并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。,进程视图 进程试图侧重系统的运行特性，关注非功能性的需求（性,物理视图,物理视图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。,物理视图物理视图主要描述硬件配置。服务于系统工程人员，解决系,场景(Scenarios),场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系

14、。文本、图形表示皆可。,场景(Scenarios) 场景用于刻画构件之间的相互关系，,IT架构设计方法,IT架构设计方法,Asset-based设计与其他方法比较,One-of-a-kind设计方法每次都从头开始设计，耗用大量人力Systematic-use-of-assets设计每次仅利用系统概念Asset-based设计方法，每次最大可能地重用资产，可以最大地节约成本，扩大利润必须采用Asset-based设计方法，以保障市场竞争力,Asset-based设计与其他方法比较One-of-a-k,Asset-based设计方法,知识资产（Assets） 资产必须基于通用方法描述（ADS） 公

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

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

17、目成功因素有一个与客户达成共识的决策基础。在项目执行过程中, 许多决定都要基于这个基础定义了如何衡量项目是否成功的标准每一个跟项目相关的团队成员都应该对项目目标有共识。这对项目执行过程中涉及到问题的解决事关重要,项目描述与目标与客户共同制定客户的要达到的最终目标, 宏观远,业务关系图,业务关系图是用来描述一个IT方案涉及到的业务范围以及范围内的业务内容。并且也描述这个范围内的内容和其它相关联业务方面的关系。这些业务单元之间的关系解释了它们之间的信息是如何流通的以及通过何种手段流通的。对这些问题的明白和理解才能使架构师知道要建设的系统在业务中的位置，从而更好地满足业务需求。另外, 业务关系图还提

18、供:业务单元之间所发生的事件。这会对系统模块之间接口的制订有很大的帮助它也提供了一个框架, 使我们可以获取业务范围内的流程以及它们之间的业务“界面”, 从而明白这些流程背后的理由和原因具体描述需要建设系统所要覆盖的业务范围。不同的业务关系图可以用来和客户沟通讨论。这也是确认最终系统实施范围的关键依据和步骤。讨论的结果包括哪些业务功能是在项目范围之内的, 哪些业务功能是在范围之外的, 以及哪些是潜在未来的业务需求。,业务关系图业务关系图是用来描述一个IT方案涉及到的业务范围以,IT技术遵循标准与目前IT系统环境,IT技术遵循的标准文档具体列举了所有项目必须遵循的标准和使用的技术, 甚至具体的产品

19、. 这些标准可能是来自之前的工作, 企业内部的IT规范. IT标准总是存在的, 无论是公开的还是不言而喻的.这些事实的记录会帮助IT架构师规划系统方案架构.这个文档也记录了在方案规划或者执行过程中要绕过这些IT标准的理由和原因另外, 任何系统模块还没有标准遵循时, 这种信息也要记录下来.这是为了将来这些实施的标准可以变成企业IT标准目前系统环境文档是个系统清单, 包括硬件, 软件和其它IT功能环境,如防火墙, 网络地址分配,等等,IT技术遵循标准与目前IT系统环境IT技术遵循的标准文档具体,可行的 vs. 不可行的,可行的 vs. 不可行的,人-机分工平衡以取综合最优,人-机分工平衡以取综合最

20、优,2022/11/4,35,可编辑,THANK YOUSUCCESS2022/10/93,非功能需求,非功能需求用来:针对要建设的IT系统, 定义关键系统特征和限制要求.用来估算系统容量和成本评估系统的可行性和生存能力用于系统部署模型的重要依据非功能需求经常是系统架构的重要因素之前描述的非功能性需求是用这个工作文件记录下来的,非功能需求非功能需求用来:,可行性分析,可行性分析报告是探讨, 解释和描述建议的方案是否可行。编写可行性报告的过程就是思考和组织建议方案的不同部分。可行性分析经常是针对某部分系统需求, 功能或某种技术的使用。可行性分析也是用来找出潜在可能存在的问题和风险. 这对与客户沟

21、通以及架构师设计时都是一个重要方面。可行性报告应该是不断更新和审核的. 同时它是作为质量保证审核以及实施计划的重要依据。,可行性分析可行性分析报告是探讨, 解释和描述建议的方案是否可,可行性分析举例,使用不同的颜色(红/黄/绿)来标示不同程度的问题不要把风险, 问题, 假设和依赖因素混为一谈提早从客户获取信息进行风险分析例如, 如果客户不提供所需要的资料或信息, 这个问题带来的风险是高的. 可以有依据向客户尽早获取资料,可行性分析举例使用不同的颜色(红/黄/绿)来标示不同程度的问,系统运行模型,提供宏观的系统逻辑运行架构, 用来理解整体系统是如何满足业务需求的用来考虑系统主要基础架构是如何部署

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

23、系统运行模型图举例,系统节点描述,系统运行模型图举例系统节点描述,Q & A,Q & A,IT Infrastructure 架构设计,逻辑层面的运营架构模型规范层面的运营架构模型物理层面的运营架构模型总结,IT Infrastructure 架构设计逻辑层面的运营架,运营架构模型八步规划法,八步法是按顺序来讲的. 但在实际制作过程中, 有些步骤是同步进行的或重复使用的.是否是这种情况决定于限定因素或条件, 以及是否使用参考架构在做每一步时, 关键的非功能性需求对架构模型的影响一定要不断核实系统可用性, 性能, 系统管理, 安全这个做法也包括如何制作以下工作文档:部署单元更新的架构决定可行性报

24、告,运营架构模型八步规划法八步法是按顺序来讲的. 但在实际制作,第一步:找出业务功能的位置和区域,信息来自于：业务角色和位置系统关系图目前IT环境,第一步:找出业务功能的位置和区域信息来自于：,第二步: 找出逻辑节点,第二步: 找出逻辑节点,逻辑节点举例,逻辑节点举例,第三步: 为了满足系统管理需求的特殊逻辑节点,第三步: 为了满足系统管理需求的特殊逻辑节点,第四,五,六步: 找出展示, 执行和数据部署节点,第四,五,六步: 找出展示, 执行和数据部署节点,第七步: 找出需要的连接节点,第七步: 找出需要的连接节点,第八步: 回顾目前所达到的结果,第八步: 回顾目前所达到的结果,建议以场景进行

25、验证,建议以场景进行验证,IT系统架构师课件,IT Opertion 架构设计,逻辑层面的运营架构模型规范层面的运营架构模型物理层面的运营架构模型总结,IT Opertion 架构设计逻辑层面的运营架构模型,规范架构是把逻辑架构改变成一个技术规范架构,技术规范架构过程在限制因素范围内和满足非功能需求的前提下, 找出必要的技术需求和功能服务用来提供业务功能考虑一些不同的选择或方法满足同样的需求, 进行选择平衡, 对目前的架构做适当的修改设计逻辑技术连接评估目前架构的可行性, 对相关的架构文档进行更新,规范架构是把逻辑架构改变成一个技术规范架构技术规范架构过程,输入-组件模型, 非功能需求, 用户

26、需求和逻辑模型,输入-组件模型, 非功能需求, 用户需求和逻辑模型,寻找技术规范节点,系统管理考虑不同节点是如何运作的监控(系统状况监控, 性能监控, 可用性监控)任务执行(开机, 关机, 日志控制, 配置控制等等)安装, 配置,变更管理数据分布, 同步, 备份, 回复系统使用以管理记录问题处理做法从每个节点, 层次, 位置和整体方案角度找出不同系统管理的考虑因素找出每个涉及到系统管理流程和数据存储的节点在不同层次和区域中找出其它涉及到系统管理和数据存储的节点,寻找技术规范节点系统管理考虑,参考架构是逻辑和技术架构的结合,参考架构是逻辑和技术架构的结合,IT Infrastructure 架构

27、设计,逻辑层面的运营架构模型规范层面的运营架构模型物理层面的运营架构模型总结,IT Infrastructure 架构设计逻辑层面的运营架,物理架构模型描述技术规范架构,物理架构模型是通过下面的五步做出来的:找出需要使用的硬件和软件描述软件和硬件的配置方案, 从而满足功能和非功能的需求确认和验证所选的硬件和软件是可以满足需求的描述应该如何管理这些所配置的硬件和软件评估所设计的完整方案的可行性, 并且记录所做的架构决定,物理架构模型描述技术规范架构物理架构模型是通过下面的五步做出,物理架构里包含什么,物理节点硬件所有硬件具体配置软件软件产品的配置和版本, 如WebSphere Applicati

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