让我们回顾一下需求分析的历史,然后讨论SOA中如何来进行面向服务的分析和建模吧。
软件工程方法中,需求分析的方法跟问题域的复杂度和类型紧密相关。在早期,计算需求主要来自科学计算,其抽象手段主要是“数据结构+算法”。在沟通需求的时候,技术人员跟业务人员以自然语言为基础来沟通,然后以过程和/或函数以及数据结构为主要抽象手段,来建立分析模型。分析结果包含过程/函数、流程图、数据流图,复杂一些的,引入模块和子系统来分割。然后,用自然语言描述为主的文档来作为沟通的手段。如果我们还记得关于GOTO的讨论,我们了解,这个计算时代经过多年的发展,推动了结构化编程的发展和成熟。
伴随着商业计算逐渐成为主流,商业计算从早期类似于科学计算的财务等,转向更为广泛的领域,其计算的复杂度和类型,发生了很大的变化,这中间各种数据库技术曾经领衔主演了一段时间,我们按下不表。这期间,在“软件危机”的推动下,对象成为基本的抽象手段,将其高度内耦合的数据、状态和行为结合在一起,不仅提高了抽象度,也自然地反映人们认识和描述这个世界的方式。经过多年的实践、争吵和合作,人们总结出了很多关于对象分析和建模的方式,组件、接口、各种分析和设计模式,逐渐地被认识和流行,UML建立了图例和文档规范,以便沟通。这是软件界的一个巨大进步。在这种软件工程方法中,技术人员通常用自然语言同业务人员沟通,然后用“Use Case”(用例)来建立各种角色所看到的系统边界,再辅助以用户交互(UI)等必要的其他模型,建立一个系统的分析视图,然后,以对象(和组件)为基本手段,建立系统的分析模型,最后,用UML和一些过程如RUP提供的文档模板为基础,提供需求分析结果。这种分析方法,今天非常流行,也很有效。
但是,商业计算的情况再次发生巨大的变化——“整合”和“灵活性”成为主要的需求。经过几十年的发展,商业计算已经不再是过去白手起家的时刻,我们已经有了很多的“历史”,那就是我们已经建立起来的这么多的系统:每个企业都有IT系统,少到几个、几十个,多到几千甚至上万。人类花了这么多钱、这么多时间在这些系统上,没有了这些系统,核心业务会崩溃。但这些系统也给我们带来了巨大的麻烦——它们能够满足不同业务部门(Line of Business,LoB)的垂直需求,可是相互不往来、也不能或者很难相互往来,难以满足跨业务部门的水平需求,更不要说在今天这个平的世界里,如何将合作伙伴、客户连接起来,建立一个动态的商业价值网络。但是,全球化的经济结构和运作模式,互联网作为全球化的IT基础设施,从商业和技术两个角度,透过竞争,既给富有创新和执行能力的企业带来了一个前所未有的商业机会,又迫使跟随的企业不得不起而迎战——将业务模式调整到以客户为中心,将自己内部的业务系统连接起来,水平整合业务活动成为端到端的业务流程,透过这些流程,让整个公司的员工可以自由地得到业务活动需要的信息,轻松地相互协作,从而将整个企业的运作模式转化为一个扁平的结构,打破业务部门的边界,极大地提高企业的效率,得到更好的客户满意度。即便如此,用户需求、市场情况、商业环境的快速变化作为这个时代的特点,要求企业能够快速调整自己的商业模型,因此,在整合的基础上,还要加上快速应变的灵活性要求。这就涉及到了软件的两个魔鬼:复杂度和演变。全面整合(整个企业,客户,合作伙伴)的系统,其复杂度再次提升,而灵活应变能力,在一个整合的世界里,大家都变,自己也没办法以不变应万变,究竟如何因变?所以,我们需要发展软件系统的构造方法,它既可以帮助我们将问题域进行良好的分割,分解映射为分布世界里的独立单元,又可以帮助我们灵活地将它们组合起来以完成一个完整的业务活动,这样一种新型的、富有弹性的分布式系统,是今天的商务世界所需要的,是商业计算的主要发展方向。SOA也好,正在热吵的Enterprise Web 2.0也好,都是我们期望用来解决上面这个问题的方法。
虽然,我们还处在这个早期,有赖于过去多年的EAI、分布式系统的构造实践,尤其是Web的发展,IT行业积累了不少的经验和技术来求解。让我们简要地看看现在这个阶段的解的重点:一个是将业务本身作为一个独立的实体,由业务人员自己自觉(而不是自发)地以业务世界的元素,比如业务活动,业务流程,业务规则,业务性能及其测评,建立起数字化的模型,其核心概念就说所谓的“服务”。在这个模型中,我们将看到一个清晰的图景:业务活动是如何影响业务绩效的,业务模型的问题在那里,如何改善。这就是所谓的“商业科学化”,请参看我在 Service Science方面的介绍。了解BPR (Business Process Reengineering) 的话,应该了解这件事情会在什么状态,它的困难在哪里。有了这个为基础,业务人员可以自己跟自己玩:市场需求变了(他们的需求),那业务模型怎么变化来适应?或者,有了一个市场图谋,如何变化自己的业务模型来适应?过去要猜,要靠某些精英的个人特质,有了这个模型,我们期待一个魔术的出现,就是可以用数学的方法来演算、模拟、推断,哪怕结果不是高度精确的,也可以给决策者一个合理的、基于数字的决策依据。然后,这个模型要清晰地被分解和映射到IT系统中的服务接口、组件和业务规则描述等等,然后将它们分配到各个应用(包括已经存在的)中,再在这个基础上,使用用例、组件(细粒度)和对象建立应用或者子系统的需求模型,我们可能需要增加新的模型,比如整合各个应用的模型,安全模型(整合情况下安全更复杂)等。看得到,这个模型对过去的业务分析(尤其是从 BPR,或者其他以业务流程为基础的)是有继承的,但要看到,他们的出发点和追求的目标,有交叉但并不能等同,所基于的概念和方法,即使有所借用,却有很不相同的重点。站在发展的角度,我们期待着业务模型数字化、科学化的突破。
是故,我们认为SOA将业务建模作为一个全新的因素引入,如何建立一个好的业务模型,然后递次分解、映射到传统技术世界主导的分析和建模,如何保证其可追溯性(Tracability)将是以服务为中心的分析、建模的重要环节。
软件工程方法中,需求分析的方法跟问题域的复杂度和类型紧密相关。在早期,计算需求主要来自科学计算,其抽象手段主要是“数据结构+算法”。在沟通需求的时候,技术人员跟业务人员以自然语言为基础来沟通,然后以过程和/或函数以及数据结构为主要抽象手段,来建立分析模型。分析结果包含过程/函数、流程图、数据流图,复杂一些的,引入模块和子系统来分割。然后,用自然语言描述为主的文档来作为沟通的手段。如果我们还记得关于GOTO的讨论,我们了解,这个计算时代经过多年的发展,推动了结构化编程的发展和成熟。
伴随着商业计算逐渐成为主流,商业计算从早期类似于科学计算的财务等,转向更为广泛的领域,其计算的复杂度和类型,发生了很大的变化,这中间各种数据库技术曾经领衔主演了一段时间,我们按下不表。这期间,在“软件危机”的推动下,对象成为基本的抽象手段,将其高度内耦合的数据、状态和行为结合在一起,不仅提高了抽象度,也自然地反映人们认识和描述这个世界的方式。经过多年的实践、争吵和合作,人们总结出了很多关于对象分析和建模的方式,组件、接口、各种分析和设计模式,逐渐地被认识和流行,UML建立了图例和文档规范,以便沟通。这是软件界的一个巨大进步。在这种软件工程方法中,技术人员通常用自然语言同业务人员沟通,然后用“Use Case”(用例)来建立各种角色所看到的系统边界,再辅助以用户交互(UI)等必要的其他模型,建立一个系统的分析视图,然后,以对象(和组件)为基本手段,建立系统的分析模型,最后,用UML和一些过程如RUP提供的文档模板为基础,提供需求分析结果。这种分析方法,今天非常流行,也很有效。
但是,商业计算的情况再次发生巨大的变化——“整合”和“灵活性”成为主要的需求。经过几十年的发展,商业计算已经不再是过去白手起家的时刻,我们已经有了很多的“历史”,那就是我们已经建立起来的这么多的系统:每个企业都有IT系统,少到几个、几十个,多到几千甚至上万。人类花了这么多钱、这么多时间在这些系统上,没有了这些系统,核心业务会崩溃。但这些系统也给我们带来了巨大的麻烦——它们能够满足不同业务部门(Line of Business,LoB)的垂直需求,可是相互不往来、也不能或者很难相互往来,难以满足跨业务部门的水平需求,更不要说在今天这个平的世界里,如何将合作伙伴、客户连接起来,建立一个动态的商业价值网络。但是,全球化的经济结构和运作模式,互联网作为全球化的IT基础设施,从商业和技术两个角度,透过竞争,既给富有创新和执行能力的企业带来了一个前所未有的商业机会,又迫使跟随的企业不得不起而迎战——将业务模式调整到以客户为中心,将自己内部的业务系统连接起来,水平整合业务活动成为端到端的业务流程,透过这些流程,让整个公司的员工可以自由地得到业务活动需要的信息,轻松地相互协作,从而将整个企业的运作模式转化为一个扁平的结构,打破业务部门的边界,极大地提高企业的效率,得到更好的客户满意度。即便如此,用户需求、市场情况、商业环境的快速变化作为这个时代的特点,要求企业能够快速调整自己的商业模型,因此,在整合的基础上,还要加上快速应变的灵活性要求。这就涉及到了软件的两个魔鬼:复杂度和演变。全面整合(整个企业,客户,合作伙伴)的系统,其复杂度再次提升,而灵活应变能力,在一个整合的世界里,大家都变,自己也没办法以不变应万变,究竟如何因变?所以,我们需要发展软件系统的构造方法,它既可以帮助我们将问题域进行良好的分割,分解映射为分布世界里的独立单元,又可以帮助我们灵活地将它们组合起来以完成一个完整的业务活动,这样一种新型的、富有弹性的分布式系统,是今天的商务世界所需要的,是商业计算的主要发展方向。SOA也好,正在热吵的Enterprise Web 2.0也好,都是我们期望用来解决上面这个问题的方法。
虽然,我们还处在这个早期,有赖于过去多年的EAI、分布式系统的构造实践,尤其是Web的发展,IT行业积累了不少的经验和技术来求解。让我们简要地看看现在这个阶段的解的重点:一个是将业务本身作为一个独立的实体,由业务人员自己自觉(而不是自发)地以业务世界的元素,比如业务活动,业务流程,业务规则,业务性能及其测评,建立起数字化的模型,其核心概念就说所谓的“服务”。在这个模型中,我们将看到一个清晰的图景:业务活动是如何影响业务绩效的,业务模型的问题在那里,如何改善。这就是所谓的“商业科学化”,请参看我在 Service Science方面的介绍。了解BPR (Business Process Reengineering) 的话,应该了解这件事情会在什么状态,它的困难在哪里。有了这个为基础,业务人员可以自己跟自己玩:市场需求变了(他们的需求),那业务模型怎么变化来适应?或者,有了一个市场图谋,如何变化自己的业务模型来适应?过去要猜,要靠某些精英的个人特质,有了这个模型,我们期待一个魔术的出现,就是可以用数学的方法来演算、模拟、推断,哪怕结果不是高度精确的,也可以给决策者一个合理的、基于数字的决策依据。然后,这个模型要清晰地被分解和映射到IT系统中的服务接口、组件和业务规则描述等等,然后将它们分配到各个应用(包括已经存在的)中,再在这个基础上,使用用例、组件(细粒度)和对象建立应用或者子系统的需求模型,我们可能需要增加新的模型,比如整合各个应用的模型,安全模型(整合情况下安全更复杂)等。看得到,这个模型对过去的业务分析(尤其是从 BPR,或者其他以业务流程为基础的)是有继承的,但要看到,他们的出发点和追求的目标,有交叉但并不能等同,所基于的概念和方法,即使有所借用,却有很不相同的重点。站在发展的角度,我们期待着业务模型数字化、科学化的突破。
是故,我们认为SOA将业务建模作为一个全新的因素引入,如何建立一个好的业务模型,然后递次分解、映射到传统技术世界主导的分析和建模,如何保证其可追溯性(Tracability)将是以服务为中心的分析、建模的重要环节。