从业务流程角度理解面向服务的概念

SOA，目前在IT领域的热门主题“面向服务的架构”，Service Oriented Architectures。SOA的概念来自于web服务，由于web服务概念的出现及相关应用系统的实施，SOA架构成为新的web服务模式。从本质上讲，SOA的概念是很简单的。与传统的端到端的企业应用系统不同，SOA提供了一系列的“服务”模块，这些服务模块具有定义良好的输入/输出接口以及功能完善的处理模块。通过使用这些服务，传统的端到端的系统可以方便的利用这些服务集成在一起。使用SOA架构最为便利的一点所构建的各种服务模块不再仅仅为某一个系统服务，而是可为整个企业内部大多数的系统所用。

企业希望实施SOA的一个先决条件是:所拥有的信息系统存在异构性，即不同的应用软件系统由不同的软件供应商提供，同时，企业自身的需求又要求各不同的软件系统无缝的集成在一起。应用软件的异构性这一特点在大多数企业都存在，就像养鸡人不愿将所有的

鸡蛋放在一个篮子一样，为了避免对某一软件供应商的过渡依赖，企业必然会选择不同的软件产品，同样，对于软件供应商而言，其所提供的产品不可能满足用户的所有需求。

以客户关系管理系统为例，目前存在的CRM系统种类繁多，有侧重于销售自动化的，有自主服务类型，还有电子邮件应答式系统。为了确保客户的满意度，有时需要这几种不同的系统取长补短，集成为一个功能更加完善的系统。但是，实际上，真正实现这一要求并不像想象的那么简单，主要原因在于各个不同的系统是由不同的软件供应商所提供，并且是为特定用户或某一用途而服务的。为了更好的为客户服务，很多相同的功能在不同的系统中被重复实现，并且对于客户而言，希望通过现有的这些系统获得“点对点”的直接式服务似乎越来越难。

这种情形在很多企业都存在，对于这些问题，利用SOA架构构建的信息系统可以方便的消除这些异构性，抹平系统之间的差异，实现应用系统的无缝集成。但是，要想使基于SOA架构的系统能够成功建立，必须明白哪些功能可以以服务的形式出现。

确定服务模块的一个方法是将现有应用系统中所能提供的功能以列表的形式列出，如果发现相同的功能模块在不同的系统都有所实现，那么这些功能模块可以以服务模块的形式加以重构。这种方法是基于软件功能层面的，虽然可以以此作为建立新系统的依据，但是，由于过多地考虑了软件系统的功能要求，所以，我们并不推荐采用这种方法来构建新系统。

对于SOA架构的系统而言， 服务模块最好通过业务流程管理来确定，即通过BPM系统来分析企业的业务流程，将所有的业务流程以图表的方式表示出来，这样可以清楚地知道我们需要完成什么样的工作，对于这些工作，我们又需要什么样的信息系统。同时，通过对业务流程的分析，我们还可以明确知道客户流程，而不是简单的只考虑客户服务和销售问题。

这种构建基于SOA架构系统的策略可以使我们清楚地明白哪些功能是我们需要的，而不是去考虑现存哪些功能。通过建立现有系统所具有的功能模块目录列表，我们可以方便的发现那些在不同的系统中被重复实现的功能模块，进一步分析我们将会发现，那些只在一个系统中被实现的功能模块，对于其他系统而言，并没有太多的用途。

在部属新的系统之前，通过对业务流程的分析，我们可以确定哪些功能是必须要实现，从而使得我们可以在更恰当的时间以更合适的方式来实现所需要的功能服务。这样不但能更好的实现信息资源共享，而且可以使得整个系统发挥其最大效能。反过来，利用基于SOA架构的系统又可以使得我们更好的进行生产设计，同时可以最大限度的节约成本。

目前，很多企业并没有对其业务流程进行充分详细的分析，其主要原因在于:只要企业存在，业务流程就存在，但是，对于业务流程的记录和分析又缺乏相应的自动化手段和必要的文档信息。业务流程往往会随着企业内外环境的变化而发生变化，比如随着客户需求的变化和产品及管理方面的变化而变动。为了更好的实施基于SOA架构的新的系统，我们必须对业务流程加以细查，从而可以对业务流程加以改善，同时，这又使得整个企业的业务流程的运作更为灵敏。此外，通过对业务流程的分析，又可以消除IT工作人员与企业管理人员之间的鸿沟，使得企业管理者更清楚的知道信息系统所提供的功能，以及这些信息系统对于企业运作的真正价值。

通过对业务流程进行分析，企业可以更清楚地知道哪些功能性要求可以以服务的形式加以实现。如果只是实施了新的基于SOA架构的系统，而没有对流程进行充分的管理和分析，那无疑是在浪费时间，企业不会清楚其真正需要的功能性服务是什么。对业务流程进行充分的分析可以帮助企业更好的了解其业务流程，明白真正需要的是什么，从而更好的改善企业的业务流程，提高其效能。