Tag: BPM

Sustainable Service Design

We all know the idea of sustainability from our daily life. But is it possible to apply this idea to software development? I think yes.
Sustainable Service Design is a practical approach to design and implement software services with a great level of reuse both at technical and business levels. It is based on the following four principles:

  1. Technology-agnostic service definition
  2. Unified request/response
  3. Consequent contract first
  4. Technology bindings
00_cover_0 If you want to know more, please read my latest article about sustainable service design which has been publised in issue 2.2015 of Javamagazin (German).The interview can be found on the jaxenter site.
In the second part in issue 3.2015 I am showing how to implement a sustainable approach using JEE and JBoss Wildfly.

 

Web Service Security on BiPRO Day

BiPRO At the upcoming BiPRO day on 11.June 2013
I am going to give a presentation introducing the most important standards in the area of web service security. The aim is to show the purpose of the standards and how they work together to create secure and interoperable message based web service solutions.

About BiPRO day:
“Einmal im Jahr treffen sich die Mitglieder des BiPRO e.V. sowie Interessierte aus der Versicherungs- und Finanzdienstleistungsbranche zum BiPRO-Tag. Dabei stehen aktuelle und zukünftige Themenfelder der Prozessoptimierung allgemein und des BiPRO e.V. im Speziellen im Vordergrund. Dazu zählen Vorträge und Präsentationen aus laufenden und bevorstehenden Projekten, die Vorstellung neuer Normen sowie Berichte über Norm-Implementierungen bei den Mitgliedsunternehmen des Vereins.”

Business Process Evolution and Versioning

(Automated) business processes evolve over time! And they usually evolve faster than IT systems do.
So how can business process changes be delivered to the users quickly?

Let’s look at an example:
Assume we have a process for vacation planning for the staff of a large company. Initially the process was automated based on the knowledge of the human resource department. After 2 months new insights require a process change. The process should be optimized to speed up the decison whether vacation is granted or not. The process has evolved and the changes have to be put in place as soon as possible. This is a common situation and actually one of the promises of business process management is: Deliver business value fast.

Sounds simple, but how can we deliver the changed process?

There are serveral options to put the changed process in place:

Option 1: Parallel
The changed process coexists with the initial one for a period of time. Existing process instances must continue with the inital process definition.

Example: Users of the process are gradually trained to use the changed process. Some departments can still use the initial process, some use the new one. The process is triggered by IT systems as well. Those systems should have a smooth upgrade path.

Action: Create a new version of the process and deploy it in parallel to the one already in place.

|--- Startable V1 -------->
|--- Instances V1 -------->
                 |--- Startable V2 --------->
                 |--- Instances V2  -------->

Option 2: Merge
The changed process replaces the initial one. Existing process instances must continue using the changed process definition.

Example: Law changes render invalid the initial process. As of now all processes, including already running instances, must run with the latest process definition.

Action: Create a new version of the process and migrate existing instances to the new process definition.

|--- Startable V1 ------|--- Startable V2 --------->
|--- Instances V1 ------|--- Instances V1 + V2 ---->

Option 3: Phase Out
The changed process replaces the initial one. Existing process instances must continue with the inital process definition.

Example: Process analysis caused the process to be optimized, so that it can be executed in less time. All users should immediately use the changed process.
To keep effort low, already running process instances should continue running with the inital process definition.

Action: Create a new version of the process and deploy it in addition to the one already in place. Prevent the initial process version to be started by disabling the start events.

|--- Startable V1 --------|
|--- Instances V1 --------------------|
                          |--- Startable V2 --------->
                          |--- Instances V2  -------->

Be aware of endpoints:
If process versions are provided in parallel like in scenario 1 and 3 and connected to technical endpoints, for instance filedrops or web services, those endpoints might collide. Changing the structure of an endpoint, for instance the message payload, might cause incompatibility as well. In those cases (which are likely to happen) the endpoints must be versioned. Alternatively a dispatching mechanism can be used to route messages to the appropriate process version.

As you can see versioning is am important concept for process evolution. Which strategy to use depends on the process and the particular business requirements. The options introduced in this blog post might help to take the right decision. Make sure your process platform supports the options you need.

Agile Process Management with Open Source

Are you interested to know how to combine process management, agility and Open Source software? Then the roadshow Agile Process Management with Open Source is for you. It is going to take place in several German cities during autumn 2012. I am going to present ways to achive efficiency in the area of process automation using proven Open Source technologies paired with agile approaches. In times where CIOs have to think twice before they spend IT budget, undoubtely an interesting topic to talk about. It have some interesting ideas to share and hope for inspiring discussions.

Agility through Business Process Automation?

Sometimes business process automation (BPA) is described as the silver bullet to improve agility and time to market. Especially large vendors spend huge amounts of marketing budget to promote their BPM tool suites, “360 Degree”- and “Zero Code”-approaches.

But why does BPM increasy agility? Is it really easier to adapt processes to business changes if a process has been automated using a BPM suite?

Sometimes yes, in the narrow range of allowed options. Often no, cause IT-coded processes are not as flexible as people in an organisation. But that does not mean that business process automation is a bad idea at all. There are areas in which process automation makes perfect sense.

Especially processes for which the following factors apply:

  • clearly structured and predictable
  • repetetive
  • frequently executed

Interestingly, often agility does not come from automated processes itself, but rather from the people who have their hands free for other more sophisticated ad hoc processes. We have experienced that in a large project for an international organisation from the public sector. Provided people have the right skills, BPA can help turning people from “routine workers” to “knowledge workers” (see It is All Taylor’s Fault). BPA allowed them to automate their repetetive tasks. It was a great improvement and productivity gain for the people and the organisation. The key was to give them a tooling that they were able to control, even without much help from IT guys.

Knowledge workers do not need their processes automated. They need other tools mostly to get the right structured information at the right time. IT can help in this regard, but not via BPA. I would call this Business Process Facilitation (BPF) rather than automation.

BPF means giving the people tools to do their job in a efficient manner without imposing predefined processes on them. In other words, it leaves the process and decision power with the people not the machines. User centered dashboards, search engines and adaptive case management tools are examples for BPF. We have experienced this in another project in which we evaluated the value of process automation using a BPM-Suite. In this highly dynamic environment the decision was to not implement BPM as it would have hindered agilty. Instead we implemented BPF to support the knowledge workers. The system mainly focused on efficient data management and decision making.

All in all it is not black and white, not Taylorism against knowledge work. Success comes from a combination of both. The key is focusing on things that are beneficial for the people and organisation. Sometimes it is automation, sometimes not. Process automation is cleary no silver bullet, but if applied wisely and with the right focus it can help organisations to improve efficiency.

Polyglot Workflows with Activiti and Silverlight

My latest article Polyglot Workflows with Activiti and Silverlight has been published in the current issue of JavaSPEKTRUM. After losts of  theory in form of articles and conference sessions, I thought it would be a good idea to present a real example.  The Activiti engine is an interesting product in the area of BPM. If you go beyond simple demo applications you might want to integrate it with existing UIs, such as corporate portals. Silverlight is an interesting candidate for this task. The article focuses mainly on the interoperability aspects of Activiti and Silverlight and shows how easy it is to bring both together.

Core Values of Great Software

Over the last decade I have seen many software solutions. Some excellent and some really bad ones. But most solutions were somewhere in the middle. They just did what they were supposed to do.

But is this really good enough? I don’t think so. Especially today where time to market is critical and the budgets are limited, functioning software is the bare minimum. On top of that other core values are getting more and more important.

  • Functionality – This is obvious.  The software must do what people expect it to do in a reliable manner.
  • Evolvability – This is also known as sustainability. A value that is important in many areas of our daily life. And also in software development. It means that we don’t want to reinvent the wheel over and over again. We don’t want to produce waste. Software must be flexible so that it can be reassembled even if technologies change. Investements have to be saved. Evolvability can be primarily achieved through proper software design. Especially service-oriented approaches are promising here.
  • Production efficiency – This is the most underestimated value. It means that just work is not enough, rather it must be quick and easy to produce. For a long time IT is has a reputation of being complicated and expensive. As a reaction to that companies are outsourcing to cheaper countries or applying more flexibile development processes auch as Scrum to improve efficiency. Especially the latter has proven to be successful. Choosing the right software is also a good way to come closer to that goal. For example frameworks should not only assessed by its functionality (often done by developers) but also on the ease of use and developing performance.

Although those values are important for every software project, they are especially important in todays SOA/BPM undertakings as they promise to increase agility and time to market. This can only be achieved with software solutions that are flexible and easy to use. Ideally even for business people without a developer background.

Three challenges of BPMN 2.0

There are three major challenges in using BPMN 2.0 as a holistic (360°) approach to Business Process Management (BPM):

  1. Semantic Alignment
    BPMN like all other high-level process languages is context agnostic. This is good, as it allows a wide adoption throughout the industry. On the other hand it means that it does not explicitly express concepts found in business contexts, such as customer, accounts, discounts etc. As people from business and IT often have a very different view on certain business aspects, it is essential that they share the same semantic context in order to understand each other. If not, a process designed by a business person will not be understandable by an IT person and vice versa. In case BPMN is applied in combination with an outsourcing approach things get even worse.
  2. Level of Details
    BPMN2.0 is designed for automatic execution on a process engine. The goal is to have one process model from analysis to execution. But people from business and IT require different very levels of detail in their process descriptions. This is why a processes created by business people are usually not detailed enough for IT people. IT processes are usually full of technical information required for automation, rendering the process almost useless for business people.
  3. Portability
    The BPMN standard introduces several conformance levels (modeling, execution, BPEL, choreography). This is good as it fosters reusability of BPMN diagrams amongst different tools. At the same time the standard explicitly allows model extensions, “to satisfy a specific need, such as the unique requirements of a vertical domain” (quote from the spec). Thus, to avoid vendor lock-in, one at least has to be very careful in choosing the right model elements.

BPMN 2.0 should not be applied naively. Unfortunately this is often happens, especially when the standards are young. To be successful with BPMN 2.0 one has to find the right mixture of standards, design principles and methods.
For instance the semantic aligment problem can be mitigated by applying Scrum for analysis and process development. A multi-layer process design can help to address the level of detail problem. And choosing the the right product can increase portability.
This is nothing that comes for free by just using BPMN 2.0. It is rather something that needs to be actively managed by experienced engineers.