BPMN in a nutshell

Business Process Modeling Notation (BPMN) is a standard specification created by Business Process Management Initiative Organization (BPMI) intended to provide a notation that is readily understood by Business Analyst (who creates the business process), Process Developer (who implements the business process into executables) and Business Owner (who manages and monitors he process). Thus, BPMN standardizes the bridge for the gap between process design and process implementation.

BPMN defines a Business Process Diagram (BPD), which is a specialized flow-charting technique to create graphical model for business process operations. The graphical model so generated is a network of directed graphical objects representing activities.

BPMN can be classified in to following four categories;
1. Flow Objects
a] Event - Events effect the flow of the process and usually have a cause(trigger) or an impact (result). Types {start, intermediate event, end}
b] Activity - The work done and can be further classified as Task(atomic), sub-processes(non-atomic or compund)
c] Gateway - They are used to model the convergence or divergence of sequence flow and can thus be used to model decision making, fork or joins.

2. Connection Objects: Using them, Flow Objects are connected together to provide basic skeleton structure of business process.
a] Sequence flow - models the 'order' of activity to be performed, it should be noted that 'control flow' is semantically incorrect in the context of business modelling language.
b] Message flow - models the flow of information.
c] Association - models the inputs and outputs of acivities.

3. Swimlanes: The concept of swimlanes is used to organize acivities into seperate visual categories to illustrate different functional capabilities or responsibiliies.
a] Pool: Intra-group activity for e.g. interactions between customer and supplier organizations can be clubbed using Pools.
b] Lanes: Inter-group activity for e.g. interactions between various department of the same organization can be modeled using lanes.

4. Artifacts:
a] Data Objects: Models the input or output form activities such as Rules, Documents for e.g. order
b] Groups: Models the logical grouping of sequence of activities, does not alters the sequence flow.
c] Annotation: Provides documentation.

BPMN can be used to model collaborations between two or more business entities which may be public in nature or business processes internal to an organization, the difference lies in the precision level between the two. The primary value add that BPMN brings to the table are;
1- Standards based.
2- Easily understood by the complete 'spectrum' of people
3- Designed to be easily transformed to the de-facto execution language standard BPEL4WS.

XML: Cornucopia

... well you see, I discussed in one of my previous post that certifications play an important role in giving structure to your study, they establish a common minimum program to be covered... little did I know that when one is going to study XML it can get tough even though you have an agenda in place. In the absence of any one-stop-key-to-success-guide books available in the market, it is difficult. I could now feel what exactly the phrase 'xml-hell' would mean for people who swear by it :))

The verbosity of XML content has it's own woes... there seems to 'too-much' of information available everywhere... Call it my XML cornucopia ... one neat resource for study...

XML: Design and Architecture

http://www.ibm.com/developerworks/xml/library/x-eleatt.html

When to use elements versus attributes ?

Any one who has worked with XML will very well know how difficult it becomes to answer this question and in the absence of any clear guidelines the whole information modelling exercise may get wrong. The above article provides a head start towards that end.

In some cases the answer is pretty unambiguous:

• If the information in question could be itself marked up with elements, put it in an element.
• If the information is suitable for attribute form, but could end up as multiple attributes of the same name on the same element, use child elements instead.
• If the information is required to be in a standard DTD-like attribute type such as ID, IDREF, or ENTITY, use an attribute.
• If the information should not be normalized for white space, use elements. (XML processors normalize attributes in ways that can change the raw text of the attribute value.)

For the grey areas the tips are:

• Principle of 'Core Content': Data goes to elements and meta-data goes to attributes. Simply put the data elements which form part of 'your' solution domain are element, while those 'qualify' or provide more details about the core content goes to attribute.
• Principle of Structured Information: If the information is 'extensible' make it an element, while 'atomic' tokens goes to attributes.
• Principle of Readability: If the information is to be understood by the human readers make it an element, else create an attribute. As the writer puts it '...information tokens that are not natural language go in attributes.'
• Principle of element/attribute binding:Use an element if you need its value to be modified by another attribute. XML establishes a very strong conceptual bond between an attribute and the element in which it appears. An attribute provides some property or modification of that particular element. Processing tools for XML tend to follow this concept and it is almost always a terrible idea to have one attribute modify another.