Cellphone Gadget and Technology News

I have just taken a further look at the BPMN 2.0 proposal to see if we could use some of its standard graphic modeling concepts for our process visualization in our Papyrus Platform. I was very disappointed. The enhanced and additional definitions create ambiguous models. An ‘Activity’ can still represent any number of different functions and the new event types are lacking in detail on how they interact with the flow. There is still no artefact method, attribute and state modelling and no business rules. The proposed UML-like data modeling seems non-existent. Thus, it will be impossible to use BPMN 2.0 for exchange as-is and it still has to be transcoded to an executable format (i.e. BPEL plus Java) using additional information that is not mapped into BPMN. Thus, no roundtrip and user empowerment! All inbound and outbound content and GUI artefacts will still have to be programmed. Hence, a lot of project management bureaucracy.

Obviously a lot can still change and maybe 2.0 will take a few more years to become a final spec. But I feel that all that is to no avail as it remains firmly footed in the flowcharting domain. But what are we trying to achieve with a process model? Gain an understanding to calculate how the systems will react given a certain situation? Simulate what will happen when certain actions are taken? Control the system so that it becomes more manageable? Achieve transparency of the processes en-route and completed?

A BPMN model has only the acting agents (users) as real world entities whose functions and decisions to perform these functions can’t be modeled unless substantial abstraction is performed. BPMN 2.0, as all flowchart models, is STILL functionally blind to the inner function of the major elements of a business process (content data and context) and therefore to its decision logic. Flowchart modelers see the world (a business) as a ‘complicated’ system that can be decomposed into a sequential causal chain of functions ‘to be executed’ and a limited set of states that causally control the execution. The relevant process knowledge is however hidden in a) functions performed by different agents who influence state changes on business entities and b) patterns of entity states and attributes that cause different agents to perform certain functions, and c) a variety of complex business events that can change entity states at any time. Flowcharts are unable to represent that even if one could extract and analyze all the information from the agents and the entities! As bad as that is, it is not the key problem.

A classical model of physics (i.e. a watch) is complicated, but the economy or a large business that consists of individually acting agents is complex (Anderson, Arrow, Pines – 1988). The flowchart fallacy is to see a business as complicated rather than complex. Holland et. al (1986) proposed a method of real-world modeling in which the world consists of various states S where a transition function F(S) changes a given state at time t into a new state a time t+1.  The caveat is that in a complex system the modeler using a modelling function can neither accurately describe the state space with all its entities nor can the function F – and its causality – performed by the agents be accurately known.

While the Law of Large Numbers allows us to build a statistical representation of real-world situations across a large number of entities and thus there seems to an emergent pattern, this does however not describe a causal law. The LOLN is an observation and cannot be decomposed into why the various agents came to a particular decision. The individual agents have only a certain probability to interact in a certain way and as much as that can be modelled, it does not allow the modeller to deduce a function to act causally correct on all entities in the same manner. The simplified ‘complicated’ model will therefore be quite wrong when people are involved. That explains why the reductionist approach works well for a robotic production plant but not for people.

The reductionist modeling hypothesis suggests the more a decomposition in smaller elements takes place the more accurate the model would be. Anderson proposed in 1972 that reductionist models are misleading for complex systems because they cannot map and predict emerging properties. Thus they cannot be used to construct the system from the decomposed bits and pieces. The model representation in such situations can only happen through destroying and redrawing the blueprint using the new functions or entities. The reductionist ‘complicated’ model cannot adapt to external influences or to changes in its agent functions.  Flowcharting is acccordingly abstraction based, top-down modeling of complicated functions that connects purely hypothetical snapshots in time with statistically inferred rules that are not causal in reality for a complex adaptive system, just as global warming theory.

Hereto I propose (as I have done for the last ten years) that BPMN 2.0 and flowchart models are still a failure for designing business processes, because a large business clearly is a complex adaptive system that consists of individual acting agents with its employees and customers. Trying to simplify a business into a ‘complicated’ system, forces the agents into non-individual actor-robots and makes the system unable to adapt to the customer agents or to other environmental changes, except if one goes back to the blueprint. That is exactly the situation why we have IT Governance and Centers of Execellence bureaucracy who have to redesign the blueprints. As this typically requires long and difficult projects to implement, BPM reduces the agility of a business rather than improve it.  If agents (such as customers would) refuse to be controlled, the model breaks not only down but produces wrong results.

I propose that a bottom-up approach of real-world objects that can map state-changes and identify causal patterns from unimpeded user activity creates a much more realistic and adaptible model of business activity. Rather than to enforce the agents to perform in a certain way, the system simply enforces basic rules of the game and creates substantial transparency and therefore flexibility and adaptability. Process management has to offer complex real world models of people acting as a social group on business entities. Flowcharts are at most usable at a very high level, for example to show the dependencies between process owners and their goals.

As for BPMN 2.0 or any other flowcharting BPM approach, why would you want to reduce your business agility?

It is also marked that in the last few years, graph of IT Outsourcing is on the rising way. Now IT Companies are sending work overseas to the countries like India and China to develop even smaller business applications. These countries possess most of the share for Software Outsourcing services. Along with these two countries other destinations like Russia, Philippines and many more are also emerging as a service provider for Offshore Development.

Software Outsourcing is concerned

Software Outsourcing to these destinations take place because the labor cost in such destinations is very low. IT Companies from the house of America and Australia are finding these destinations the most suitable for the development purposes. Though, Offshore Software Development might create some threats in the mind of the localized people from these countries. But at the end of the day IT Companies are finding this way of business the most convenient for many reasons apart from the cost benefit. As far as Software Outsourcing is concerned, fear is a reasonable enough response in the mind of these people, but not an effective survival tactic as the companies are now more and more evolving for such IT Outsourcing services. Though, these people thing that IT must take some different route than moving beyond the territory.

Keeping IT services inside the territory for these countries has been impossible as they are finding lots of benefits by shifting the jobs to the lower cost destinations with compared to their local development teams and companies. Along with Software Services, BPO (Business Process Outsourcing) in telecommunication sector and other sector is also on the boom in the current market scenario. By these processes IT companies can expand their business beyond the local territory without real investment. Flexibility and cost are the two most important factors that lead the IT Companies to move their jobs to the overseas destinations. You don’t have to put real efforts to expand your market by this way of the business process.

BPEL or Business Process Execution Language (an XML format) was created according to the vision that process definitions should be interchangeable between BPM vendors. While that sounds like a noble target, I question its validity. Today BPEL is only supported by that vision as in reality it is unfulfilled. I will explain why that is my point of view and why it causes opposition. People either subscribe to that vision or they are implied to have deeper, immoral motives such as locking customers in. The truth is that any product (BPM or not) locks a customer in, one way or the other. The most successful vendors in doing this are IBM, Oracle, Microsoft and SAP. So maybe BPEL is not a visionary concept but just an ambition for more market share. The current expectation is that once these monopolists will fully endorse BPEL they will push the poor rest out of the market. The means could be a standards-based process language called BPEL.

There are over 200 other BPM vendors in all imaginable flavors. Less than ten percent of those vendors support BPEL and their implementations are not fully compatible. Therefore it is strange that some claim that BPEL is the ‘de-facto’ industry standard. Yes, it is the only thing that comes close to something that looks like a standard. Of all the languages that anyone would want to code, BPEL is (like any XML format) not something you want to write natively. Certainly not a business analyst. But the vision and claim is that BPEL resembles process code that can be taken from one BPM vendor to the other with little to no effort. That, I am sorry to say, is an illusion. Where it is part of a sales pitch it is a straight lie. It is true that you can upload the BPEL code, but that brings hardly a benefit.

When you look at how various BPM environments are implemented then you will find each one to be utterly unique. The possible combinations of operating systems, Java server versions, database servers, business rules, content integration, GUI frontend functionality, browser and portal functionality, backend application service interfaces (SOA or not) and more (such as security interfaces) go into the several thousand. BPEL exists in multiple versions (1.0, 1.1, 2.0 are quite incompatible) and allows proprietary extensions most of which are in native Java code. So it is an illusion that you can take the BPEL code along and then simply run it in another BPM environment.

Let me take this further. As you do not want to maintain BPEL code, why would you even worry about it? What you want to maintain is your processes and these should be maintained in a graphical manner and if at all be saved in something like BPMN, which is another dreadful XML format but at elast represent a graphical notation. BPEL and Java means that you need to work in Eclipse, which is a programming tool (another so called ‘standard’) and nothing else. BPEL is a functional subset of BPMN and thus a true roundtrip is not possible.

BPEL does not solve any other issues of BPM like the necessary process monitoring. A customer service centered organization does not care how you execute a process as long as it meets the business goals. So what we need is to monitor business data that represent those goals. Some of them may be process related such as elapsed time for completion of a customer service task. Monitoring business data requires access to those data and they need to be defined. In what way BPEL would support standards-based tools for business monitoring has not been explained.

BPM as a principal concept represents also a vision where the noble target replaces pragmatic and realistic achievements. There are no vendor independent studies that prove that rigidly managed process flows are beneficial to a business. Executives chase the illusion that they can implement a business model with IT that will allow them to run the business by remote control.

For decision making and monitoring the business achievements against goals, it is necessary to have access to real-time business data. BPM people speak of using ‘a common semantic set’ when they mean metadata definitions that correlate to the service interface data. Therefore not only BPEL has to be compatible but also business architecture metadata. BPEL offers nothing for both needs at all. Presenting real-time business data to the business user in the process requires Java code to pull the data from the service interface and present them.

The other element that is needed for pragmatic use of process is business rules. One can convert business rules into BPEL, but then they cannot be executed as complex rule sets that are triggered by data changes or business events.  Business rules also act on business data so you need to code more Java to pull them from the service interface and pass them to the rule engine. Business rules have however multiple purposes with the most important one being so called boundary rules that are essential for auditing. The better your boundary rule set is, the better you will catch exceptions and violations automatically. Thus those rules should not really be an integral part of your process but rather an independent definition but tightly integrated into the process execution. There are some non-BPEL product that handle real-time data and rules quite well.

Some vendors propose BPM 2.0 and other visionaries already propose BPM 3.0. They say that it will not happen without BPEL. I think they are right. Therefore there will be no BPM 2.0. Or even 3.0. BPM in its current rigid form with or without BPEL and BPMN is a dead-end. New technology concepts are required.

What would this new technology need to look like? If any technology concept can foster successful process management, it has to be business facing and enable real-time metadata-driven model execution, while engaging business directly in continuous process change cycles. To enable business participation, a secure change management environment is required that controls the lifecycle and manages deployment.

The only way that business users can be involved in designing processes is by using graphical means of process representation that has to include rules and event handling. Non-technical business analysts must be able to modify processes, rules, and presentation and content. In difference to widespread opinion, process management does not improve business agility by mapping out all activities in flowcharts. That was ok when companies worked the same way for decades. Today companies need to be able to adapt on a weekly basis. The best way to plan and represent a process is by defining the user roles involved, the data entities required and how they are serviced by backend applications, business rules, user presentation and content definitions. Content state drives the process forward.

The problem of complex summary states of content has led to innovative functionality. Consider a software agent who will monitor user activity in a business process (case) and automatically discover the data and state patterns that repeatedly cause user activity.

Conclusion: When BPEL and even BPMN are looked at from a pragmatic business need perspective the only acceptable benefit is that products that use them have similar functionality and people designing processes will find it easier to switch products.  Given that with other products that low level of technology is never touched, that potential benefit becomes a moot point. You can line up BPEL with Java and SOA. Nice idea, but …