IT系统架构师学习课程

1、启发性的问题回答以下问题： 什么是系统架构? 为什么系统架构重要? 在一个项目里为什么需要系统架构? 系统架构师的角色是什么? 谁是在一个项目里对系统架构要负责任的? 谁是负责系统架构文档资料的? 一般来说, 用什么样的图或模型来表示系统架构? 什么是系统架构思维?第1页/共67页第一页，编辑于星期六：二点 三十七分。IT架构师的侧重点 IT架构师负责提供如何利用IT技术帮助一个企业或组织开展业务和支持业务发展 系统架构师侧重于如何架构支持业务系统实现的IT基础设施 IT产品专家侧重于产品开发和项目的实施第2页/共67页第二页，编辑于星期六：二点 三十七分。系统架构思考方式 它可以把复杂的系统

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

3、一名优秀的技术骨干, 从而增加你在团队中的价值。第4页/共67页第四页，编辑于星期六：二点 三十七分。成功的架构师必备的特征l 沟通的能力(communication)l 富有激情地去做自己需要做的事情(passion)l 判断别人的能力和做事的特性(character)l 技术知识和能力，了解技术发展趋势(technical trend)l 对一两个技术方向具备精深的掌握。(technical specialty)l 行业知识(industry knowledge) 了解客户, 明白客户需求 从客户的角度思考和理解l 具备很好的个人,销售,场景和能力技能(4 quadrant skills)

4、l 最重要的是具备结果导向的执行能力(result-oriented approach)第5页/共67页第五页，编辑于星期六：二点 三十七分。如何沟通 增加销售说服力第6页/共67页第六页，编辑于星期六：二点 三十七分。如何定义“系统架构”? IBM Architectural Description Standard (ADS)定义: IT系统架构是一种包括软件和硬件模组的结构。它描述了这些模组对外的接口属性以及模组之间自身的关系. F. Brooks & W. Buchholz in Planning Computer Systems: Computer architecture,

5、 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技术来制定解决客户商业问题的方案。这个方案是通过系统管理架构来展示和描述的, 它包括系统, 应用和应用模组之间的流程。类似一个建筑设计师, IT系统架构师的工作是侧重于方案设计阶段的工作。在方案实施过程中, 系统架构师扮演了一个与客户沟通的桥梁, 确认系统是按照所规

6、划的架构来实施的, 并且对施工方提供技术指导和引导.第7页/共67页第七页，编辑于星期六：二点 三十七分。归纳一下系统架构师是个什么样的人? 实际做事的人 不同意见和选择的协调人 结果导向的 知识广而多, 而不是少而精 是个技术专家 是一个产品专家, 但知道产品的能力 不是项目经理 不仅仅是个设计高手 绝对不是个孤独的思想家对于系统架构的误解(myths)系统架构和系统设计是一回事架构和基础结构是一回事系统架构等同于硬件组合好的系统架构是靠一个架构师独立做出来的系统架构凌驾于软件架构之上架构是不可以衡量和确认的架构是门科学架构是技术, 基础结构, 数据和网络的组合第8页/共67页第八页，编辑于

7、星期六：二点 三十七分。架构决策决定于要解决的问题和涉及到的方面架构决策决定于要解决的问题和涉及到的方面第9页/共67页第九页，编辑于星期六：二点 三十七分。什么是系统思考? (System Thinking)第10页/共67页第十页，编辑于星期六：二点 三十七分。系统和系统架构思考 系统性思考是一种架构设计过程,为了解各个部分是如何工作的 它是被人们认为在事件的背后, 寻找事件和功能的模式从而找出系统之间负责功能模式和事件的关系 系统性思考是为了阐述一种宏观的看法。宏观的看法是要代表如何解释系统组件之间关系的最基本基础 负责系统之间的关系以及方式 系统之间的关系使得我们可以理解不同事件的处理

8、模式 选择系统的边缘界线有助于理解系统之间的互动 如何系统边缘的定义或选择是错的话, 我们的理解就会受阻 思考的方法是循环性的, 架构师要学会如何调整系统边缘, 从而更深理解整体系统架构设计的思考是基于以下几方面建立在系统思考之上的: 使用从上到下和满足需求的方法 有能力把一堆乱麻整理成清晰的线条 利用结构来确认系统需求是可以满足的第11页/共67页第十一页，编辑于星期六：二点 三十七分。系统架构思考支持系统架构 把复杂的系统简单化 分析需要的功能, 从而找出需要的模块 建设具体物理系统的基础 定义如何连接系统各个部分的结构和策略 提供组合以及拆散系统元素或模块的规则 帮助分析系统非功能性的需

9、求并设计达到这些要求的方案 提供了架构决策的记录,可在未来进一步扩展系统功能第12页/共67页第十二页，编辑于星期六：二点 三十七分。从不同的角度看IT架构思维 IT架构概念可以想成是某种程度的提炼和封装(hiding of details) 把在一定场景或状况下的细节隐藏起来。一旦场景发生变化, 所要隐藏的细节也会改变 IT架构设计需要考虑多方面的因素和质量。但经常这些质量之间会有冲突。因此决定架构时,我们要不断进行选择平衡(trade-off) 从不同角度看IT架构时, 都会觉得需要改变。这是自然的因为任何一个角度看都只是一种架构的表示而已.所以, IT架构思考涉及到内容输入, 思考和结果

10、输出第13页/共67页第十三页，编辑于星期六：二点 三十七分。IT架构设计使用的语言功能方面的架构 组件 它是软件功能单元。它的使用是通过一个或多个接口达到的 子系统 任何一种在IT系统里组件的组合 组件协同使用(collaboration) 使用场景的代表, 它的实现是通过多个组件按一定顺序使用来达到的 组件互动(interaction) 代表两个组件之间的交互,通过接口来执行的.部署方面的架构节点 架构中的物理单元, 软件在其之上运行连接 代表节点与节点之间的物理连接, 如局域网, 广域网等部署单元 代表一个或多个组件, 共同部署在同一个节点上部署单元的执行, 状态和部署三个方面都可以是分

11、开来考虑的(execution, state, installation)第14页/共67页第十四页，编辑于星期六：二点 三十七分。描述和标示架构方法第15页/共67页第十五页，编辑于星期六：二点 三十七分。描述和标示架构方法 4+1视图第16页/共67页第十六页，编辑于星期六：二点 三十七分。逻辑视图（Logic View） 逻辑视图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（Problem Definition)。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图

12、（Class Diagram）来描述逻辑视图。如下图: 构件(Components)：类、类服务、参数化类、类层次 连接件(Connectors)：关联、包含聚集、使用、继承、实例化 第17页/共67页第十七页，编辑于星期六：二点 三十七分。开发视图(Development/Module View) 开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编程人员， 方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：Java

13、SDK，图像处理软件包）。 第18页/共67页第十八页，编辑于星期六：二点 三十七分。进程视图 进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。第19页/共67页第十九页，编辑于星期六：二点 三十七分。物理视图 物理视图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。 第20页/共67页

14、第二十页，编辑于星期六：二点 三十七分。场景(Scenarios) 场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。文本、图形表示皆可。 第21页/共67页第二十一页，编辑于星期六：二点 三十七分。IT架构设计方法第22页/共67页第二十二页，编辑于星期六：二点 三十七分。Asset-based设计与其他方法比较 One-of-a-kind设计方法每次都从头开始设计，耗用大量人力 Systematic-use-of-assets设计每次仅利用系统概念 Asset-based设计方法，每次最大可能地重用资产，可以最大地

15、节约成本，扩大利润 必须采用Asset-based设计方法，以保障市场竞争力第23页/共67页第二十三页，编辑于星期六：二点 三十七分。Asset-based设计方法 知识资产（Assets） 资产必须基于通用方法描述（ADS） 公司必须有一组通用的Assets 公司必须知道怎样得到Assets 技能（Skills） ITA必须具有技能将知识资产与客户需求对应，形成解决方案 方法论（Methods） 方法论是怎样重用Assets的规则只有遵循统一的方法论才能有效地重用Assets 只有遵循统一的方法论才能有效地建立Assets 第24页/共67页第二十四页，编辑于星期六：二点 三十七分。架构设

16、计方法论及工作文档第25页/共67页第二十五页，编辑于星期六：二点 三十七分。架构文档分类第26页/共67页第二十六页，编辑于星期六：二点 三十七分。架构设计交付必须的文档第27页/共67页第二十七页，编辑于星期六：二点 三十七分。业务分析工作文档 项目描述 信息来源: 客户访谈, 标书内容 价值: 基本信息。帮助了解项目概况以及要解决的业务问题 业务的目标 信息来源: 客户访谈, 与客户业务部门交流, 标书内容 价值:对架构师非常重要, 对说服客户内部也是重要的 业务关系图 信息来源: 你自己或是别人对这个客户业务的分析 价值: 对架构师非常重要, 对客户有时也是重要的 遵循的IT标准 信息

17、来源: 客户访谈, 与客户IT部门交流, 标书内容, 你的建议 价值: 基本约束。决定了建议的方案架构是否被客户拒绝 目前客户IT环境 信息来源: 客户访谈, 与客户IT部门交流, 标书内容, 客户IT文档 价值: 基本知识。帮助你设计方案架构, 帮助客户理解你的架构理由第28页/共67页第二十八页，编辑于星期六：二点 三十七分。项目描述与目标 与客户共同制定客户的要达到的最终目标, 宏观远景, 和关键项目成功因素 有一个与客户达成共识的决策基础。在项目执行过程中, 许多决定都要基于这个基础 定义了如何衡量项目是否成功的标准 每一个跟项目相关的团队成员都应该对项目目标有共识。这对项目执行过程中

18、涉及到问题的解决事关重要第29页/共67页第二十九页，编辑于星期六：二点 三十七分。业务关系图 业务关系图是用来描述一个IT方案涉及到的业务范围以及范围内的业务内容。并且也描述这个范围内的内容和其它相关联业务方面的关系。这些业务单元之间的关系解释了它们之间的信息是如何流通的以及通过何种手段流通的。对这些问题的明白和理解才能使架构师知道要建设的系统在业务中的位置，从而更好地满足业务需求。 另外, 业务关系图还提供: 业务单元之间所发生的事件。这会对系统模块之间接口的制订有很大的帮助 它也提供了一个框架, 使我们可以获取业务范围内的流程以及它们之间的业务“界面”, 从而明白这些流程背后的理由和原因

19、 具体描述需要建设系统所要覆盖的业务范围。不同的业务关系图可以用来和客户沟通讨论。这也是确认最终系统实施范围的关键依据和步骤。讨论的结果包括哪些业务功能是在项目范围之内的, 哪些业务功能是在范围之外的, 以及哪些是潜在未来的业务需求。第30页/共67页第三十页，编辑于星期六：二点 三十七分。IT技术遵循标准与目前IT系统环境 IT技术遵循的标准文档具体列举了所有项目必须遵循的标准和使用的技术, 甚至具体的产品. 这些标准可能是来自之前的工作, 企业内部的IT规范. IT标准总是存在的, 无论是公开的还是不言而喻的. 这些事实的记录会帮助IT架构师规划系统方案架构. 这个文档也记录了在方案规划或

20、者执行过程中要绕过这些IT标准的理由和原因 另外, 任何系统模块还没有标准遵循时, 这种信息也要记录下来.这是为了将来这些实施的标准可以变成企业IT标准 目前系统环境文档是个系统清单, 包括硬件, 软件和其它IT功能环境,如防火墙, 网络地址分配,等等第31页/共67页第三十一页，编辑于星期六：二点 三十七分。可行的 vs. 不可行的第32页/共67页第三十二页，编辑于星期六：二点 三十七分。人-机分工平衡以取综合最优第33页/共67页第三十三页，编辑于星期六：二点 三十七分。非功能需求 非功能需求用来: 针对要建设的IT系统, 定义关键系统特征和限制要求. 用来估算系统容量和成本 评估系统的

21、可行性和生存能力 用于系统部署模型的重要依据 非功能需求经常是系统架构的重要因素之前描述的非功能性需求是用这个工作文件记录下来的第34页/共67页第三十四页，编辑于星期六：二点 三十七分。可行性分析 可行性分析报告是探讨, 解释和描述建议的方案是否可行。 编写可行性报告的过程就是思考和组织建议方案的不同部分。 可行性分析经常是针对某部分系统需求, 功能或某种技术的使用。 可行性分析也是用来找出潜在可能存在的问题和风险. 这对与客户沟通以及架构师设计时都是一个重要方面。 可行性报告应该是不断更新和审核的. 同时它是作为质量保证审核以及实施计划的重要依据。第35页/共67页第三十五页，编辑于星期六

22、：二点 三十七分。可行性分析举例 使用不同的颜色(红/黄/绿)来标示不同程度的问题 不要把风险, 问题, 假设和依赖因素混为一谈 提早从客户获取信息进行风险分析 例如, 如果客户不提供所需要的资料或信息, 这个问题带来的风险是高的. 可以有依据向客户尽早获取资料第36页/共67页第三十六页，编辑于星期六：二点 三十七分。系统运行模型 提供宏观的系统逻辑运行架构, 用来理解整体系统是如何满足业务需求的用来考虑系统主要基础架构是如何部署的以及系统组件应该如何部署 用来确认客户对系统实施的倾向和限制因素 用来执行早期的系统基本功能的流程执行验证(walk-through) 基于以上几个方面, 用来考

23、虑系统的非功能性需求应该如何满足 用来选择实施系统组件功能的产品或应用, 衡量它们的可用性 用来估算相关系统硬件和基础建设的成本 作为选择软件和硬件产品的选择基础第37页/共67页第三十七页，编辑于星期六：二点 三十七分。系统运行模型图举例 用来估算硬件的成本及软件license的数量第38页/共67页第三十八页，编辑于星期六：二点 三十七分。系统运行模型图举例 系统LPAR的节点配置方案第39页/共67页第三十九页，编辑于星期六：二点 三十七分。系统运行模型图举例 系统节点描述第40页/共67页第四十页，编辑于星期六：二点 三十七分。Q & A第41页/共67页第四十一页，编辑于星期

24、六：二点 三十七分。IT Infrastructure 架构设计 逻辑层面的运营架构模型 规范层面的运营架构模型 物理层面的运营架构模型 总结第42页/共67页第四十二页，编辑于星期六：二点 三十七分。运营架构模型八步规划法 八步法是按顺序来讲的. 但在实际制作过程中, 有些步骤是同步进行的或重复使用的. 是否是这种情况决定于限定因素或条件, 以及是否使用参考架构 在做每一步时, 关键的非功能性需求对架构模型的影响一定要不断核实 系统可用性, 性能, 系统管理, 安全 这个做法也包括如何制作以下工作文档: 部署单元更新的架构决定 可行性报告第43页/共67页第四十三页，编辑于星期六：二点 三十

25、七分。第一步:找出业务功能的位置和区域 信息来自于： 业务角色和位置 系统关系图 目前IT环境第44页/共67页第四十四页，编辑于星期六：二点 三十七分。第二步: 找出逻辑节点第45页/共67页第四十五页，编辑于星期六：二点 三十七分。逻辑节点举例第46页/共67页第四十六页，编辑于星期六：二点 三十七分。第三步: 为了满足系统管理需求的特殊逻辑节点第47页/共67页第四十七页，编辑于星期六：二点 三十七分。第四,五,六步: 找出展示, 执行和数据部署节点第48页/共67页第四十八页，编辑于星期六：二点 三十七分。第七步: 找出需要的连接节点第49页/共67页第四十九页，编辑于星期六：二点 三

26、十七分。第八步: 回顾目前所达到的结果第50页/共67页第五十页，编辑于星期六：二点 三十七分。建议以场景进行验证第51页/共67页第五十一页，编辑于星期六：二点 三十七分。第52页/共67页第五十二页，编辑于星期六：二点 三十七分。IT Opertion 架构设计 逻辑层面的运营架构模型 规范层面的运营架构模型 物理层面的运营架构模型 总结第53页/共67页第五十三页，编辑于星期六：二点 三十七分。规范架构是把逻辑架构改变成一个技术规范架构技术规范架构过程1.在限制因素范围内和满足非功能需求的前提下, 找出必要的技术需求和功能服务用来提供业务功能2.考虑一些不同的选择或方法满足同样的需求,

27、进行选择平衡, 对目前的架构做适当的修改3.设计逻辑技术连接4.评估目前架构的可行性, 对相关的架构文档进行更新第54页/共67页第五十四页，编辑于星期六：二点 三十七分。输入-组件模型, 非功能需求, 用户需求和逻辑模型第55页/共67页第五十五页，编辑于星期六：二点 三十七分。寻找技术规范节点 系统管理考虑 不同节点是如何运作的 监控(系统状况监控, 性能监控, 可用性监控) 任务执行(开机, 关机, 日志控制, 配置控制等等) 安装, 配置,变更管理 数据分布, 同步, 备份, 回复 系统使用以管理记录 问题处理 做法 从每个节点, 层次, 位置和整体方案角度找出不同系统管理的考虑因素 找出每个涉及到系统管理流程和数据存储的节点 在不同层次和区域中找出其它涉及到系统管理和数据存储的节点第56页/共67页第五十六页，编辑于星期六：二点 三十七分。参考架构是逻辑和技术架构的结合第57页/共67页第五十七页，编辑于星期六：二点 三十七分。IT Infrastructure 架构设计 逻辑层面的运营架构模型 规范层面的运营架构模型 物理层面的运营架构模型 总结第58页/共67页第五十八页，编辑于星期六