Services can be used to provide a consistent mechanism to expose and combine various technologies and their infrastructure capabilities. The intent of SOA is to provide common reusable SOA Services that can be leveraged by a variety of consumers. SOA Services are made available to various types of service consumers in order to rationalize the way business functions are performed and enterprise data is managed
SOA acts as a value-add layer on top of existing IT assets. It exposes these assets, as well as custom-built capabilities, as reusable SOA Services. SOA Services will typically originate from functionality and data that already exist in the enterprise – SOA Services created by “service-enabling” existing assets. As new projects are implemented, standalone SOA Services may also emerge as autonomous entities that do not have dependencies on existing systems.
SOA also includes infrastructure to aid in the discovery, management, mediation, monitoring, and security of SOA Services. Consumers discover and interact with SOA Services via the SOA infrastructure.
BPM and Services
BPM Solutions are composite applications in the form of business processes. Business processes are collections of activities, orchestrated in a controlled sequence, to accomplish a unit of work. The unit of work is generally related to common business functions, for example: product sales, order fulfillment, and employee benefits enrollment.
The spectrum of business processes can be defined as having two extremes: purely human-centric processes and purely system-centric processes. Quite often processes will be comprised of a mix of human interaction (manual activities) and system interaction (automated activities). Though any processes can involve both types of interaction, there are reasons to consider them separately. In addition, a third type of workflow pertaining to document management should also be taken into consideration.
BPM and SOA are often used together, as they both support a closer alignment between business and IT, and they both promote agility.
BPM targets alignment and agility at the process level, while SOA applies more at the activity level. Hence, business processes and SOA Services can represent business constructs, providing a mapping between the things business does and the way IT helps get it done.
The convergence of BPM and SOA generally happens via process decomposition. That is when business processes are modeled as, (i.e. decomposed into), activities. All automated activities must be backed by some form of executable code or function call. These functions, if they are deemed worthy, can be engineered as SOA Services following service-oriented design principles. Agility at the process level is attained by changing the process model. Agility at the service level is achieved by deploying services that are loosely coupled and independently managed.
Further, BPM processes and sub-processes can themselves be exposed as SOA Services. This enables processes to be composed of SOA Services that are implemented as processes. It can be beneficial in two ways. First, it improves reuse of lower level system-centric processes (i.e. service orchestrations), and second, it offers a standard interface mechanism with which to invoke all types of business processes.
In my next blog I will address other types of solutions such as MDM, BI, and EDA.
Good Luck, Now Go Architect…
An Enterprise Architect's Musings 