1IT系统架构师课件PPT文件格式下载.ppt

1IT系统架构师课件PPT文件格式下载.ppt

《1IT系统架构师课件PPT文件格式下载.ppt》由会员分享，可在线阅读，更多相关《1IT系统架构师课件PPT文件格式下载.ppt（67页珍藏版）》请在冰豆网上搜索。

什么是系统架构思维?

IT架构师的侧重点,IT架构师负责提供如何利用IT技术帮助一个企业或组织开展业务和支持业务发展系统架构师侧重于如何架构支持业务系统实现的IT基础设施IT产品专家侧重于产品开发和项目的实施,系统架构思考方式,它可以把复杂的系统简单化它可以分析需要的功能,从而找出需要的模块它提供了建设具体物理系统的基础它定义如何连接系统各个部分的结构和策略它提供组合以及拆散系统元素或模块的规则它帮助分析系统非功能性的需求从而设计达到这些要求的方案它提供了做架构决策的记录,从而可以在未来进一步扩展系统功能,优秀IT系统架构师的诀窍,永远都把自己放在不断学习新东西的位置。

（myexperience）寻求最好的团队一起工作。

不但你所参加的项目成功机会大,而且在团队中学到更多的东西。

不断学习的心态可使你成为一个优秀的系统架构师。

即使你不想成为系统架构师,也可以成为一名优秀的技术骨干,从而增加你在团队中的价值。

成功的架构师必备的特征,沟通的能力（communication）富有激情地去做自己需要做的事情（passion）判断别人的能力和做事的特性（character）技术知识和能力，了解技术发展趋势（technicaltrend）对一两个技术方向具备精深的掌握。

（technicalspecialty）行业知识（industryknowledge）了解客户,明白客户需求从客户的角度思考和理解具备很好的个人,销售,场景和能力技能（4quadrantskills）最重要的是具备结果导向的执行能力（result-orientedapproach）,如何沟通增加销售说服力,如何定义“系统架构”?

IBMArchitecturalDescriptionStandard（ADS）定义:

IT系统架构是一种包括软件和硬件模组的结构。

它描述了这些模组对外的接口属性以及模组之间自身的关系.F.Brooks&

W.BuchholzinPlanningComputerSystems:

Computerarchitecture,likeotherarchitecture,istheartofdeterminingtheneedsoftheuserandthendesigningtomeetthoseneedsaseffectiveaspossible.IT目前比较接受的定义:

IT系统架构师通过使用合理的IT技术来制定解决客户商业问题的方案。

这个方案是通过系统管理架构来展示和描述的,它包括系统,应用和应用模组之间的流程。

类似一个建筑设计师,IT系统架构师的工作是侧重于方案设计阶段的工作。

在方案实施过程中,系统架构师扮演了一个与客户沟通的桥梁,确认系统是按照所规划的架构来实施的,并且对施工方提供技术指导和引导.,归纳一下,系统架构师是个什么样的人?

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

（SystemThinking）,系统和系统架构思考,系统性思考是一种架构设计过程,为了解各个部分是如何工作的它是被人们认为在事件的背后,寻找事件和功能的模式从而找出系统之间负责功能模式和事件的关系系统性思考是为了阐述一种宏观的看法。

宏观的看法是要代表如何解释系统组件之间关系的最基本基础负责系统之间的关系以及方式系统之间的关系使得我们可以理解不同事件的处理模式选择系统的边缘界线有助于理解系统之间的互动如何系统边缘的定义或选择是错的话,我们的理解就会受阻思考的方法是循环性的,架构师要学会如何调整系统边缘,从而更深理解整体系统,架构设计的思考是基于以下几方面建立在系统思考之上的:

使用从上到下和满足需求的方法有能力把一堆乱麻整理成清晰的线条利用结构来确认系统需求是可以满足的,系统架构思考支持系统架构,把复杂的系统简单化分析需要的功能,从而找出需要的模块建设具体物理系统的基础定义如何连接系统各个部分的结构和策略提供组合以及拆散系统元素或模块的规则帮助分析系统非功能性的需求并设计达到这些要求的方案提供了架构决策的记录,可在未来进一步扩展系统功能,从不同的角度看IT架构思维,IT架构概念可以想成是某种程度的提炼和封装（hidingofdetails）把在一定场景或状况下的细节隐藏起来。

一旦场景发生变化,所要隐藏的细节也会改变IT架构设计需要考虑多方面的因素和质量。

但经常这些质量之间会有冲突。

因此决定架构时,我们要不断进行选择平衡（trade-off）从不同角度看IT架构时,都会觉得需要改变。

这是自然的因为任何一个角度看都只是一种架构的表示而已.所以,IT架构思考涉及到内容输入,思考和结果输出,IT架构设计使用的语言,功能方面的架构组件它是软件功能单元。

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

在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（ProblemDefinition）。

在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（ClassDiagram）来描述逻辑视图。

如下图:

构件（Components）：

类、类服务、参数化类、类层次连接件（Connectors）：

关联、包含聚集、使用、继承、实例化,开发视图（Development/ModuleView）,开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。

服务于软件编程人员，方便后续的设计与实现。

它通过系统输入输出关系的模型图和子系统图来描述。

要考虑软件的内部需求：

开发的难易程度、重用的可能性，通用性，局限性等等。

开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：

JavaSDK，图像处理软件包）。

进程视图,进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。

服务于系统集成人员，方便后续性能测试。

强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。

定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。

物理视图,物理视图主要描述硬件配置。

服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。

主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。

可以与进程视图一起映射。

场景（Scenarios）,场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。

可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。

文本、图形表示皆可。

IT架构设计方法,Asset-based设计与其他方法比较,One-of-a-kind设计方法每次都从头开始设计，耗用大量人力Systematic-use-of-assets设计每次仅利用系统概念Asset-based设计方法，每次最大可能地重用资产，可以最大地节约成本，扩大利润必须采用Asset-based设计方法，以保障市场竞争力,Asset-based设计方法,知识资产（Assets）资产必须基于通用方法描述（ADS）公司必须有一组通用的Assets公司必须知道怎样得到Assets技能（Skills）ITA必须具有技能将知识资产与客户需求对应，形成解决方案方法论（Methods）方法论是怎样重用Assets的规则只有遵循统一的方法论才能有效地重用Assets只有遵循统一的方法论才能有效地建立Assets,架构设计方法论及工作文档,架构文档分类,架构设计交付必须的文档,业务分析工作文档,项目描述信息来源:

客户访谈,标书内容价值:

基本信息。

帮助了解项目概况以及要解决的业务问题业务的目标信息来源:

客户访谈,与客户业务部门交流,标书内容价值:

对架构师非常重要,对说服客户内部也是重要的业务关系图信息来源:

你自己或是别人对这个客户业务的分析价值:

对架构师非常重要,对客户有时也是重要的遵循的IT标准信息来源:

客户访谈,与客户IT部门交流,标书内容,你的建议价值:

基本约束。

决定了建议的方案架构是否被客户拒绝目前客户IT环境信息来源:

客户访谈,与客户IT部门交流,标书内容,客户IT文档价值:

基本知识。

帮助你设计方案架构,帮助客户理解你的架构理由,项目描述与目标,与客户共同制定客户的要达到的最终目标,宏观远景,和关键项目成功因素有一个与客户达成共识的决策基础。

在项目执行过程中,许多决定都要基于这个基础定义了如何衡量项目是否成功的标准每一个跟项目相关的团队成员都应该对项目目标有共识。

这对项目执行过程中涉及到问题的解决事关重要,业务关系图,业务关系图是用来描述一个IT方案涉及到的业务范围以及范围内的业务内容。

并且也描述这个范围内的内容和其它相关联业务方面的关系。

这些业务单元之间的关系解释了它们之间的信息是如何流通的以及通过何种手段流通的。

对这些问题的明白和理解才能使架构师知道要建设的系统在业务中的位置，从而更好地满足业务需求。

另外,业务关系图还提供:

业务单元之间所发生的事件。

这会对系统模块之间接口的制订有很大的帮助它也提供了一个框架,使我们可以获取业务范围内的流程以及它们之间的业务“界面”,从而明白这些流程背后的理由和原因具体描述需要建设系统所要覆盖的业务范围。

不同的业务关系图可以用来和客户沟通讨论。

这也是确认最终系统实施范围的关键依据和步骤。

讨论的结果包括哪些业务功能是在项目范围之内的,哪些业务功能是在范围之外的,以及哪些是潜在未来的业务需求。

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

针对要建设的IT系统,定义关键系统特征和限制要求.用来估算系统容量和成本评估系统的可行性和生存能力用于系统部署模型的重要依据非功能需求经常是系统架构的重要因素之前描述的非功能性需求是用这个工作文件记录下来的,可行性分析,可行性分析报告是探讨,解释和描述建议的方案是否可行。

编写可行性报告的过程就是思考和组织建议方案的不同部分