此规划侧重于业务战略环境中的业务流程。可与组织中的不同业务线紧密合作的企业架构从由业务战略定义的业务需求开始,并能为主要的企业业务流程建模。比如,企业架构可通过AquaLogic
BPM Designer在设计层面实现这一目的。这将有助于架构师理解企业内全局的主要流程,而且通过让更多的销售代表参与进来还可以推进这种方式。使用AquaLogic
BPM Designer,业务分析师可以模拟业务流程,提供在对流程进行反向工程时发生的优化的一种度量。业务流程规划归业务本身所有。架构师的主要任务是获取业务需求并确认可由组织内的不同业务线使用的共同业务服务。
以银行业务环境为例,首先要先设计各项银行业务(比如贷款、进/出口操作)的流程。这两项银行业务具有完全不同的流程,但也会共享一些共同的服务。共同服务的确认是通过在组织层面设计流程实现的。在某种程度上,授权系统和会计系统应该能在不同的流程,比如开具信用证(LC)的流程或贷款批准的流程,被重用。两个流程应该能使用共同的授权服务和共同的会计服务。
功能规划
设计好组织的重要流程之后,就可用确定主要的功能块了。功能块提供可在不同的业务流程中重用的业务服务。业务服务也是
SOA 理想的构建块。这些服务还应该能被重用和重组,以便提供业务所需的敏捷性。在选择这些功能块以及需要在功能块间共享的数据时,业务线应该提供给企业架构师足够的业务知识,以便整个组织都能重用和理解规范的数据模型、域UML模型和数据存储库。这之后,就需要在规划中加入业务。
这种通用的做法应该会带来可在整个组织内共享的通用的语言和通用的分类法。通用实体和通用域模型的定义使其在组织内的含义通用,而且可以被不同的业务线重用。这个规划就像是个城市规划:将功能构建块组织成与组织内不同的业务线相关的区域和地带。
通用的语言将十分有助于功能构建块的重用以及数据在这些块间的共享。规范模型应该在企业存储库内被共享。管理考虑应该定义设计、访问、验证和修改这些模型的方式。我将在本文后面的部分对这些考虑事项详加介绍。
回到银行这个例子,在这个组织中,应该有一个业务线用来处理付款、外币兑换和抵押,另一个业务线处理贷款,第三个业务线处理进/出口操作,比如信用证(LC)和收款,还有一个水平的业务线用来处理授权、会计、报告以及风险管理。如果用城市规划来做比喻的话,每个业务线都可看作一个特区。
进一步观察进/出口这个业务线,还会发现分别与LC和收款相关的功能块。而代表LC 的功能块还可以细分为LC所应提供的不同的服务。这个块应该提供功能(或服务),比如开具LC、修改LC、使用LC和偿还
LC。这些都是LC块的业务服务。这些服务将依赖于由授权块、会计块和付款块提供的功能。
授权块将基于客户的状态为客户授予信贷额度。授权块可能会依赖于风险管理块的功能。LC功能也将使用由会计块和付款块提供的服务,而付款块则将会使用会计块和授权块的功能。
对功能规划的描述采用业务术语,并加以细分以使它能映射到应用内的应用程序和服务。在银行示例的这个环境中,会计服务和授权服务在组织层面上重用。
确定了这些功能构建块之后,还需要定义这些块之间的通信,这就意味着形成规范的数据模型。这个规范模型可使用UML模型进行描述,这就带来了数据的XML表示。这个通用语言应该跨整个组织共享。
在银行示例中,不管是在LC块还是在贷款块使用,账户都是一样的,客户也是相同的。账户和客户都是在跨组织的共享业务模型中定义的实体。这些实体由两个规范模型表示,一个用于账户数据,另一个用于客户数据。这些模型可由整个组织共享。它们可通过作为组织构建块的一部分的公共服务访问。这些服务可以是
CRUD (Create Retrieve Update Delete) 服务,也可以是复合服务。定义规范模型的最好的方法是参考业界标准。银行系统使用SWIFT
标准。在 SWIFT标准手册中定义的. MT 消息在业务用例使用消息的层面上定义了银行操作。这些消息可以轻松映射成可在整个组织内使用的
XML 消息。最大限度地遵循标准非常有助于将单个组织内使用的业务操作扩展到多个组织间的B2B 操作。
定义了块中使用的功能块和数据模型后,这些资产应该能由企业存储库中的不同业务线重用。BEA AquaLogic
Enterprise Repository 可用来共享企业信息资产。