Keith Swenson’s article on the fallacy of flexibility makes a good case for lean software development and the Lean Startup:

This article is about software design, and makes the case that flexibility for flexibility sake should never be your goal.  There is a very delicate balance between design and implementation in order to provide both usability and capability when it comes to software.  Flexibility is often held up as a axiom, but flexibility should be provided only to the extend that it is actually needed by the end user.

I’d put it slightly different: flexibility should be provided to the extent that it is either less work, or actually providing value to the end user.  In that order.  If the absence of doing something yields flexibility, that’s good.  But if you design your software to solve hypothetical situations that have yet to manifest, you run a real risk of overdesign (and over-engineering).

Keith goes on to document a set of rules to keep software simple and maintainable, including removing outdated functionality.  You could sum these up as minimizing technical debt (or in BPM, process debt). The less debt you incur, the more maintainable (and less costly) your code base will be going forward.  The more debt you retire, the better, generally speaking (but, there are trade-offs to retiring debt).

The key insight:

What I am trying to say here is that our normal intuition about the value of designing up front is wrong most of the time when it comes to software because it is not like a physical production process.

So true.  Great read, I recommend anyone technical read the whole article.  If you’re not technical, you might want to read it anyway – it will give you insight into how much the flexibility ideas of your technical staff are costing you.

Anyone involved in Enterprise software or hardware companies should read this article from TechCrunch.  It has a few key insights, that mirror what I’ve been observing, but put it into words much better than I could have:

20 years ago, the technology adoption curve generally conformed to the following order:

1. Government, specifically Defense and Intelligence organizations.
2. Businesses, with large businesses going first and smaller businesses adopting later.
3. Consumers

Today things have completely reversed. The latest technology goes to consumers first, followed by small enterprises that behave like consumers, then larger ones, then the military. The stunning reversal is one of many profound side effects of broad scale Internet adoption.

The reversal in the cycle has really interesting ramifications for businesses who sell to other businesses… But this shift is going to take a lot longer to change Fortune-500 buying cycles than people anticipate…

If you don’t know much about Signal events in BPMN2, read Anatoly’s blog post on the subject:

In order to make the diagram work we must limit the signal propagation somehow. How it can be done?

1. The first thing that comes into my mind is an attribute that would limit signal broadcasting by the current process instance boundaries. Yet there is no such attribute in the standard. Under BPMN 1.x one may say that it’s implementation issue not covered by the standard. But BPMN 2.0 fully specify the process metamodel. Let’s look at page 281 of OMG document dated June 2010: signal has a single attribute – its name. Therefore, a signal will be transmitted to all process instances.
2. If the signal has only name then let’s use what we have. The diagram above may work if we could change signal name dynamically i.e. during the process execution. If we could name the signal “Process 999 Concept Ready” instead of “Concept Ready” then everything will be fine. But it’s a dirty hack and it’s hard to count on it. BPMS engines allow to change certain things during the execution (e.g. timer settings) but unlikely the name.

As Anatoly points out, the signaling examples given in several highly regarded books are fine, but when you think about how to make them work for the n>1 case, the logic breaks down.

It turns out that Lombardi’s BPM product (Now IBM’s Websphere Lombardi Edition) does not distinguish between Message flow and Signal events (the distinction between the two has only artificial merit).  All events include an information payload (which can be arbitrarily simple or complex).  The receivers control what they listen to by identifying a correlation key.  The correlation key has to be something in the information payload, and as you can imagine, often one element of the payload is specifically designed to be the correlation key for listeners.

So sometimes implementations get the design right in a way that the spec-writers don’t – because of what I would call over-design.  Let’s face it, writing specifications like BPMN2 goes against the principle of lean development (producing the minimum viable set of features).

So I find it interesting to see some of the challenges Anatoly has faced by facing in some cases a more pure representation of the BPMN 2 specification.

Bruce Silver reminds us that he has helped IBM to produce free training videos for Blueworks Live:

With the recent launch of Blueworks Live, IBM has posted an updated version of a set of training videos called Process Mapping 101.  Together with colleague Shelley Sweet of I4 Process, I created the original set for Lombardi back in 2008 , and the new version updates it to Blueworks Live.

There is a registration form to get started, but not a bad price for 2 hours of content!