超越软件架构.ppt

* * * * * * 追求可移植性的原因？ 市场架构师和技术架构师总是热衷于追求可移植，原因： 用户需求？ 竞争对手支持，所以我也要支持？ 证明技术能力强？ 所谓可移植优势案例分析 案例1： 期望：通过支持多平台，尽可能获取细分市场份额； 结果：基于客户使用的不同操作系统或硬件系统分割市场是错误的！ 正确的办法：瞄准用户的业务问题，解决好业务问题，你支持什么平台，客户都会跟着你走； 曾经的伤感：热衷于使用J2EE支持跨平台 所谓可移植优势案例分析 案例2： 期望：市场架构师说“我们的技术架构支持多平台，可以满足客户的特殊需求”，底气何来？技术架构师保证我们的技术是最棒的； 结果：单凭技术能力抓不住客户！ 正确的办法：仔细考虑客户的特殊要求，考虑对客户收益的支持能力； 追求可移植性的真正动机？ 开发人员显示其能力？ 错误的理解可移植性的商业价值？ 没有真正体会到完全的可移植性是不可能的，譬如操作系统不同版本之间的细微差别？ 为了个别所谓的“关键”用户的特殊需求？（这种情况在产品开发早期特别多） 评判可移植性的依据 是否因为公司有实力编写跨平台、可移植的代码，就应该这么做？ 评判的唯一准则：成本/收益比 可能的关键成本 对多平台开发、测试、质量保证、技术支持人员的培训成本； 支持多平台所需要购买、配置支持软硬件的成本； 开发和质量质量保证人员在每个平台上所消耗的成本； 管理多个平台版本所需要的管理成本，如支持平台版本升级所需要的测试成本。 评判可移植性的依据 考虑跨平台架构的条件： 可以统计，并已统计出，增加的总体成本 有足够的开发资源（包括人、物、时间等）支持创建、测试和配置多平台 了解多平台带来的冲击，并且有能力应付 确定销售收入足以支付增加的成本 内容纲要 审视软件架构 关于软件架构 市场架构与技术架构的区别 业务模型及其对软件架构的影响 可移植性与软件架构 部署架构 集成与扩展 软件架构的可用性 部署架构 企业级软件系统部署架构发展历程 常见的部署架构 客户对部署架构的影响 软件企业自身对部署架构的影响 软件系统部署架构发展历程 企业级软件系统部署架构发展历程 集中式大型机系统 客户机/服务器系统 分布式系统Web 网络服务系统（SOA） 业务模型影响部署架构； 在你“忽悠”客户的时候，小心被供应商、专家“忽悠” 部署架构的技术发展与实际部署有一定的距离； 选择合适的部署架构与技术有关； 最重要的是保障业务模型的实现与客户的利益 常见的部署架构 软件全部部署在客户方，这种形式在国内非常普遍； 提供应用服务（ASP）：ASP为客户运营提供应用程序的有限服务集，例如CA证书，SAS，地图数据； 提供管理服务（MSP），例如主机托管； Web服务 上述部署架构的综合、细化、演进 上述部署架构的基础是：企业的业务模型（商业模式） 客户对部署架构的影响 原则：部署架构应该符合客户要求 客户对部属架构的影响： 客户对软件系统的控制程度，包括对软件系统的整体控制、终端控制，例如政府、某种控制终端软件开发的失败案例； 数据安全/隐私和最大负荷 成本、对服务提供商（ASP、MSP）的信任 客户的技能、经验和地理分布情况等 软件企业自身对部署架构的影响 市场架构师选择部署架构考虑的因素： 客户需求 企业自身的能力、期望、需求、短期及长期发展战略 软件企业自身对部署架构的影响 影响部署架构的因素 完成销售所需要的时间与步骤—销售周期 基础设施的投入与回报时间 是否有足够的现金流，这一点很重要！ 灵活性 目标企业的地理分布情况 在意你的服务，而不是在意你的价格，对于xSP供应商尤其如此 内容纲要 审视软件架构 关于软件架构 市场架构与技术架构的区别 业务模型及其对软件架构的影响 可移植性与软件架构 部署架构 集成与扩展 软件架构的可用性 集成与扩展 概念 原因 分层业务架构 业务逻辑层的集成与扩展 持久性数据的集成与扩展 集成与扩展带来的其他商机 建立可集成与扩展架构的基本思路 建立可集成与扩展架构的基本思路是：分层架构 分层是松散耦合设计的常用架构 一般分四层： 用户界面层 服务对象层 业务模型层 持久性数据层 概念 集成：通过某种办法使系统与其他系统一起工作； 扩展：本系统在功能等方面的扩充 为什么要集成与扩展？ 对未来不可预测的需求做架构准备，例如插件架构 满足客户对以后功能扩展的要求； 便于将不同项目组或不同阶段的系统组成一个较大的系统，这很常见 从其他系统中获取需要的信息 通过集成不同的组件或系统，使客户很难丢掉你的系统 通过集成其他供应商的产品，建立利益联盟 集成与扩展是常识性的需求 业务逻辑层的集成与扩展 通过API集成，要考虑一些因素，例如平台偏好、合作伙伴偏好等，要尽量仅展现客户的最低集成API要求（成本问题）