If Agile Software Is A Cop-Out; Is BPM the Next Studio for Software Development?

Continuing my comments on Mike Gualtieri’s post on the state of software development (which seems to have hit on a real issue, based on the number and quanitity of comments it generated), Mike states that there are 4 pillars needed for a methodology for creating a new paradigm for software development:

  • Parallel. Development teams must have the confidence and insight to do parallel streams of development.
  • Immersive. Software is a means to an end. That end is to deliver applications that exhibit the seven qualities of great software: user experience, availability, performance, scalability, adaptability, security, and economy.
  • Software. That’s what we develop. That’s what we deliver. However, the future software development is experience.
  • Studio. Software development is not pure coding, engineering, architecture, management, or design. It is cross-disciplinary. Better yet, it is its own discipline.

These are all good, important points but they ignore the business perspective! I have been a user experience advocate forever – since being the user experience advocate for IBM Research in the late 90s. User experience is a critical perspective for developers to understand, and critical for the success of any software. But I have learned it isn’t enough – software development needs to take into account two more critical business aspects:

  • Business Value. Software must deliver business value, and that isn’t always completely aligned with user experience or any of the immersive points Mike lists. A application can have a great user experience but bring no value to the business, which means it will either be killed or die from lack of attention. In most cases business value needs to come first, and foremost.
  • Platform. Software (even what ends up as applications software) is either a platform itself, or built on (and used to enrich) a platform. This is both a business and technical decision, and can greatly affect the long term success of any software. See a great rant on the subject here.

So how do BPM platforms stack up as supporting the pillars of software development?  Theoretically they stack up pretty well.

  • Parallel – the modeling process is a bottleneck, but once completed things can be implemented in parallel
  • Immersive – the BPM and its model driven development platform should make it much easier to obtain the immersive aspects too.
  • Software – most BPM platforms put no focus on user experience. I have written about this before, but it a real failing of most BPM suites.
  • Studio – certainly BPM suites are built to support multi-disciplinary teams (though with great differences in the level of support for different audiences)
  • Business value – BPM suites should get high ratings here – since the theory is that the is driven by “the business”
  • Platform – A BPMS is by definition a platform, and theoretically every application built on the BPMS could enhance it

The problem is the distance between theory and practice. Most BPM suites try too hard to make themselves of value to the business side, and miss a lot of what is needed on the high-end development side. I really don’t know of any BPM suite that focuses solely on developers and their needs, or positions itself as a better development environment for business applications. BPM suites are sort of a camel, while developers are looking for a better horse. So BPM suites could be part of the answer for the problems in software development, but in practice they aren’t.


5 Responses to “If Agile Software Is A Cop-Out; Is BPM the Next Studio for Software Development?”

  1. John Reynolds Says:

    Good observations Jacob, as always.

    I agree that BPM suites generally “miss a lot of what is needed on the high-end development side”… but in my experience I mostly see the converse… BPM suites also miss a lot of what’s needed on the business side. Simple things like “follow the sun” task assignments, dealing with vacations, sick days, etc. usually require bringing in a “real” developer, when it’s obvious those are things business users certainly could specify.

    So we’ve got to build out in both directions – business and dev – without creating Frankenstein Swiss Army Knife abominations.

    • Jacob Ukelson Says:

      I agree. What surprises me most is that BPM suites are just not considered at all by developers for mainstream development tasks. They are far from perfect, but I think vendors (and analysts) focus on BPM as a tool for the business has led away from the need to make BPM a much better tool for the programmer.

  2. BPM Quotes of the week « Adam Deane Says:

    […] BPM Suites – Jacob Ukelson Most BPM suites try too hard to make themselves of value to the business […]

  3. kswenson Says:

    I didn’t buy Gualtieri’s argument in the first place. Consider this quote:

    “Development teams must have the confidence and insight to do parallel streams of development.”

    This assumes, at the very beginning, that software problems are separable and reducible. In many software products they are not, and that is precisely where traditional waterfall model development falls into trouble, and “parallel” will as well.

    Anyway, it appears that Gualtieri has found an audience in backlash to Agile. We will see how far it carries him.

  4. Ukelson: Is BPM the Next Studio for Software Development? » Process for the Enterprise Says:

    […] Ukelson has a fantastic critique of Agile Software – he lists the 4 pillars of Agile, but then points out: These are all good, important points […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: