Year: 2012

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.

HTML5 Geolocation

Recently I’ve been playing with HTML5 features just to see what it can do in the area of Rich Internet Applications (RIA).

Especially geolocation, local storage and application caching got my attention.
As I don’t think privacy is a concept of the past, I thought it would be a nice use case to track a persons location and store it locally.
So I created a little Location Tracker App to show those features in action.

The required browser features are not supported on all desktop browsers. But due to the fact that most mobile webbrowsers are based on Webkit, it runs on almost any mobile device. (Using a location tracker on a fixed PC seems to be of limited use anyway ;-))

It is amazing to see what you can do with HTML5, Modernizr, KnockoutJS, jQuery and a few lines of JavaScript. For me HTML5 is an interesting option especially for mobile devices.

Collocation Is Vital!

What does collocation mean? The concept is very simple. It means bringing together the people who work on a software product in a physical environment. This seems to be natural. But in highly distributed work environments that we have today it is not anymore.

I’ve been working on agile projects for many years and I always hear that collocation is difficult. Especially in larger enterprises it seems that the hurdles are high. There are many reasons stated by different people.

Here are some examples:

  • There are no adequate rooms available (managers).
  • The buisiness guys don’t understand IT. We can’t work in the same office (developers).
  • The IT guys don’t understand our business. We can’t work close to them (business).
  • Our outsourcing partners are from country xyz. It is impossible to work with them in one office (managers).
  • The business people have their work to do. They simply don’t have the time to work closely with IT (business).
  • I have to concentrate. Working close to others would always disrupt my work (developers).
  • We don’t like travelling. (all of them)

All of those are valid arguments, but to me it seems that they are sometimes artificial. In this case reluctancy to change is stronger than the will to increase efficiency.

From my experience collocation is an underestimated factor that can greatly improve effectiveness of teams. The study Collocation Impact on Team Effectiveness goes in the same direction.

Another interesting read is Collocation, Collocation, Collocation. Quote from the blog:
“A big part of the problem is socio-political in nature and would appear to be deeply embedded in the human DNA. We naturally tend to come to trust those that we have regular contact with (our family / village / tribe / region / country / team) and have an equal and opposite tendency to distrust those on the outside of these habitual daily contact networks (all those that the lock on our front door or the defences around the tribal village are designed to keep out).”

If a company is interested in real agility and effectiveness, I think it should try really hard to create collocated work environments and not give up early. It might somtimes be difficult, but the reward will be better results and most likely even better motivated staff.

Scrum in Reinsurance

On 5. July 2012 I am going to give a presentation introducing an agile Project in the area of reinsurance which I accompanied as Scrum master and solution architect. The conference is going to take place in the SAP Service Center in St. Leon-Rot near Walldorf.
The presentation is called Scrum in reinsurance – a success story. It covers factors that made the project a success as well as impediments. The aim is to share our lessons learned on the way to successful agile project management. I hope to see you there.

Scrum and Silverlight in Reinsurance

Today I would like to share a success story of a project I accompanied as Scrum Coach and Solution Architect from analysis to production.

Main success factors were:

  • Scrum (Agile Development)
  • Cross functional Team
  • Service-oriented Design (SOA)
  • Silverlight RIA

You can read more in the case study Modernization of business partner management.

Lightweight Collaboration Tools

When you work with distributed teams it is important to have lightweight tools for efficient communication. Here are some free tools that I would recommend:

Surveymonkey – Online polls
DFN Scheduler – Scheduling
Skype – Video and voice conferencing
Chatzy – Private web based chatrooms (port 80 only, mobile access)
Trello – Scrum and Kanban boards (highly interactive)
Kunagi – Scrum boards (includes tools like planning poker)
Teamviewer – Online meetings and remote control (free for non commercial use only)

Impediment Number One to Agile Adoption

Scrum is in many respects very different from traditional project management approaches, especially waterfall models. It requires a different mindset in which it is ok to say:

“I don’t know yet exactly how long the project is going take, but give me some time to get to know the requirements and the team. After some Sprints we will give you a solid estimation based on empirical knowledge. Trust us, we do the best we can to deliver quality on time”.

For many especially “classic-minded” project managers such a statement is unimaginable. They simply can’t understand the culture of Scrum as it is very different from what they are used to.
After applying Scrum in several projects over the last years and after giving many Scrum workshops I think that the only way of learning Scrum is by doing it, ideally accompanied by a skilled coach. Books and certifications help, but they do not create deep understanding.
And here begins the dilemma. Especially managers in larger organisations never work on projects, they manage. Therefore it is hard for them to leave their classic mindset. This leads to non-supportive behavior which often blocks the way to agile adoption in large enterprises. In a recent interview Scrum in larger organisations Jeff Sutherland describes the challenges to change the management mindset.

He says:
“… major challenges you will have to deal with when you implement Scrum in a large organization is to change the mindset in the organization in general and on management-level in particular …”

For the reasons given above this nut is hard to crack. To me it seems that this is impediment number one on the way to agile adoption in larger enterprises.

RIA goes to Hollywood

Most RIA technologies today use an asynchronous model to communicate with the server, primarily to keep the UI responsive no matter what the server is doing. This principle is also known as the Hollywood principle. Don’t call us, we call you means that instead of continuously polling, the server calls back when the operation finished. In order to be notified when the server finished its job, callbacks are used.

For instance in Silverlight this leads to code like this

void ClickLoad()
{
    LoadCustomer(1,
    (result) =>
    {
        // Process result
    },
    (error) =>
    {
        // Process error
    });
}

void LoadCustomer(int id, Action<Customer> success, Action<Exception> error)
{
    LoadFromServer("select * from customers where id = " + id,
    (result) =>
    {
        success(result[0] as Customer);
    },
    (exp) =>
    {
         error(exp);
    });
}

void LoadFromServer(string query, Action<List<object>> success, Action<Exception> error)
{
    server.LoadCompleted += (s, e) =>
    {
        if (e.Error != null)
            error(e.Error);
        else
            success(e.Data);
    };

    server.LoadAsync(query);
}

Not very nice, is it? In jquery we find a similar pattern.

$.ajax({
  url: 'ajax/load.html',
  data: "query=1"
  success: function(result) {
    // Process result
  }
  error: function(XMLHttpRequest, textStatus, errorThrown) {
    // Process error
  }
});

Usually an application consists of several layers. In that case the callbacks have to be routed back to the original caller, leading to code that is neither easy to read nor easy to maintain.

From what is already visible, it is very likely that Silverlight and WinRT are going to have great overlap. The combination of XAML, C# and WinRT plus the tooling will be very familiar to all Silverlight users.
That means, it is likely that the asynchronous programming model will be the predominant model for client/server communication for Windows Metro style apps. In order to simplify this, C#5.0 is going to include the await/async keywords, that will make callback chaining obsolete.

Example:


void ClickLoad()
{
    try
    {
        Customer result = await LoadCustomer(1);
        // Process result
    }
    catch(Exception e)
    {
        // Process error
    }
}

async Task<Customer> LoadCustomer(int id)
{
    List<object> result = await LoadFromServer("select * from customers where id = " + id);
    return result[0] as Customer;
}

async Task<List<object>> LoadFromServer(string query)
{
    return await server.LoadAsync(query);
}

This is much cleaner than the examples above. Actually it is a synchronous programming model supporting an asynchronous runtime model. As asynchronous calls are very common in RIA applications the async/await keywords are going to change the way we program async calls in the near future, leading to code that is easier to develop and maintain.

I can’t await async in C# 5.0 😉