原则4:尽可能快地交付
拉系统
敏捷开发中的拉系统(Pull System)借助于信息发射源(Information Radiator)使人们能够自己确定去做什么(例如,走廊上可能有一个白板,所有相关的用户素材都写在上面的卡片上;分配工作意味着将素材卡片(Story Card)从白板的“to-do”区移到“checked-out”区)。
在SOA环境中,您可以在卡片上编写用户素材和服务。通过添加服务,工作单元甚至变得更小,因为正如本系列的第1部分的SOA Application部分中所述,功能性是在用户界面应用程序、服务编排以及服务应用程序之间分配的。排队论指出,更小的工作包产生更高的吞吐量,例如功能的更快交付。
众所周知的用于面向对象(OO)设计的CRC卡片(类(Class)、责任(Responsibility)、协作(Collaboration))技术可以修改成SOA设计中的SRC卡片。“面向服务的分析与设计原理”包括这种技术的初始示例。
约定的经济模型
传统上,软件开发有时被看作是产生成本。近来,软件开发被看作是产生收入,可以帮助利用经济期权。基于期权的软件经济从金融市场提取出相似之处:交付运行的软件的短期迭代被看作是实物期权(Real Option)。就像金融期权(Financial Option)一样,实物期权通过现在非常少量的投资,来向您提供可能从未知的将来获得收益的机会。
但是并不需要走那么远:如果您创建约定的简单经济模型并使用它来驱动开发决策,甚至SOA约定也将从中受益。有了这个经济模型,就可以向团队成员授权,让他们自己明确什么对于业务是重要的:他们可以都从相同的假定开始工作。如果您考虑减少一些特性,销售部门可能推测出,没有这些特性,他们将少销售百分之“X”单位的产品。
原则5:向团队授权
对于任何软件开发,最有资格作决定的人就是在第一线工作的人。在解决方案体系结构层次上仍然需要严格的控制,而基础服务开发应该尽可能地灵活。通过授权给最接近实现的专业人员去做微观决策,您可以确保服务的最终代码满足所需要的功能性。在企业SOA中,您可以从授权和委托设计决策给服务的开发人员(在定义的范围内)中受益。
无论何时沿着层次结构向下委派决策权,您都必须确保所有的决策者都理解了统帅全局的愿景。通常,决策应该始终的是大家共同参与的活动,而不是孤立的活动。跨功能团队的环境(出现在敏捷项目中)促进了决策协作。
原则6:构建完整性
构建在概念上具有高度完整性的SOA的方法是从客户到开发团队、以及开发团队的上游流程和下游流程之间都有良好的信息流。从我们的角度来看,我们认为这一原则在服务开发层次以及服务编排中具有很高的价值。通过维持业务和IT专业人员之间良好的通信水平,可以确信您所交付的IT解决方案满足当前以及未来的业务流程和需求。随着结构良好的SOA中的业务和IT之间的联系越来越紧密,逐渐要求所交付的服务能够满足和紧密配合超出目标的业务流程。如果没有这种高层次的完整性,那么交付的服务不满足必要的业务要求或QoS的风险将会增加。
解构
现在,在IT产业中解构开发代码的实践得到认可已经有一段时间了。在SOA的环境中,这种实践同样重要。由于与业务的配合越来越紧密,以及需要确保所交付的服务可以支持不断变化且敏捷的业务环境,因此需要从本质上确保持续地评审和解构基础服务的设计。如果不能做到这一点,就将导致服务僵硬、不灵活,这对支持不断变化的业务环境没有益处。正如本系列的第1部分中的Agile architecture部分所述,该服务模型是控制持续解构的出色工具。
原则7:眼观全局
SOA的一项基本原则就是企业层次上的业务联合。对于任何企业体系结构(Enterprise Architecture)约定,都存在一个内在的需求,即确保始终维护统帅全局的“城市规划(city planning)”视图,并专注于将在SOA中部署的单个服务的详细设计。如果陷入以牺牲整体为代价来换取最佳的单个部分(或者服务)的诱惑中,您将承受交付不灵活的SOA的风险,它与企业中的关键业务流程是不相配的。
结束语和展望
正如我们在本系列中展示的,SOA可以从敏捷软件实践和LSD的已证明有效的原则中获得极大的好处。敏捷和SOA这两种实践的匹配基于一个共性——两者都极力设法处理变化。服务接口应该当作实现可能将改变的应用程序的必要条件。敏捷项目为要求它们实现的服务接口的改变做好了准备。
SOA的“持续的”解构意味着经常更改服务接口和服务组合。SOA中的这种敏捷需要实现项目中的敏捷。基于本文中所强调的要点,我们要说,当实现项目采用敏捷方法并接受改变时,SOA中真正的敏捷将起作用。
通常油和水并不能溶合在一起。不可否认,极限编程的想法和以可控的方式建立企业级服务体系结构之间存在着文化差异。但这仅仅是初步估计,在写完本文之后,我们可以声明存在一种乳化剂,即LSD的原则。
所以,最后我们将声明,在SOA和LSD原则的上下文中,“油和水确实可以溶合”!
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
Gottfried Luef是IBM的一名IT架构师兼顾问,目前在奥地利维也纳工作,为政府领域的各种项目提供Web服务、SOA和J2EE体系结构方面的经验支持。他参与了奥地利政府Web服务标准的制定。Gottfried获得了奥地利维也纳大学(University of Vienna)信息管理博士学位。您可以通过gottfried_luef@at.ibm.com与他联系。
Christoph Steindl是一名高级IT架构师和IBM的Method Exponent。他从2000年开始就职于IBM,参与了多个软件开发和系统集成项目。他擅长的领域包括应用程序开发、软件工程和方法学。他非常了解各种敏捷开发方法,并且经常就LSD、使用Scrum管理敏捷开发项目、使用Scrum支持XP、分布式敏捷开发、测试驱动的开发、实用的用例模型和敏捷开发项目评估发表演讲。他被Johnannes Kepler University(位于奥地利林茨)和University of Applied Sciences(位于奥地利哈根堡)聘为讲师,并且是认证ScrumMaster。他获得了Johnannes Kepler University(位于奥地利林茨)的计算机科学和机械电子学学位以及电子科学博士学位。您可以通过christoph_steindl@at.ibm.com与他联系。
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突