SOA Manifesto rambilings part 4 (what else?)

The Manifesto does not tackle any relationship between PROCESS ORIENTATION and SERVICE ORIENTATION. In this blog I'll tackle this link and explain why they go hand in hand. The only reason this was not done in the context of the Manifesto was time and focus.

So here is my take on why it is in fact important and perhaps one of the most important aspects to SERVICE ORIENTATION and SERVICE ORIENTATED ARCHITECTURE.

PROCESS ORIENTATION is a paradigm that constrains a solution to focus on the underlying flows between components where a component maybe a person or an agent for a person (e.g. a portal) or a software component (which maybe embodied by a SERVICE CONTRACT).

BUSINESS PROCESS MANAGEMENT (BPM) is the management of PROCESSES that are formulated by applying PROCESS ORIENTATION. A BUSINESS PROCESS MANAGEMENT SYSTEM is a software platform that supports the construction of PROCESS DESCRIPTIONS, their simulation, execution and life-cycle management.

ORCHESTRATION (as embodied by WS-BPEL) is a mechanism for describing, simulating and executing COMPOSITE SERVICES which are “orchestrated” by means of a some flow between them to deliver a new SERVICE.

Today BPM and ORCHESTRATION are common bed-fellows. Many companies use the former to deliver the person based workflows and the latter for composing complementary SERVICES, which may then be consumed by a BPM layer. In the future these two bed-fellows will merge with the introduction of WS-HumanTask and Bpel4People. These two related standards will deliver the necessary descriptions to enable both BPM and ORCHESTRATION to be merged.

When we think of BPM and SERVICE ORIENTED ARCHITECTURE we need to understand where things are today and where they may be tomorrow and deal with the present and plan for the future. Typically a BPM SERVICE ORIENTED ARCHITECTURE approach focuses on the encoding of PROCESSES at the business level so that legacy applications involved in the PROCESS are SERVICE ENABLED along the way. The reason to do the SERVICE ENABLEMENT is that it is a cheaper and faster route to leveraging legacy application within an overall BPM context. This is the case because of the huge technology investment in tools to SERVICE ENABLE and in BPM to leveraging SERVICES.

Successful BPM and SERVICE ORIENTED ARCHITECTURE projects (together or separately) are all dominated by a clear view of business value to be delivered. They are often preceded by a Proof of Concept which is constrained and focuses on key integration aspects (for SERVICE ENABLEMENT) and key PROCESS aspects (which manifest business value).

Key to business value is the identification of value based on a clear understanding of the vision and mission of an enterprise coupled with strategic goals. This is the case because the strategic goals, which are derived from the vision and mission, provide clear guidance as to where the value lies. Identification of the strategic goals and the Key Performance Indicators that go with them enables a project to be framed that has clear business value and so when delivered can be measured to determine the value delivered. The same Key Performance Indicators and their derivatives may then be used to monitor and measure the running PROCESSES and their attendant SERVICES and the delivered flexibility provides the means by which the solution can be tuned and adjusted. This ensures that the run-time governance of the solution always aligns the solution to the business goals through their expression in the Key Performance Indicators.