There are many processes that are information or business object centric. In such cases the entities have their own lifecycle and interact with the external world using services. Process analysts must however be careful on ensurign that they are now mixing business ownernship and separate the correctly the facettes that are owned by different owners in an organization. As an example the Telco standard information model clearly differentiates "the Customer Order" owned by customer facing organization from the "Service Order" and "Resource Orders" owned by other organizations in the enterprise.

Then the approach analyzes the state charts for each entity.

This approach can also be taken when different organization have to share a common entity such as a customs manifest declaration. The public entity and its public life cycle can be passed as an SCXML State Chart XML W3C SCXML Standard document. A reference implementation of SCXML available from Apache SCXML project.

The following picture describes such document bei exchanged between different organization and agencies, each with its own IT infrastructure. The only requirement is that each of those organization is able to interpret the SCXML standard to make out how the entity should be handled. It addition the document can carry the history of events that enables each stakeholder to reconstruct a monitoring view.

Managing the complexity of business processes

Enterprises embarking on the business process management journey must ensure that they keep the gains that business processes provide by controlling the cost of their life cycle. Particularly, a process quality approach is essential to enable low-cost changes. This article should interest business architects, and IT managers and architects as it discusses an approach to controlling the development and maintenance efforts for business processes by limiting their complexity.

Well here it comes again. Today I have been confronted to a project where the teams did not understand the need for variability and replaced the Characteristic Value variability pattern from the SID Telco model with static tags for each attributes.

At the end they make their interfaces signature rigid and will have to introduce new services for each different type of orders or products. This is typically what happend with Client-Server where changes on the server side propagated to the client side. We absolutely must avoid to use that Client-Server on Web Services approach for SOA as it ends up propagating and amplying the cost of changes to service consumers ,whether they are processes or other applications.

SOA needs to be about business or semantic loose coupling where the interfaces can absorb variations without having to change all of the consumers that use that specific interface.

The characteristic value pattern from the SID is as follows where the value point to a specification that defines the type, name and constraints. The information is structure in stable parts and variable parts with the variability of the information model enabled by this pattern.

An example of such variable message is also provided. The Characteristic values can be added to described very different aspects and do not change at all the structure of the messages even when adding new attributes to a product, service resource or a customer.

It has been a long week since my last entry ;-) , publishing a book uses a lot of bandwidth.

Before going into variability, I want to explain the issue leading to variabiltiy

We have often forgotten that services exposed information that is carried by processes. Thus if the information evolves in its structure it will propagate to services and processes. Let me give you an example that I experimented in a project: A product catalog may contain attributes for these products. Whether these new attributes were represented or not as new columns in a database, they ended up being new tags in a schema such as <TV_Channels> for a video on demand product. Given that the schema changed the services accessing the product catalog changed signature, and the business processes using these services had to be regenerated and tested. Two product attribute changes per week were occuring, and the system test for the affected processes was 2 weeks on average per process. This ended being a catch 22.

That being said, I now need to answer to the following questions, how can I model the information to prevent structural changes and how can I evaluate the testing effort of a business process.

On the first question, I wrote a full chapter on various techniques in my book, including xsd:any I already mentionned, in this blog but the one we used in the specific case is the CharacteristicValue and CharacteristicSpec pattern from the Telemanagement Forum SID model for Telco operators. This model defines a characteristic specification that will describe the attribute with metadata, including the allowed values the type and validity dates. The characteristic value itself has a link the specification so that a common specification can be used for many values.

On the second question, the experience shows that creation, change and test effort of processes is roughly proportional to the number of arcs (connections) in a given business process. Even if you only change a small aspect you will need to test all internal variations. It is quite common to have two to four person hours of effort per arc in the process.

The following picture shows that with only 3 tasks and 5 nodes in a process you can have 10 arcs, so you may expect 5 days of test.

Another important aspect of variability are rules and policies. A consistent enterprise approach to rules and policies will require the creation of a common business vocabularity which content must be aligned with the concepts in the information model.

With OMG's SBVR there is now a standard for the structure of rules and policies but not of the contents which will always be specific to an industry and/or an enterprise. The vocabulary will describe the core elements of the information model, while the rules content model will define the acceptable value ranges when they are required by rules or policies.

If we now integrate this information variability with SOA and BPM but also with rules and policies we can have business processes which behavior is driven by the content of information and is much less sensitive to changes. Using a business vocabulary for the rules with a human language like rules or policy description enables business users to manipulate the rules and shift the changes from IT to business. In a further blog entry I plan to give real examples of such policies.

I use the Business Process Modeling Notation (BPMN) categories as defined in BPMN 1.1 standard to categorize and modularize business processes.

There are three basic types of sub-models categories within an end-to-end BPMN model:

1. Collaboration Processes is the first category: it describes exchanges between 2 independent business entities. These processes just describe the exchanges between the different processes and ensure the good mutual behavior. To take a railway analogy this is the network where the collaboration process ensures the synchronization by managing the signaling for trains to avoid collisions.

2. Abstract (public) processes are the second category: They provide the end to end view from a participant point of view, like the view that a train engineer who drives all of the trains but leaves each wagon responsibility to the respective conductors. He only care about the overall length and weight of the process (train) and the behavior of the links.

These models are use to create the end to end monitoring model by capturing events that surface from each of the smaller modules (the wagons).here is often a confusion between this monitoring model which higher management of the enterprise requires and the process automation which is provided from the next category of processes which are smaller modules.he monitoring model can take actions based on indicators it controls.

3. Private (internal) business processes are the last category: they have a single business owner and usually focus on a main core entity (from the information model). These are the only processes that should be automated with a BPEL. Each wagon is a separate process as it usually has a different business owner. The business owners define the contracts between their processes as business services that act like the links between wagons in trains. Any automated process that has multiple owners ends up being unmanageable because of the conflicts that always occur in that case. The technology for each module can be different represented by a wagon or the locomotive). The CRM can be Siebel, the billing SAP and the Supply Chain WebSphere Process Server. The monitoring model above does not require the technology to be the same provided that you expose appropriate events for the monitoring model.

Next week I will expose information variability and its impact on services and processes.

Achieve Breakthrough Business Flexibility and Agility by Integrating SOA and BPM

Practical from start to finish, Dynamic SOAand BPM squarely addresses two of the most critical challenges today’s IT executives, architects, andanalysts face: implementing BPM as effectively as possible and driving more value from their SOA Investments.by Marc Fiammante

On the SOA front I had a very constructive discussion with Jérome Hannebelle from France Telecom/Orange (he wishes to be quoted) on a variability approach that differentiates the provider WSDLs from the consumer WSDLs. His interesting position is that to avoid the impact of version change the providers should expose more generic WSDLs with xsd:any for all the service message parameters branches that are subject ot release variations, however consumers should for the same service be provided with validation WSDLs that have explicit definition of the parameters for a given release. The provider then need at run time to identify the service request version an apply the appropriate routing and handling behind the service facade. This approach is a variation of the patterns I describe in my book where I already state that the umtimate provider's granularity and interfaces may be different from the consumer view. The implication is the dependency tree management in the registry that it implies to that there is explicit correlation between the various consumer validation WSDLs and the provider WSDL.

On the fun side Las Vegas is an interesting location, I flew a total of 15 minutes at the indoor skydiving tunnel. A safe way of experimenting skydiving feelings.

What is the good ganularity of services ? Well I like to reformulate this question in what is the manageable granularity of services. How many services methods or interfaces can we manage in an Enterprise. If we take a decomposition like APQC Process Classification Framework at the task level which is the 4th level of decomposition, we get aroun 1,500 tasks for the cross industry elements. Each task would have several interfaces or methods. Looking at other decompositons like IBM's Component Business Modeling which is a two level decomposition or Telemanagement eTOM Business PRocess Framework we get an average of 7 to 10 elements at each level of decomposition. This would lead to a potential of between 10 thousand and 100 thousand interfaces at a level 5 of decomposition, which I think everyone would agree is not manageable.

The implication of that simple math is that a manageable granularity is between a level 3 and 4 of decomposition, and if you end up with finer interfaces, we need to consolidate into more variable paylod interfaces at a higher level. It also implies that a decomposition exists in the enterprise otherwise there is no way to find what is the decomposition level of a service.

As I mention in my book we have too much considered SOA as client/server on Web Services. We really need to think variability as a way to enable reuse and avoid the propagation of provider changes to consumers and vice versa. In complement to the approach for variability I describe in my book looking at information variability, service variability and process variability here are two good articles on variability that an architect I work with in a large european bank just sent to me as we are working on these topics together for that bank.