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.


BiPRO takes SOA to the next level!

The advocates of Service Orientation always pointed out that SOA comprises 50% technology and 50% business. At BiPRO this vision becomes true.
BiPRO is a standardization organization for the insurance industry. BiPRO has members from the entire market including well known insurance companies and agents. By standardizing services at the business level using proven technical standards, BiPRO really takes the SOA idea to the next level. BiPRO conformant services are reusable and highly interoperable. Development is contract first, based on open standards such as WSDL and XSD. It is really impressive to see what BiPRO already achieved.

On 25.6.-26.6. June BiPRO-Day 2014 is going to take place in Düsseldorf Germany.


At the event I am going to give a live coding session. In particular I am going to show how to implement and secure BiPRO services using current Web Service standards such as JAX-WS, SAML, WS-Security and WS-SecureConversation. Attendees can see how the implementation works with JBoss Wildfly, Apache CXF and .NET. Moreover they can take a peek into the future of BiPRO standards in the area of security.
I hope to see you there!

Capacity Based Velocity Calculation for Dynamic Agile Teams

Traditionally the velocity (V) of agile teams is calculated as number of story points (SP) delivered per sprint. If our team is static, that means, it consists of the same or at least the same amount of people in each sprint we can get a velocity that really reflects the team performance.
Although highly desireable, from my experience static teams are not very common. In fact most teams have a certain degree of dynamics, especially in long running projects.

Typical reasons are

  • Vacation or sick leave
  • Daily business (especially team members from the business are not 100% commited to the project, as they still have their daily duties)
  • Partial engagement (specialists are only part of the team when their knowledge is required)

How can we calculate the velocity for those dynamic teams? By taking capacity into account and combining it with the team velocity. I can recommend following procedure that I used on several projects with very good results.

  1. Have a sprint planning meeting with all people that might have something to deliver in the next sprint or delivered something in the previous sprint.
  2. Ask every person how much days she plans to commit to the next sprint. This is the planned capacity (PC). Adjust PC if necessary during the sprint planning session based on the selected user stories. Use PC as a basis to plan the next sprint.
  3. Ask every person how much days she really committed to the previous sprint. This is the delivered capacity (DC). The delivered capacity might differ from the planned capacity announced in the previous sprint planning metting. That is normal for the reasons given above.
  4. Calculate the capacity based velocity like this CBV = SP/DC.

The advantages of capacity based velocity are:

  1. It is based on empiric data (delivered capacity instead of planned capacity). It reflects what really happened and not what was supposed to happen.
  2. It grounds story points (virtual) with capacity (real) as it takes capacity into account in addition to the story points. But beware! Once the SP/DC ratio (how many days do we need to implement a story point?) is known after some sprints, it is tempting to perform planning with capacity instead of story points. This is a bad idea as it brings us back to the notion of exact planning which we (hopefully) learned is not possible.
  3. It allows the projection of realistic project release dates as we have a stable measure even if the team structure varies.


Understand your Team with SCARF

If you are a Scrum Master or coach you might sometimes wonder why people act and react the way they do.
The SCARF model can help you to understand which factors are driving peoples reactions.
The model lists factors that cause a reaction of either approach or avoid. The factors are:

Status, certainty, autonomy, relatedness and fairness

Here are some ideas what you can do to minimize reactions of avoidance in your Scrum team:

  1. Increase status by praising sprint results as well as team improvements, ideally in public.
  2. Increase certainty by protecting the sprint from outside disturbances. Make sure the expectations are stable and understood.
  3. Increase autonomy by letting the team take decisions.
  4. Increase relationship by colocating the team members. Select team members by personal interests as well as technical expertise.
  5. Increase fairness by treating yourself and the team members equally.

Keeping those factors in mind can help to better understand peoples reactions and adapt your own behavior so that it minimizes reactions of avoidance.

Team Complexity – The Underestimated Factor

Most people would agree to say that an IT project is complex if it has to cope with difficult technology and a challenging business context.
But it is not just technical complexity that threatens the success of a project. Team complexity is an important and often underestimated factor that highly affects the likelyness of success and failure of IT projects.
Even if you have a simple technical problem to solve, it can get much more complicated if you do it with a complex team.
The main problem is that effective communication is very hard to achieve with complex teams. But effective communication amongst the stakeholders, developers, business and operations is one of the key success factors for IT projects. Thus having a team with low complexity reduces risk and increases efficiency. But why is this often not recognized? I think the reason is that dynamic effects are hard to measure and invisible most of the time.
Inspired by the article Projects fail due to dynamic complexity (German) written by Prof. Dr. des. oec. HSG Stefan Grösser I thought about common factors that affect team complexity and therefore dynamic complexity.
To create more awareness in terms of those factors and make the subject more tangible I’ve created the Team Complexity Calculator. Its a fun tool that can be used to get a better idea of how those typical factors affect team complexity. It does not produce absolute results, so please don’t take it too serious. 😉
If you know additional factors that affect team complexity, please let me know.

Those factors are based on experience I’ve made in projects ranging from small to very large sizes.

How to Link WSDL-Services To BPMN-Processes

Since BPMN2.0 it is not only possible to design processes but to also execute them using a process engine. The process flow has a appropriate visual representation in the standard. But executable processes are mostly data driven. They interact with external services and exchange data with them. In addition to that processes maintain their own internal state. So a common requirement is to model the process internal state and connect to external services using the service data representation. BPMN is capable to include data definitions based on WSDL and XML Schemas, although the capabilities of the tools (that I know) to visualize data are somewhat limited.

In this blogpost I would like to show you how data looks like in BPMN and how a process can be linked in a standardized way to existing services based on WSDL and XSD.

The process is as simple as possible. The service is based on a BiPRO service description. The BiPRO is a standardization organisation in the German insurance market that standardizes processes and services at a technical and business level.


Below you see a simplyfied version in plain BPMN (when you import the bpmn below you will only see the events and tasks).

<?xml version="1.0" encoding="UTF-8"?>
<definitions id="definitions" xmlns=""
  <!-- WSDL Import -->
  <import importType=""
          namespace="" />

   <!-- Item definition. Link to the external WSDL/XSD structure. structureRef: QName of input element -->
   <itemDefinition id="getQuoteRequestItem" structureRef="nachrichten:getQuote" />
   <itemDefinition id="getQuoteResponseItem" structureRef="nachrichten:getQuoteResponse" />

   <!-- Message definitions. Link to the item definition. Can be visualized by using DI -->
   <message id="getQuoteRequestMessage" itemRef="tns:getQuoteRequestItem" />
   <message id="getQuoteResponseMessage" itemRef="tns:getQuoteResponseItem" />

   <!-- Interface definition. implementationRef = QName of WSDL Port Type -->
   <interface name="Komposit Interface" implementationRef="bipro:KompositServicePortType">
      <!-- Operation: implementationRef = QName of WSDL Operation -->
      <operation id="getQuoteOperation" name="getQuote Operation" implementationRef="bipro:getQuote">
         <!-- Links to the message definitions --> 
  <process id="servicecall">
   <!-- Datasources and targets for the service call (process state). Can be visualized by using DI and dataObjectReferences -->
   <dataObject id="dataInputOfProcess" name="Input for webservice" itemSubjectRef="xs:string"/>
   <dataObject id="dataOutputOfProcess" name="Output for webservice" itemSubjectRef="xs:string"/>
   <!-- Process start -->
   <startEvent id="start" />
   <sequenceFlow id="flow1" sourceRef="start" targetRef="initScript" />
   <!-- Initialization of process data -->
   <scriptTask id="initScript" scriptFormat="groovy" name="Initialize process">
       def temp = ""
       execution.setVariable("dataInputOfProcess", temp)
   <sequenceFlow id="flow2" sourceRef="initScript" targetRef="webService" />
   <!-- Web Service call -->
   <serviceTask id="webService" name="Call getQuote" implementation="##WebService" operationRef="tns:getQuoteOperation">
       <!-- Defines the inputs and outputs and links to item definitions -->
          <dataInput itemSubjectRef="tns:getQuoteRequestItem" id="dataInputOfServiceTask" />
          <dataOutput itemSubjectRef="tns:getQuoteResponseItem" id="dataOutputOfServiceTask" />
       <!-- Defines the mapping between process data and service input -->

       <!-- Defines the mapping between process data and service output -->

   <sequenceFlow id="flow3" sourceRef="webService" targetRef="end" />
   <!-- Process end -->
   <endEvent id="end" />

Now let’s look at the example step-by-step.

1. Import the service: Line 16-18 imports the WSDL file that includes the types and messages used by the external service that we want to call from the process.

2. Define the items: Line 21-22 defines items that act as links to the types defined in the imported WSDL and XSD files.

3. Define the messages: Line 25-26 defines messages to be used in the interface definition that we see in the next step. Messages can be visualized by modeling tools provided that DI Information is present in the model.

4. Define the interface: The interface is the equivalent to the WSDL port type in BPMN. It is defined in line 29-36. So far we have itemDefinitions that link to the XSD-messages and an interface that links to the WSDL-port type. The inMessageRef and outMessageRef elements use the messages defined in step 3 to indirectly reference the itemDefinitions.

5. Define the process variables: The process maintains state. This state is defined in the form of dataObjects in line 41-42. Please note that the links to the external service are defined outside the process (which begins in line 38). The dataObjects are defined inside the process as they represent the data that is maintained by the respective process instances. By the way, when importing the process in a modeling tool, dataObjects are not visualized. To visualize dataObjects as a paper sheet, dataObjectReferences can be used. In this simple example we just use a string as input and output which transports a version information send to the BiPRO service and back. In a more complex senario this could be a type from an imported XSD.

6. Initialize the process: A simple BPMN script task (line 50-55) is used to initialize the dataObject dataInputOfProcess. It just sets the version to

7. Link the serviceTask: The most complex part is the serviceTask (line 60-102). The operationRef attribute (line 60) links to the operation which is part of the interface definition (line 31). This is the web service operation to be called when the serviceTask is executed. The serviceTask comprises the elements ioSpecification (line 63-72), dataInputAssociation(line 75-86) and dataOutputAssociation (line 89-100). ioSpecification can be seen as a logical port that describes the service input and output from the perspective of the service. The itemSubjectRef attribute on the dataInput and dataOutput elements (line 64-65) link to the itemDefinitions (line 21-22) and as such to the data structures in the WSDL files. The id together with the inputSet and outputSet (line 66-71) define the connection points the serviceTask offers for sending and receiving data. dataInputAssociation and dataOutputAssociation map the dataObjects (process data) to the connection points or in other words to the request and response structures of the service (service data).

When the serviceTask webService is called, the process data from the dataObject dataInputOfProcess is copied to the web service request message nachrichten:getQuote/BIPROVersion. Then the service is called. After the service call finished, the version is copied from the response message nachrichten:getQuoteResponse/BIPROVersion to the dataObject dataOutputOfProcess.

This blogpost has shown how to link WSDL/XSD based services to BPMN processes in a standardized way.
Even if automated process execution is not in focus, it can be important to unambiguously link services to processes to create an integrated view of the entire process including its data.