Those familiar with military aviation training methods and simulators will be aware of a fact which came to my attention just last week. During a meeting with a major UK supplier of military and civilian hardware and software, their representative reminded me that military pilots, once qualified, are most regularly trained in the tasks which they least regularly carry out.

While a pilot will be operating the undercarriage and trimming elevators or the rudder in every flight, he will hopefully never need to eject from the cockpit. However, should he ever need to, he absolutely must know how to go about it, the procedures that need to be carried out and the controls used to ensure his safe ejection from the cockpit and deployment of his parachute. To ensure that this is the case, he will regularly undergo cockpit ejection training in a simulator environment, but will rarely use a simulator to practise trimming procedures.

Whatever role we find ourselves in, most of us quickly internalize those activities which we regularly carry out. How does this relate to training software engineers?

During the last few years I’ve been disappointed to learn of the number of educational establishments which will teach many of the topics we’ve discussed only through a lecture format. Whilst I appreciate that projects are time-consuming to plan and run, my experience tells me that a student who is encouraged to use the techniques they learn in the context of a team project, will not only gain a better understanding of how a project is run and the project management techniques they’ve learned, but also will be more likely remember the likes of UML and SSADM.

Application of taught skills is, in my view, essential to the full learning and further development of those skills, and also gives the opportunity for students to experience them in something closer to a real world environment, rather than just in the sterility of the lecture hall.

The five key challenges I examined were:

• Keeping business processes and the solutions that support them closely aligned
• Maintaining investment in intellectual property within, or accessible to, the organization
• Understanding the hand-over points between client and supplier organizations
• Preserving interoperability of long-lived IT system assets
• Minimizing client risk through adherence to standards for development practices

Of course, these challenges are in addition to the risks that are associated with the management of outsourced activities themselves.

In times where standards-based process improvement is de rigueur, seen in the continued push towards CMMI levels 4 & 5, it seems strange to me that so often these activities don’t include the use of standards-based analysis & design methods. Even stranger is that the software assets which are being developed offshore are so rarely subject to formal asset management techniques which can help to not only control the assets, but also to widen their use within a component- or service-based approach.

Of course we are all pretty familiar with the now standard model of outsourcing, or off-shoring software development. There are numerous destinations for this, Eastern Europe and India being most common, butalso far eastern countries like China and the Philippines.

Also, we are pretty familiar with outsourcing departments, like Customer Services and Back Office.

But what about outsourcing Business Processes ?

Well I suppose it’s a pretty natural progression – as we have pushed IT Systems up the abstraction hierarchy, from systems development and service oriented architecture towards business process orchestration, it then seems natural at the business level to consider outsourcing the business processes themselves.

But, how well do we understand our business processes? Well enough to be able to express to an outsourcing company what you want them to do for you? Techniques like BPMN look to me to be a natural fit for this – a rich enough notation so you can express your overall business processes and then consider for portions of your business whether they need to be local or can be offshore.

And then, the strap line – “Utilising sourcing as part of your business strategy” – in BMM (Business Motivation Modeling) terms, this is a Means to achieving your business Ends. I think it would be really valuable for anyone considering ‘Sourcing’ to model their business strategy using BMM and then look to use BPMN to model their business processes. Having a well defined strategy and business process model will help guarantee successful outsourcing.

It’s a topic which has had much coverage in the last year, following the publication of a research paper on BPMN usage by Michael zur Muehlen and Jan Recker. The paper analysed over 120 examples of BPMN diagrams from a number of sources, to identify the most commonly used BPMN elements, and its findings certainly back-up the experiences of our consultants with a range of users of Select Architect. Further blogged debate by Bruce Silver and Sandy Kemsley, appears to have reached a broad consensus.

Because Select Architect supports an older, simpler notation for workflow modelling, the Process Thread Diagram, in addition to BPMN, we’re often asked which should be used. In general we find that the two notations are used by different groups of user, broadly similar to the groups identified in the paper by zur Muehlen and Recker.

Those who are interested in modeling business processes in order to understand organizational boundaries and responsibilities, or as part of a process improvement exercise, seem to prefer a simpler notation, which they often perceive cannot be achieved with BPMN. They see the multitude of options available on BPMN events (a start event has six trigger types – including undefined, intermediate has nine, end has eight result types) and on tasks themselves (nine task types in Select Architect) and decide, instead, to use the process thread notation which is not universally standardised.

BPMN event trigger and result types

The other group of business process modelers are the analysts who want to precisely model the conditions of the workflow, for whom the range of gateway and event types is essential.

You could say that Select has been implicit in propagating this split in BPM notations; the pragmatic reality is, however, that while we have customers who want to use the process thread diagram rather than BPMN diagram, it would be unwise to force adoption of BPMN.

Rather, I would like to see all of us involved with business process modeling promoting BPMN as a technique which may be adopted by both groups, using the level of detail required for their purposes.

Let modeling with BPMN be seen as an iterative process. Why shouldn’t the process analysts use a validated subset of BPMN to construct ’simpler’ diagrams where the events can be simply start, intermediate and end events. They have no need to worry about the detailed trigger types, and should not feel pressured to do so. Similarly for simple decision points, they need not even use gateways, let alone worry about the gateway type or detail, instead using conditional flows. If the project requires more detailed modeling, those details can be applied as the processes are further analysed and decomposed.

Perhaps we, and other BPMN vendors, should consider BPMN profiles, based on the role of the user, which provide cut-down toolbars of elements and property details?