ADF/BPEL Architect at Revere Group (Chicago, IL)

(Oracle SOA Suite 10g, Oracle SOA Suite 11g) with Oracle BPEL and Oracle ESB (Mediator) and Oracle AIA PIP Experience in working with Java Messaging Service (JMS) and knowledge on Business Rules and Business Activity Monitoring activities…
Bpel jobs | Simply Hired

Why a Business Architecture?

The main goal of a Business Architecture is to enable the business to improve customer service quality through a better transparency, flexibility and adaptability of business operations. The market environment changes more rapidly and the use of technology by customers dramatically influences how a business can operate. Financial services calculation processes, marketing programs, business rules and content change already weekly rather than monthly.

However, if a business architecture has to be modelled, encoded and assembled by using a large number of tools and software components it cannot provide the benefits. Today’s heavily fragmented and hardcoding-integrated IT systems (including SOA) are too rigid to enable rapidly changing business environments. Most IT departments do not focus on adaptability and innovation because they have been requested to focus on lowering cost and system stability. Therefore, six month rollout cycles are the norm with three month being the exception. Business users expectations of stability and executive demands for lower cost are incompatible with the ability to achieve a flexble and adaptive, competitive IT infrastructure. Efficiency is still the main IT goal, with effectiveness a far-off second and agility being no more than an overused buzzword.

Combine this with the misconception that running a business can be pre-planned and therefore encoded into processes and rules, with decisions being taken by predictive analysis based on historical (or better outdated?) business data. I propose that good business decisions are always taken by experienced people who use intuition to combine relevant data in business context. After billions of IT investments neither process management nor business intelligence have delivered the promised wonderland of the automated enterprise that the board can run remotely from the beach. Why?

Neither BPM nor BI consider the human side of running a business and therefore fail to produce a nimble, agile organization. Based on unproven management theories and over-optimistic information technology benefit claims a huge IT bureaucracy is now necessary to manage a complex technology stack. Control and use of the technology stack is only feasable through outsourcing partners and the necessary complex contracts reduce corporate agility even more. Billions are spent by the IT monopolists for marketing to sell an illusion of the IT-controlled business that does not exist and is not achievable by the proposed complex means.

The above situation was the reason for ISIS Papyrus to develop a new IT platform that does not require a huge technology stack and does not need complex programming but a simple modeling and rule definition methodology to build a flexible and adaptible Business Architecture that is mostly under the control of the business and not the IT department.

Agility AND innovation happen on the people level. BPM and SixSigma trash out the people empowerment slogan but fail to deliver because in neither approach people are given the freedom to do things as they see fit as long as the goals are achieved. Enterprise 2.0 is a countermovement to the bureaucratic IT-Governance approach, but if it is simply putting Web 2.0 behind the firewall without giving the user access to plausible business data entities there is not such thing as empowerment.

William of Ockham wrote in Numquam ponenda est pluralitas sine necessitate: “The explanation of any phenomenon should make as few assumptions as possible and not invent further entities to explain a theory.” He was a friar and felt that the one entity of God would explain everything. Bertrand Russel translated it to: “The simplest explanation is usually the best.” Translated further to IT means that coded software systems or process solutions that require substantial resources to be model a business and even more to then adapt it to changing needs make things more complex than necessary. Flexibility AND adaptability by the user – while ensuring transparency and maintainability – are the key capabilities of modern systems. SixSigma adds a lot of bureaucratic complexity that is certainly not in line with Occam’s Razor. Let’s simplify …

A detailed description of Business Architecture features of the Papyrus Platform you will on my Papyrus Architecture blog.

BPMN 2.0 – A Step Sideways!

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?

Build Service Oriented Composite Applications with new Book on Oracle SOA Suite 11g

Getting Started With Oracle SOA Suite 11g R1 is a new book from Packt that helps develop service-oriented composite application using the much anticipated Oracle SOA Suite 11g. Written by Oracle SOA Suite Product Management team members, this book walks the reader through the development of a services-oriented applications based on a real-life scenario.

Oracle’s SOA Suite 11g is an integrated, best-of-breed solution that helps build and manage large, highly demanding SOA projects. This book offers a hands-on approach to learning Oracle SOA Suite 11g and provides a comprehensive overview of the Oracle SOA Suite 11g Product Architecture.

This book provides an introduction to key SOA concepts, and emerging standards such as Service Component Architecture (SCA) and Services Data Object (SDO). Users will learn the fundamentals of Oracle SOA Suite 11g platform infrastructure, including; Web-Service Binding, Mediator and Database Adapter as well as understand the core components that make up the Oracle SOA Suite; namely BPEL, Human Workflow, Business Rules, and JMS Adapter.

Developers will learn to enhance their composite application with Policy-based Fault Handling, Business Events, Sensors, and Security policies. They will be shown how to enhance their project with Business Activity Monitoring (BAM) and B2B integration in addition to using the Oracle Service Bus for service virtualization. Additionally, developers learn to assemble services in order to build composite services and long-running business process.

This book is ideal for both new and experienced SOA developers looking for a hands-on approach to learning Oracle SOA Suite 11g will find this book useful. For more information, please visit: www.packtpub.com/getting-started-with-oracle-soa-suite-11g-r1/book

Model SOA Business Processes Using Bpmn

Modeling business processes for SOA and developing end-to-end IT support has become one of the top IT priorities. The SOA approach is based on services and on processes. Processes are focused on composition of services and in that sense services become process activities.

Experience has shown that the implementation and optimization of processes are the most important factors in the success of SOA projects. SOA is so valuable to businesses because it enables process optimization. In order to optimize processes, we need to know which processes are relevant and we have to understand them – something that cannot be done without business process modeling. There is a major problem with this approach – a semantic gap between the process model and the applications.

This book will show you how to fill this gap. It describes a pragmatic approach to business process modeling using the Business Process Modeling Notation (BPMN) and the automatic mapping of BPMN to the Business Process Execution Language (BPEL), which is the de-facto standard for executing business processes in SOA. The book will also cover related technologies like Business Rules Management and Business Activity Monitoring which play a pivotal role in achieving closed loop Business Process Management.

This book is for CIOs, executives, SOA project managers, business process analysts, BPM and SOA architects, who are responsible for improving the efficiency of business processes through IT, or for designing SOA. It provides a high-level coverage of business process modeling, but it also gives practical development examples on how to move from model to execution. We expect the readers to be familiar with the basics of SOA.

The book has been published and is available from Packt. For more information, please visit http://www.packtpub.com/business-process-driven-SOA-using-BPMN-and-BPEL/book

Next Page »