1-IT系统架构师课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– 业务单元之间所发生的事件。这会对系统模块之间接口的制订有 很大的帮助 – 它也提供了一个框架, 使我们可以获取业务范围内的流程以及它们 之间的业务“界面”, 从而明白这些流程背后的理由和原因 – 具体描述需要建设系统所要覆盖的业务范围。不同的业务关系图 可以用来和客户沟通讨论。这也是确认最终系统实施范围的关键 依据和步骤。讨论的结果包括哪些业务功能是在项目范围之内的, 哪些业务功能是在范围之外的, 以及哪些是潜在未来的业务需求。
架构决策决定于要解决的问题和涉及到的方面
什么是系统思考? (System Thinking)
系统和系统架构思考
• 系统性思考是一种架构设计过程,为了解各个部分是如何工作的 • 它是被人们认为在事件的背后, 寻找事件和功能的模式从而找出系统之 间负责功能模式和事件的关系 • 系统性思考是为了阐述一种宏观的看法。宏观的看法是要代表如何解 释系统组件之间关系的最基本基础 – 负责系统之间的关系以及方式 – 系统之间的关系使得我们可以理解不同事件的处理模式 • 选择系统的边缘界线有助于理解系统之间的互动 • 如何系统边缘的定义或选择是错的话, 我们的理解就会受阻 • 思考的方法是循环性的, 架构师要学会如何调整系统边缘, 从而更深理 解整体系统 架构设计的思考是基于以下几方面建立在系统思考之上的: • 使用从上到下和满足需求的方法 • 有能力把一堆乱麻整理成清晰的线条 • 利用结构来确认系统需求是可以满足的
归纳一下
系统架构师是个什么样的人? • 实际做事的人 • 不同意见和选择的协调人 • 结果导向的 • 知识广而多, 而不是少而 精 • 是个技术专家 • 是一个产品专家, 但知道 产品的能力 • 不是项目经理 • 不仅仅是个设计高手 • 绝对不是个孤独的思想家
对于系统架构的误解(myths) • 系统架构和系统设计是一回事 • 架构和基础结构是一回事 • 系统架构等同于硬件组合 • 好的系统架构是靠一个架构师 独立做出来的 • 系统架构凌驾于软件架构之上 • 架构是不可以衡量和确认的 • 架构是门科学 • 架构是技术, 基础结构, 数据和 网络的组合
• 业务关系图
– 信息来源: 你自己或是别人对这个客户业务的分析 – 价值: 对架构师非常重要, 对客户有时也是重要的
• 遵循的IT标准
– 信息来源: 客户访谈, 与客户IT部门交流, 标书内容, 你的建议 – 价值: 基本约束。决定了建议的方案架构是否被客户拒绝
• 目前客户IT环境
– 信息来源: 客户访谈, 与客户IT部门交流, 标书内容, 客户IT文档 – 价值: 基本知识。帮助你设计方案架构, 帮助客户理解你的架构理 由
Asset-based设计方法
• 知识资产（Assets）
– 资产必须基于通用方法描述 （ADS） – 公司必须有一组通用的Assets – 公司必须知道怎样得到Assets
•
技能（Skills）
– ITA必须具有技能将知识资产与客 户需求对应，形成解决方案
•
方法论（Methods）
– 方法论是怎样重用Assets的规则 – 只有遵循统一的方法论才能有效 地重用Assets – 只有遵循统一的方法论才能有效 地建立Assets
成功的架构师必备的特征
沟通的能力(communication) 富有激情地去做自己需要做的事情(passion) 判断别人的能力和做事的特性(character) 技术知识和能力，了解技术发展趋势(technical trend) 对一两个技术方向具备精深的掌握。(technical specialty) 行业知识(industry knowledge)
– IT系统架构是一种包括软件和硬件模组的结构。它描述了这些模 组对外的接口属性以及模组之间自身的关系.
• F. Brooks & W. Buchholz in Planning Computer Systems:
– Computer architecture, like other architecture, is the art of determining the needs of the user…and then designing to meet those needs as effective as possible.
– 部署单元的执行, 状态和部署三个方面都可以是 分开来考虑的(execution, state, installation)
描述和标示架构方法
描述和标示架构方法
• 4+1视图
逻辑视图（ 逻辑视图（Logic View） ）
• 逻辑视图主要是用来描述系统的功 描述系统的功 能需求，即系统提供给最终用户 最终用户的 能需求 最终用户 服务。在逻辑视图中，系统分解成 一系列的功能抽象、功能分解与功 能分析，这些主要来自问题领域 （Problem Definition)。 在面向对象技术中，通过抽象、封 装、继承,可以用对象模型来代表逻 辑视图，可以用类图（Class Diagram）来描述逻辑视图。如下 图:
wenku.baidu.comT架构师的侧重点
• IT架构师负责提供如何利用IT技术帮助一个企业 或组织开展业务和支持业务发展 • 系统架构师侧重于如何架构支持业务系统实现的 IT基础设施 • IT产品专家侧重于产品开发和项目的实施
系统架构思考方式
它可以把复杂的系统简单化 它可以分析需要的功能, 从而找出需要的模块 它提供了建设具体物理系统的基础 它定义如何连接系统各个部分的结构和策略 它提供组合以及拆散系统元素或模块的规则 它帮助分析系统非功能性的需求从而设计达到这 些要求的方案 • 它提供了做架构决策的记录,从而可以在未来进一 步扩展系统功能 • • • • • •
IT架构设计使用的语言
功能方面的架构 • 组件– 它是软件功能单元。它的使用是通过一 个或多个接口达到的 • 子系统– 任何一种在IT系统里组件的组合 • 组件协同使用(collaboration) – 使用场景的代表, 它的实现`是通过多个组件按一定顺序使用来达 到的 • 组件互动(interaction) – 代表两个组件之间的交 (interaction) 互,通过接口来执行的. 部署方面的架构 • 节点– 架构中的物理单元, 软件在其之上运行 • 连接– 代表节点与节点之间的物理连接, 如局域 网, 广域网等 • 部署单元– 代表一个或多个组件, 共同部署在同 一个节点上
架构设计方法论及工作文档
架构文档分类
架构设计交付必须的文档
业务分析工作文档
• 项目描述
– 信息来源: 客户访谈, 标书内容 – 价值: 基本信息。帮助了解项目概况以及要解决的业务问题
• 业务的目标
– 信息来源: 客户访谈, 与客户业务部门交流, 标书内容 – 价值:对架构师非常重要, 对说服客户内部也是重要的
IT系统架构师培训计划 系统架构师培训计划
启发性的问题
回答以下问题： • 什么是系统架构? • 为什么系统架构重要? • 在一个项目里为什么需要系统架构? • 系统架构师的角色是什么? • 谁是在一个项目里对系统架构要负责任的? • 谁是负责系统架构文档资料的? • 一般来说, 用什么样的图或模型来表示系统架 构? • 什么是系统架构思维?
优秀IT系统架构师的诀窍
• 永远都把自己放在不断学习新东西的位置。 (my experience) • 寻求最好的团队一起工作。不但你所参加的项目 成功机会大, 而且在团队中学到更多的东西。 • 不断学习的心态可使你成为一个优秀的系统架构 师。即使你不想成为系统架构师, 也可以成为一名 优秀的技术骨干, 从而增加你在团队中的价值。
系统架构思考支持系统架构
• • • • • • • 把复杂的系统简单化 分析需要的功能, 从而找出需要的模块 建设具体物理系统的基础 定义如何连接系统各个部分的结构和策略 提供组合以及拆散系统元素或模块的规则 帮助分析系统非功能性的需求并设计达到这些要求的方案 提供了架构决策的记录,可在未来进一步扩展系统功能
项目描述与目标
• 与客户共同制定客户的要达到的最终目标, 宏观远景, 和关键项目成功因素 • 有一个与客户达成共识的决策基础。在项 目执行过程中, 许多决定都要基于这个基础 • 定义了如何衡量项目是否成功的标准 • 每一个跟项目相关的团队成员都应该对项 目目标有共识。这对项目执行过程中涉及 到问题的解决事关重要
进程视图
• 进程试图侧重系统的运 运 行特性，关注非功能性 行特性 的需求（性能，可用 性）。服务于系统集成 系统集成 人员，方便后续性能测 人员 试。强调并发性、分布 性、集成性、鲁棒性 （容错）、可扩充性、 吞吐量等。定义逻辑视 图中的各个类的具体操 作是在哪一个线程 （Thread）中被执行。
IT架构设计方法
Asset-based设计与其他方法比较
• One-of-a-kind设计方 法每次都从头开始设 计，耗用大量人力 • Systematic-use-ofassets设计每次仅利 用系统概念 • Asset-based设计方 法，每次最大可能地 重用资产，可以最大 地节约成本，扩大利 润 • 必须采用Assetbased设计方法，以 保障市场竞争力
– 构件 构件(Components)：类、类服务、参 数化类、类层次 – 连接件 连接件(Connectors)：关联、包含聚集、 使用、继承、实例化
开发视图( 开发视图 Development/Module View)
• 开发视图主要用来描述软件模块 描述软件模块 的组织与管理（通过程序库或子 的组织与管理 系统）。服务于软件编程人员 编程人员， 编程人员 方便后续的设计与实现。它通过 系统输入输出关系的模型图和子 系统图来描述。要考虑软件的内 部需求：开发的难易程度、重用 的可能性，通用性，局限性等等。 开发视图的风格通常是层次结构， 层次越低，通用性越好（底层库： Java SDK，图像处理软件包）。
了解客户, 明白客户需求 从客户的角度思考和理解
具备很好的个人,销售,场景和能力技能(4 quadrant skills) 最重要的是具备结果导向的执行能力(result-oriented approach)
如何沟通– 增加销售说服力
如何定义“系统架构”?
• IBM Architectural Description Standard (ADS)定义:
物理视图
• 物理视图主要描述硬件配置 描述硬件配置。服务于系统工 系统工 描述硬件配置 程人员，解决系统的拓扑结构、系统安装、 程人员 通信等问题。主要考虑如何把软件映射到硬 件上，也要考虑系统性能、规模、可靠性等。 可以与进程视图一起映射。
场景(Scenarios) 场景
• 场景用于刻画构件之间的相互关系 刻画构件之间的相互关系， 刻画构件之间的相互关系 将四个视图有机地联系起来。可以描 述一个特定的视图内的构件关系，也 可以描述不同视图间的构件关系。文 本、图形表示皆可。
从不同的角度看IT架构思维
• IT架构概念可以想成是某种程度的提炼和封装(hiding of details) • 把在一定场景或状况下的细节隐藏起来。一旦场景发生变化, 所要隐 藏的细节也会改变 • IT架构设计需要考虑多方面的因素和质量。但经常这些质量之间会有 冲突。因此决定架构时,我们要不断进行选择平衡(trade-off) • 从不同角度看IT架构时, 都会觉得需要改变。这是自然的因为任何一 个角度看都只是一种架构的表示而已. …所以, IT架构思考涉及到内容输入, 思考和结果输出
业务关系图
• 业务关系图是用来描述一个IT方案涉及到的业务范围以及 范围内的业务内容。并且也描述这个范围内的内容和其它 相关联业务方面的关系。这些业务单元之间的关系解释了 它们之间的信息是如何流通的以及通过何种手段流通的。 对这些问题的明白和理解才能使架构师知道要建设的系统 在业务中的位置，从而更好地满足业务需求。 • 另外, 业务关系图还提供:
• IT目前比较接受的定义:
– IT系统架构师通过使用合理的IT技术来制定解决客户商业问题的 方案。这个方案是通过系统管理架构来展示和描述的, 它包括系统, 应用和应用模组之间的流程。类似一个建筑设计师, IT系统架构师 的工作是侧重于方案设计阶段的工作。在方案实施过程中, 系统架 构师扮演了一个与客户沟通的桥梁, 确认系统是按照所规划的架构 来实施的, 并且对施工方提供技术指导和引导.
架构决策决定于要解决的问题和涉及到的方面
什么是系统思考? (System Thinking)
系统和系统架构思考
• 系统性思考是一种架构设计过程,为了解各个部分是如何工作的 • 它是被人们认为在事件的背后, 寻找事件和功能的模式从而找出系统之 间负责功能模式和事件的关系 • 系统性思考是为了阐述一种宏观的看法。宏观的看法是要代表如何解 释系统组件之间关系的最基本基础 – 负责系统之间的关系以及方式 – 系统之间的关系使得我们可以理解不同事件的处理模式 • 选择系统的边缘界线有助于理解系统之间的互动 • 如何系统边缘的定义或选择是错的话, 我们的理解就会受阻 • 思考的方法是循环性的, 架构师要学会如何调整系统边缘, 从而更深理 解整体系统 架构设计的思考是基于以下几方面建立在系统思考之上的: • 使用从上到下和满足需求的方法 • 有能力把一堆乱麻整理成清晰的线条 • 利用结构来确认系统需求是可以满足的
归纳一下
系统架构师是个什么样的人? • 实际做事的人 • 不同意见和选择的协调人 • 结果导向的 • 知识广而多, 而不是少而 精 • 是个技术专家 • 是一个产品专家, 但知道 产品的能力 • 不是项目经理 • 不仅仅是个设计高手 • 绝对不是个孤独的思想家
对于系统架构的误解(myths) • 系统架构和系统设计是一回事 • 架构和基础结构是一回事 • 系统架构等同于硬件组合 • 好的系统架构是靠一个架构师 独立做出来的 • 系统架构凌驾于软件架构之上 • 架构是不可以衡量和确认的 • 架构是门科学 • 架构是技术, 基础结构, 数据和 网络的组合
• 业务关系图
– 信息来源: 你自己或是别人对这个客户业务的分析 – 价值: 对架构师非常重要, 对客户有时也是重要的
• 遵循的IT标准
– 信息来源: 客户访谈, 与客户IT部门交流, 标书内容, 你的建议 – 价值: 基本约束。决定了建议的方案架构是否被客户拒绝
• 目前客户IT环境
– 信息来源: 客户访谈, 与客户IT部门交流, 标书内容, 客户IT文档 – 价值: 基本知识。帮助你设计方案架构, 帮助客户理解你的架构理 由
Asset-based设计方法
• 知识资产（Assets）
– 资产必须基于通用方法描述 （ADS） – 公司必须有一组通用的Assets – 公司必须知道怎样得到Assets
•
技能（Skills）
– ITA必须具有技能将知识资产与客 户需求对应，形成解决方案
•
方法论（Methods）
– 方法论是怎样重用Assets的规则 – 只有遵循统一的方法论才能有效 地重用Assets – 只有遵循统一的方法论才能有效 地建立Assets
成功的架构师必备的特征
沟通的能力(communication) 富有激情地去做自己需要做的事情(passion) 判断别人的能力和做事的特性(character) 技术知识和能力，了解技术发展趋势(technical trend) 对一两个技术方向具备精深的掌握。(technical specialty) 行业知识(industry knowledge)
– IT系统架构是一种包括软件和硬件模组的结构。它描述了这些模 组对外的接口属性以及模组之间自身的关系.
• F. Brooks & W. Buchholz in Planning Computer Systems:
– Computer architecture, like other architecture, is the art of determining the needs of the user…and then designing to meet those needs as effective as possible.
– 部署单元的执行, 状态和部署三个方面都可以是 分开来考虑的(execution, state, installation)
描述和标示架构方法
描述和标示架构方法
• 4+1视图
逻辑视图（ 逻辑视图（Logic View） ）
• 逻辑视图主要是用来描述系统的功 描述系统的功 能需求，即系统提供给最终用户 最终用户的 能需求 最终用户 服务。在逻辑视图中，系统分解成 一系列的功能抽象、功能分解与功 能分析，这些主要来自问题领域 （Problem Definition)。 在面向对象技术中，通过抽象、封 装、继承,可以用对象模型来代表逻 辑视图，可以用类图（Class Diagram）来描述逻辑视图。如下 图:
wenku.baidu.comT架构师的侧重点
• IT架构师负责提供如何利用IT技术帮助一个企业 或组织开展业务和支持业务发展 • 系统架构师侧重于如何架构支持业务系统实现的 IT基础设施 • IT产品专家侧重于产品开发和项目的实施
系统架构思考方式
它可以把复杂的系统简单化 它可以分析需要的功能, 从而找出需要的模块 它提供了建设具体物理系统的基础 它定义如何连接系统各个部分的结构和策略 它提供组合以及拆散系统元素或模块的规则 它帮助分析系统非功能性的需求从而设计达到这 些要求的方案 • 它提供了做架构决策的记录,从而可以在未来进一 步扩展系统功能 • • • • • •
IT架构设计使用的语言
功能方面的架构 • 组件– 它是软件功能单元。它的使用是通过一 个或多个接口达到的 • 子系统– 任何一种在IT系统里组件的组合 • 组件协同使用(collaboration) – 使用场景的代表, 它的实现`是通过多个组件按一定顺序使用来达 到的 • 组件互动(interaction) – 代表两个组件之间的交 (interaction) 互,通过接口来执行的. 部署方面的架构 • 节点– 架构中的物理单元, 软件在其之上运行 • 连接– 代表节点与节点之间的物理连接, 如局域 网, 广域网等 • 部署单元– 代表一个或多个组件, 共同部署在同 一个节点上
架构设计方法论及工作文档
架构文档分类
架构设计交付必须的文档
业务分析工作文档
• 项目描述
– 信息来源: 客户访谈, 标书内容 – 价值: 基本信息。帮助了解项目概况以及要解决的业务问题
• 业务的目标
– 信息来源: 客户访谈, 与客户业务部门交流, 标书内容 – 价值:对架构师非常重要, 对说服客户内部也是重要的
IT系统架构师培训计划 系统架构师培训计划
启发性的问题
回答以下问题： • 什么是系统架构? • 为什么系统架构重要? • 在一个项目里为什么需要系统架构? • 系统架构师的角色是什么? • 谁是在一个项目里对系统架构要负责任的? • 谁是负责系统架构文档资料的? • 一般来说, 用什么样的图或模型来表示系统架 构? • 什么是系统架构思维?
优秀IT系统架构师的诀窍
• 永远都把自己放在不断学习新东西的位置。 (my experience) • 寻求最好的团队一起工作。不但你所参加的项目 成功机会大, 而且在团队中学到更多的东西。 • 不断学习的心态可使你成为一个优秀的系统架构 师。即使你不想成为系统架构师, 也可以成为一名 优秀的技术骨干, 从而增加你在团队中的价值。
系统架构思考支持系统架构
• • • • • • • 把复杂的系统简单化 分析需要的功能, 从而找出需要的模块 建设具体物理系统的基础 定义如何连接系统各个部分的结构和策略 提供组合以及拆散系统元素或模块的规则 帮助分析系统非功能性的需求并设计达到这些要求的方案 提供了架构决策的记录,可在未来进一步扩展系统功能
项目描述与目标
• 与客户共同制定客户的要达到的最终目标, 宏观远景, 和关键项目成功因素 • 有一个与客户达成共识的决策基础。在项 目执行过程中, 许多决定都要基于这个基础 • 定义了如何衡量项目是否成功的标准 • 每一个跟项目相关的团队成员都应该对项 目目标有共识。这对项目执行过程中涉及 到问题的解决事关重要
进程视图
• 进程试图侧重系统的运 运 行特性，关注非功能性 行特性 的需求（性能，可用 性）。服务于系统集成 系统集成 人员，方便后续性能测 人员 试。强调并发性、分布 性、集成性、鲁棒性 （容错）、可扩充性、 吞吐量等。定义逻辑视 图中的各个类的具体操 作是在哪一个线程 （Thread）中被执行。
IT架构设计方法
Asset-based设计与其他方法比较
• One-of-a-kind设计方 法每次都从头开始设 计，耗用大量人力 • Systematic-use-ofassets设计每次仅利 用系统概念 • Asset-based设计方 法，每次最大可能地 重用资产，可以最大 地节约成本，扩大利 润 • 必须采用Assetbased设计方法，以 保障市场竞争力
– 构件 构件(Components)：类、类服务、参 数化类、类层次 – 连接件 连接件(Connectors)：关联、包含聚集、 使用、继承、实例化
开发视图( 开发视图 Development/Module View)
• 开发视图主要用来描述软件模块 描述软件模块 的组织与管理（通过程序库或子 的组织与管理 系统）。服务于软件编程人员 编程人员， 编程人员 方便后续的设计与实现。它通过 系统输入输出关系的模型图和子 系统图来描述。要考虑软件的内 部需求：开发的难易程度、重用 的可能性，通用性，局限性等等。 开发视图的风格通常是层次结构， 层次越低，通用性越好（底层库： Java SDK，图像处理软件包）。
了解客户, 明白客户需求 从客户的角度思考和理解
具备很好的个人,销售,场景和能力技能(4 quadrant skills) 最重要的是具备结果导向的执行能力(result-oriented approach)
如何沟通– 增加销售说服力
如何定义“系统架构”?
• IBM Architectural Description Standard (ADS)定义:
物理视图
• 物理视图主要描述硬件配置 描述硬件配置。服务于系统工 系统工 描述硬件配置 程人员，解决系统的拓扑结构、系统安装、 程人员 通信等问题。主要考虑如何把软件映射到硬 件上，也要考虑系统性能、规模、可靠性等。 可以与进程视图一起映射。
场景(Scenarios) 场景
• 场景用于刻画构件之间的相互关系 刻画构件之间的相互关系， 刻画构件之间的相互关系 将四个视图有机地联系起来。可以描 述一个特定的视图内的构件关系，也 可以描述不同视图间的构件关系。文 本、图形表示皆可。
从不同的角度看IT架构思维
• IT架构概念可以想成是某种程度的提炼和封装(hiding of details) • 把在一定场景或状况下的细节隐藏起来。一旦场景发生变化, 所要隐 藏的细节也会改变 • IT架构设计需要考虑多方面的因素和质量。但经常这些质量之间会有 冲突。因此决定架构时,我们要不断进行选择平衡(trade-off) • 从不同角度看IT架构时, 都会觉得需要改变。这是自然的因为任何一 个角度看都只是一种架构的表示而已. …所以, IT架构思考涉及到内容输入, 思考和结果输出
业务关系图
• 业务关系图是用来描述一个IT方案涉及到的业务范围以及 范围内的业务内容。并且也描述这个范围内的内容和其它 相关联业务方面的关系。这些业务单元之间的关系解释了 它们之间的信息是如何流通的以及通过何种手段流通的。 对这些问题的明白和理解才能使架构师知道要建设的系统 在业务中的位置，从而更好地满足业务需求。 • 另外, 业务关系图还提供:
• IT目前比较接受的定义:
– IT系统架构师通过使用合理的IT技术来制定解决客户商业问题的 方案。这个方案是通过系统管理架构来展示和描述的, 它包括系统, 应用和应用模组之间的流程。类似一个建筑设计师, IT系统架构师 的工作是侧重于方案设计阶段的工作。在方案实施过程中, 系统架 构师扮演了一个与客户沟通的桥梁, 确认系统是按照所规划的架构 来实施的, 并且对施工方提供技术指导和引导.