1、第 1 页,软件架构设计方法,业界IT项目主要问题及原因,成功的项目：26 项目能够在预定的时间内和预算费用内完成；问题项目并完成：46 超过预算费用，18.9； 超过预计时间，22.2 比预计功能减少；失败的项目 28 项目终止，,缺乏高层支持和用户的介入 20.3 缺乏强有力的项目管理 18.0 需求不完整 12.3% 需求不断变动 11.8% 不明确的目标和期望 11.2% 不适当的技术架构 7.0% 缺少资源 6.4% 不现实的进度计划 4.3% 新项目 3.7% 其它 5%,软件需求分析参考模型,业务需求,技术需求,并发处理,信息发布,按需处理,联机分析处理,适当规模的平台,高吞吐量
2、,架构目标,示例:多个业务分区 多层次的用户 全时处理(联机可用性) 用户触发的按需处理 与数据仓库无缝集成 灵活的用户端信息获取/分析 实时的基于场景的敏感性分析 和其他机构集成开放标准访问 和外部系统互联 直通式处理 (STP) 能力 组件化或者模块化设计 可复用的和可共享的组件 选用适当规模的平台已降低成本 加快进入市场的速度 便于支持和维护,确立架构的重要性: 使所有资源都能够在一个方向上使用来交付业务和技术需求 评估和指导架构组件的设计.,高可用性,灵活的 可扩展性,多维安全控制,支持业务功能,集中式信息管理,组件化架构,行业消息,开放和公用访问,开放互联,模块化组件,架构目标,支持
3、联机/批量并发处理 多并发处理(for different partitions) 生产 /影子数据并发处理,并发处理,按需处理,按需的高效率交易处理 无缝的中间层和后台触发与通讯 同步响应和异步的结果回送,联机分析处理,从生产数据中隔离出分析/历史数据 高效的数据复制 用户友好、高性能的临时分析,信息发布,从异构系统中合并信息 健壮的数据仓库 和CRM以及交付渠道集成,适当规模的平台,健壮的、企业级的分层架构 利用中间层的能力 (渠道管理, 数据分析) 利用后台交易处理能力,模块化组件,基于组件的架构框架 松耦合的数据/访问服务 松耦合的应用/公用服务,多维安全控制,分区的安全控制 集中式安
4、全管理 / single sign on 使用多种验证方式的灵活性,灵活的可扩展性,最大化纵向扩展能力 最大化横向扩展能力 获得架构/应用系统扩展透明性,高可用性,最小化宕机时间和切换时间 最小化单点故障 在切换时对用户透明,高吞吐量,能够处理3-5 倍的峰值业务量 快速的联机响应；缩短的批处理窗口 内置的负载分享/均衡以获得高交易处理速率,架构目标,支持业务功能,集中式信息管理,组件化 架构,架构目标（续）,开放和公用访问,基于开放技术的公用访问方法 隔离的渠道和业务逻辑层 多个传递渠道和主机到主机的连接,行业消息,采用国际标准 (消息/架构) 支持同步和异步消息 支持高效的单一和大量交易请
5、求,开放互联,关键设计原则,开放互联 开放访问 通用渠道管理 兼容行业标准 组件化 基于组件的架构 跟上市场 复用优于购买；购买优于建造,复用优于购买；购买优于开发,成本最低 公用的开发技术 易于集成,经过检验的资产和服务 可以投入生产、健壮 真正开放、基于标准,成本高 错误率高 需要的时间长,架构设计方法,业务需求,技术需求,分层的架构设计,并发 流程,信息发布,随时 流程,OLAP,估量正确的 平台,大吞吐量,架构目标,高可用性,灵活的 可扩展性,多角度的 安全控制,业务功能,集中信息管理,组件化的架构,行业 消息,开放的通用的 访问,开放式连接,模块化组件,总体技术架构,企业级体系架构蓝图,体系架构分层参考模型,欢迎诸位领导和专家批评指正！,
