Austin’s economy has already been demonstrating a fair amount of resiliency in the last couple of years.  This week there’s been a flurry of good news for startups and entrepreneurs here.

First there’s the article from Bijoy Goswami in the Austin Business Journal, “Time has come for Austin’s entrepreneurs to make a scene.”  The ABJ has become primary source of business news for Austin business owners.  The article announces the launch of a news portal for Austin Entrepreneurs – www.abjentrepreneur.com.

Two of the first three articles:

Dachis buys third firm in 3 weeks

and

SolarBridge collects $15M in VC

Not sure how much overlap there will be with the kind of coverage we see on Austin Startup, which also focuses on entrepreneurs and startups in Austin, but it more of a blogging format.

Jim Sinur coined the phrase, and because it has a ring to it, people have picked up on it (perhaps behind Jim’s intent):

• Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests.  It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it.  This works if the process is predictable.
• Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time.  Since you can not predict it, you have to elaborate it as you go along.  You design it, as you are doing it.  There is no development life-cycle.  This works on unpredictable emergent process.

Keith Swenson thinks Design by Doing is advocating ACM:

Instead, a clear term is needed for “design by doing” and that is Case Management — particularly a newly enable technical approach known as Adaptive Case Management.  By having a clear label for “design by doing”, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.

I don’t know, why not just call it “design by doing” and use that as the tag-line for your product offering… ACM doesn’t quite have the same ring to it, and it isn’t nearly as easy to relate to.  Trying to convert a useful phrase into a three-letter acronym is, of course, the purview of techies and software firms.

Max J Pucher comments in Keith’s blog:

[..] So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners. [..]

Actually, I think the simplest explanation for the sudden desire to coin a new phrase, by firms previously happy to be labeled BPM, is this:  a bunch of companies have already acquired one or two BPM software vendors.  How many more BPM software companies do we expect Oracle, IBM, SAP, Software AG, and SAP to buy?  Would you rather be the “XYZ” software company that is more clearly defined as a complement to the BPM companies these firms already purchased, rather than a BPM company that has significant product overlap?  Of course!  (well, as Max says, he doesn’t care about the labels for his product, Papyrus, so I don’t mean to personalize this to Max, by any means!).  And if you’re a big established company, now is the time to find your opportunity to differentiate from IBM and Oracle – RPM from Progress, ACM from Fujitsu (and a few smaller vendors).

I even think this effort to differentiate the three letter acronyms is logical from the perspective of these firms, and in the self-interest of these firms.  But like some others (Anatoly for example), I’d like to keep BPM separate from BPMS (method from technology).  There are other folks who are just tired of chasing the latest 3 letter acronym and think the exercise doesn’t benefit customers or practitioners.   I see managing unpredictable work as still being “process-driven” even if others don’t.  Design-by-Doing sure sounds like a process to me, folks.  Maybe a meta-process, but a process nonetheless.

I’d like to see the ACM crowd turn their attention to explaining how they make the design-by-doing approach easier through their software offerings – explain why your software is just the right socket wrench for the job, rather than a screwdriver.  Educate the market on why the software fits the problem definition.  As a practitioner, I want to understand whether your software improves the odds of my customers achieving good results.

Regardless, it sure has made for a lot of good reading lately on BPM blogs.

IBM’s Lombardi team recently posted an updated schedule for Lombardi Day and Lombardi sessions that will be happening later in the week.  We’re still on for a 3:45 session on Monday discussing what we learned from bpmCamp 2010.

I’m always on the lookout for the intersection of startups and process.  And recently Mark Suster put together yet another great post, this one about how to put your technical team together for your startup.  And specifically, the difference between your CTO and VP of Engineering.  He also has this fantastic graphic:

Engineering Team

To quote Mark:

“…In my view it is important to distinguish the difference between the CTO and the “VP Engineering.”  Because these titles are so often used I’m sure that some people will have hardened views about what they mean that are different than mine.  But for non-technical founders let me offer you a definition that you can use when you build a team.  The VP of Engineering is the person who still has great technical chops but prefers not to be a coding monkey (that term is meant in the most endearing of ways).

The VP Engineering aspires to manage teams.  They feel comfortable with C++ but also have a black-belt in Excel.  They are sticklers about managing unit tests, system tests and regression tests. In fact, they are passionate about automating testing overall.  They know how to estimate work units, how to manage the agile development process and how to get the most out of their teams.  VP’s of Engineering are essential to making sure the trains run on time.  The VP of Engineering is also your primary interface to your head of product management and often the VP of Engineering is somebody you would drag in front of clients to win big deals.

And first and foremost a VP of Engineering is a people manager….”

As Mark puts it, the CTO is your purist, a hardcore technical visionary and perfectionist.  Your VP of Engineering is about process, and values scaling the organization and having repeatable systems and processes.

This hit the news this morning, that Apple acquired Siri.  We had the opportunity to see Siri compete in the startup accelerator competition at SXSW-interactive this year. Even at that time I was thinking how much better something like Siri would be if it was able to take advantage of a “service registry” or API registry within the iPhone App community – much like apps in Mac OSX can take advantage of the service registry there.  So an application could register to provide “table reservations” and Siri could farm out reservation requests to such applications (currently, it does this only with OpenTable). And integration to core applications within the iPhone would greatly improve the service (emails, calendar, etc).

So its a logical fit, and a good outcome for the Siri team.  But more than that, the Business Insider believes it is a shot across the bow at Google- because it may be what Search looks like on mobile devices.  Where it is less about “search” and more about “search as a preface to action”. I think this is a great point, and a fantastic move by Apple.  I can definitely imagine them taking advantage of Siri functionality to make the Apps we already buy more useful on our phones.  And hopefully the Siri application itself will improve (more stable, better voice recognition, etc.).

Business Insider’s original article here.

Adam Deane noticed a change in Gartner’s BPMS Definition:

If you compare it to previous BPMS definitions by Gartner (for example in last year’s Magic Quadrant for Business Process Management Suites), you will see two major additions:
1. Document and content management.
2. Inline and offline simulation (instead of just simulation)

Good catch.  Of course, we shouldn’t be surprised that the definition of “what’s in the BPMS box” would change over time – I expect that soon it will be a given that several other features (even products, or market segments) should be included in the BPMS definition.  Why? Because too many people view BPM (or BPMS) as the the future “Business Operating System” (in the 90′s, I think most people viewed ERP as the operating system for the business… ).  Rightly or wrongly, that puts a lot of things under the umbrella.

The real progress will be when the technology becomes so good it is transparent to the business, so obvious it is as if it works by magic (see Arthur C Clarke: “Any sufficiently advanced technology is indistinguishable from magic.”).

Every so often, a conversation builds to critical mass and demands an in-person meet-up.  Eric Ries pulled this show together, and I have to say there is some great video, and there were some great presentations to browse to get to understand better what you can do with a lean-startup approach.

Steve Blank has one of the best overviews with links to all the important content.  And here’s a link to the stream of his talk.  You can find almost all of the presentations on slideshare with the sllconf tag.

Maybe I relate to this conference effort because we put on the bpmCamp unconference earlier this year.  Mainly, I applaud the effort to build momentum and credibility around some really great frameworks.

Theo Priestley warns against creating a new role for “organizational actors” to assist with process improvement projects:

Secondly, as highlighted above, we do not need to invent a new role or label to fulfil this kind of role-play, or indeed formalise it in any way. We were loosely composed of analysts, heads of depts, customer service reps; people who understood the process at all levels and we all understood what the purpose and goal of what we were doing. This should not be the responsibility of one particular person or a set of people but just another piece of the continuous improvement mindset which exists already.

What Theo is arguing is that to do process improvement and BPM correctly, we have to involve the business (and IT) in the effort.  Rather than further specializing roles, most organizations would likely benefit from the cross-pollination and change in the routine.  I’ve always suspected that BPM projects depend more on EQ than IQ: selecting the right people for the project is more of a judgment call, and the people who will be most effective are those with a high EQ.

Businesses will be better off  investing in the people already in the organization by giving them broadening experiences and responsibilities, that they’ll take with them back to their day job.  At the very least they’ll have a new appreciation for a broader swath of the business.

Alain Breillatt argues that you can’t innovate like Apple for many reasons.  His article is really a fascinating read for what it reveals about Apple’s design and product development process, regardless of what you think of his conclusion.

But as with any piece that makes a bold statement, there are bound to be pieces where the author misses an underlying truth in pursuit of making the point that is the thesis of the article.

The part of the article that caught my attention:

10 to 3 to 1. Take the pixel-perfect approach and pile on top of it the requirement that Apple designers expect to design 10 different mockups of any new feature under consideration. And these are not just crappy mockups; they all represent different, but really good, implementations that are faithful to the product specifications.
Then, by using specified criteria, they narrow these 10 ideas down to three options, which the team spends months further developing…until they finally narrow down to the one final concept that truly represents their best work for production.

This approach is intended to offer enormous latitude for creativity that breaks past restrictions. But it also means they inherently plan to throw away 90% of the work they do. I don’t know many organizations for which this would be an acceptable ratio. Your CFO would probably declare, “All I see is money going down the drain.” This is a major reason why I say you can’t innovate like Apple.

Well, first of all, the math is wrong.  If they brought 10 concepts all the way to final production-ready version, and threw away 9, that would be 90% “thrown away”.  But actually they’re abandoning 7 ideas at an earlier stage, and 2 more at a late stage for production.  So the percentage thrown away is something less than 90%.

Second, what struck me most is that Apple’s design process doesn’t consider these throw-away prototypes as waste – it considers these prototypes as a valuable part of the creative process – and that the TRUE waste is producing less than the best product design.  Or worse, producing multiple products that are inadequate.  Imagine if Apple had released 4 iPhones instead of 1 in the first run.  That would have been the real waste – because each of those products would require significant production costs, engineering costs, support costs, and marketing costs on into the future. So Apple is making a trade-off of design-cost against production-waste, from this point of view…

Next, Alain describes Apple’s strategy as high-risk:

4. Apple focuses on a select group of products. Apple acts like a small boutique and develops beautiful, artistic products in a manner that makes it very difficult to scale up to broad and extensive product lines. Part of this is due to the level of attention to detail provided by their small teams of designers and engineers. To think that a multi-billion dollar company only has 30 major products is astounding, because their neighbors at that level of revenues have thousands of products in hundreds of different SKUs.

As Jobs explains, this is the focus that enables them to bring such an extensive level of attention to excellence. But it is also an inherently risky enterprise, because they are limited in what new product areas they can invest in if one fails.

Again, I see how having a “narrow” product line can look like it increases risk.  But the advantage that Apple gets (and which I’ve pointed out previously), is that Apple can put all of their R&D effort behind a smaller number of products at volume, rather than splintering the focus with a great number of different products.  The greater risk to Apple’s business would be producing a broad array of inferior products.  The risk that Alain is focused on is the risk that Apple produces, for example, only one phone, and if the next version is a “dud” then the risk comes home to roost.  But this risk is over-stated:

1. Apple’s product update lifecycle is typically about 1 year. So if a design is a dud, it usually won’t hurt them in that product category for more than 1 year, and they can learn from that failure for the next version.
2. Apple provides a lot of product updates that aren’t risky – color options, storage/memory upgrades, speed improvements, software updates.
3. Apple only provides “choice” when there is demand volume to justify the extra cost.

Moreover, one could argue that for a given market-share, Apple can benefit from efficient R&D expense (yielding higher margins).  And if Apple is successful in delivering a premium design, then they benefit a second time from premium pricing.

Of course, Alain makes many points in his article that were new insights to me, and more that I completely agree with, so it is a little unfair to just pick on a couple of things that I think his post missed.  It’s a great read and highly recommended.  But, my cautionary note: when thinking about cost, think about the cost of the Apple path, sure. But then, think about the real costs of the other path as well.  Which one is really more expensive?  Riskier?  And what is the expected return for each path (Risk*Reward – Cost)?

Update 5/24/2010: Clearly, Apple’s own R&D and growth trajectory show that its approach is actually more efficient, less expensive.  Alain argues that it is more expensive, but the data shows otherwise.  Take this article from Silicon Alley Insider as an example:

Turns out, Apple’s run of incredible products (and growth) has been achieved with a staggeringly low R&D spend. How low? Apple only spent $4.6 billion on R&D over the past four years, while revenues soared from $25 billion to $43 billion.

Meanwhile, Microsoft spent 700% more, and acquired 45 companies.  And achieved much more modest growth.  It is pretty compelling data.

One of the most anticipated sessions at bpmCamp was a discussion on off-shoring.  It had one of the highest turnouts of day 1. There were some interesting observations from the discussion :

1. Everyone agreed that daily communication across multiple mediums was a must: phone, email, instant messaging, screen sharing.
2. Structure helps: Daily SCRUM sessions, for example.
3. Bringing offshore folks onshore for a while helps – consensus is that this is more important than the reverse, though both are good.
4. Despite having productive off-site working relationships within the US, several participants reported a drop-off in productivity when going off-shore – despite no obvious logistical/infrastructure difference besides timezone.
5. Integration and collaboration among the teams is vastly more important than documentation and specifications.  The trend toward increasingly exact specifications to manage off-shore resources mirrors what happened with software development methodology in the US many years ago – with increasing gateways and overhead, and slowing velocity and innovation. (This led to a waterfall backlash, and the popularity of Agile software methods)
6. There’s a lot of potential in the follow-the-sun model, and in cost-savings.  But the challenges to productivity are real.

My own advice: when off-shoring, work with firms that do BPM deployments locally, for local market customers.  The adjustments they have to make to do a remote-BPM project are less-severe than the adjustments technical staff have to make from traditional IT projects to BPM projects.

Theo Priestley once again has me thinking with this post asking “Is This the End of BPM Centre of Excellence?“:

There are two trains of thought at play. In recent interviews on Redux, Vinay Mummigati of Virtusa said “A BPM center of excellence (COE) is an absolute must for organizations planning to adopt BPM across the enterprise. As companies adopt BPM in more than a single department they often start seeing challenges in terms of standardization, scalability, performance and governance.”

And yet there was a completely different perspective taken by Max J Pucher of ISIS Papyrus who stated “…if there is one thing that Social BPM could knock down, it is the Process Center of Excellence and the related bureaucracy overhead!“

Ever a pragmatist, I would suggest that inside any firm that can adopt “social” media techniques, the Center of Excellence has to adapt its traditional role.  Instead of being primarily a governance and gatekeeping organizations, the mission should be re-defined as:

• Providing expert resources for BPM initiatives to draw on – no matter how much participation and spread of BPM skills, there will always be process improvement specialists who have more knowledge and context than the average participant.
• Providing social infrastructure for collaboration – wikis, BPM collaboration platforms, Sharepoint sites, email lists-  whatever is most appropriate for the organization. Lower the barrier to entry for collaboration among your BPM practitioners, users, and participants.
• Encouraging and Curating the content generated from “Social” BPM and collaborative activities.  Knowledge workers need positive reinforcement for their participation in social BPM, and with the greater volume of content the CoE’s role will shift to be more editorial rather than primary authorship.
• Breaking down barriers to communication and collaboration, rather than creating new chains of command and approval.

It isn’t that there isn’t a need for experts-  there is!  But the role of those experts changes from manager-governor to coach-collaborator.  Of course, being an outside consultant, this isn’t a stretch for us to see the writing on the wall -because this is the role we already play for our customers.

We had a session on User Interfaces built on top of Teamworks at bpmCamp.  It was an interesting, technically detailed discussion – but what I took away from it were some key questions for process authors or process application developers:

1. When should one deviate from the “stock UI builder” included in a BPMS?  Teamworks ships with a great out of the box prototyping UI builder.  It let’s you build simple interfaces extremely quickly (integrated with process data), but has some limitations when it comes to more customized look-and-feel.  But when is a departure from the standard UI worth it?
2. Once one decides to roll a custom interface, which frameworks have the most currency?  There were people present that had worked with ExtJS and Flex, or just used Ajax to customize the Teamworks user interfaces.
3. Why can’t access to process work be more universal?  There was a lot of discussion about the process portal, but why aren’t tasks and updates available via twitter, RSS, SMS, SalesForce, and email among other things?
4. There was general consensus that the reporting framework should be more “open” out of the box- providing useful data for charting in a simple XML format, along with optional detailed information in an XML format, in order to make it easier to support alternate visualizations.  This approach would make it much easier to plug in different charting tools.  (Note: to that end, bp3 has built a reporting framework that supports Google Visualization (and soon Fusion charts).
5. There was a lot of interest in using the newer REST api’s for Teamworks.

I think the key take-away for me is that BPM practitioners want it to be easier to publish process information to whatever platforms their users want to receive them.  BPM information still needs to be further democratized.

The second take-away, related to the first, is that “portals” have gotten a lot less interesting.  In some environments, a portal is needed for a specific process- and only for that process.  In other environments, a portal needs to support multiple processes in one unified interface.  There’s no one right answer – as evidenced by divergent opinions at bpmCamp.  BPMS vendors either need to re-imagine the concept of the process portal, or they need to open their platforms for more innovation by embracing social media.

Adaptive, Dynamic, Social: Can These Three Emerging BPM Concepts Become Unified ?

I sure hope so!  In fact, I can’t see any other reasonable outcome.

It looks like IBM is taking registration for Lombardi Day at Impact:

Every year we run the Lombardi Customer Conference – called Driven. Whether online or in person, Driven is always a great opportunity to get caught up on the latest from Lombardi and to hear about how your fellow practitioners are succeeding with BPM. This year, as a part of the IBM family, we have the opportunity to combine our Lombardi sessions with the broader IBM Impact conference in Las Vegas, May 2-7. Lombardi Day will be a day limited to Lombardi customers and similar in nature to Driven conferences of years past. In addition to Lombardi Day, this year you will have the opportunity to attend Impact.

If you are a Lombardi customer or partner, Lombardi Day is probably a good opportunity to get plugged into what’s in store now that Lombardi is part of IBM.  I registered separately for Lombardi Day, but I’ll also be speaking at the event on “What we Learned at bpmCamp”.

There’s also a pretty decent brochure for the agenda.

We had two somewhat related sessions at bpmCamp – one in which Flournoy Henry presented findings and data for scaling Teamworks, and another discussion with Dave Knapp engaging the group in a discussion about testing in Teamworks. Of course, many of these points were not specific to Teamworks.

Some of the key points from the testing session:

There was a general consensus that too much attention is given to “User Acceptance Testing” as a phase at the end of a major project, rather than engaging in continuous user acceptance testing.  At the very least, incorporating user acceptance testing with portions of the solution at each iteration is critical.

Being near the top of a pyramid of integrations and business system dependencies, a major challenge is testing process applications with all the external services required to make the process work. It isn’t just the fact that there is a dependency – one needs consistent test data across several systems to make for realistic testing prior to going to production.  There’s also a complexity in promoting process applications – to get all the directly BPM-related assets promoted in concert with any updates required in dependent systems.

There was also discussion around fail-over and roll-back testing.  It reminds me of the old adage for backup systems:  don’t tell me how often you back-up your systems, tell me how often you’ve done a full restore from backup.  Switching successfully requires practice in order to have it go smoothly.  But practicing has cost and risk as well.  This is part of why cloud computing is so compelling: High Availability software deployments are expensive when you want to do them right.

Neil Ward-Dutton has a great post about BPM vendor results that moves into a discussion of process improvement approaches:

The distinction between “old school” and “new wave” process improvement approaches (I’ve called these “high church” and “low church” before) is just continuing to get stronger. 10 years ago, the vast bulk of process improvement activity used to be driven by the “high church” crowd: lots of ceremony, burning of incense, and so on. Scientific improvement efforts driven by highly-qualified specialists are essential in situations where there’s a lot at stake (for example when you’re reengineering an auto manufacturing line: get it wrong and it’s going to cost you a lot to put it right). And don’t get me wrong: there’s definitely a place for this.

This description and the ensuing thoughts reminded me of our early experiences with BPM at Lombardi.  Lance and I (and others at Lombardi) were often running into process improvement experts with a grounding in Six Sigma or Lean (or less often, IDS Scheer, or Enterprise Architecture modeling).  We were sometimes supported by these folks, and sometimes they resisted our approach (and “BPM” in general).  On the whole, there was a lot of resistance, as our approach to process improvement was somewhat heretical.

So Lance (now CEO of BP3), embarked on a journey to get behind the curtain, to understand the vestments of the Six Sigma and process improvement community so that we could better work with these folks.  After going through the first rounds of training at the Green Belt level, he started to get others of us to go through the training as well.  And what we found was that you didn’t have to adopt the religion of Six Sigma to get the value.  The statistical tools are just that :  great tools you can use.  The “high church” trappings are wholly unnecessary but they do create an aura of authority for those who exercise them.  Lance went on to become a certified Master Black Belt, but we continued to apply what we learned from Six Sigma in an eminently practical way.  The point isn’t to be “pure” – the point is to get to value faster.  If statistics can do that for your business, then you use them.  In our mind, if a BPMS can do that for your business, then you use it.  Make the best of the tools at your disposal to get the maximum benefit.

Still, there are those whose self-interest is aligned with keeping the “high church” ceremonies and orthodoxy firmly in place.  The challenge is to keep it in perspective – scientific approaches can inform the “new wave” way of thinking without slowing things down.

One of the ironies now is that some of the newer entrants to the Business Process space now see BPM as the high church (old school) and their own approach as the new wave.

While Apple’s customer service could use a minor overhaul, the process ninja points out that it is still worlds better than the telcos customer service:

A Tale of Two Processes – Apple vs. Optus:

So I have the choice – dig through 2 years of paperwork and slog back to Optus to deal with the surly girl at the phone shop with no usable iPhones, or I can go to the apple store and they will simply replace it. I choose Apple, and whilst I’m there I may play with all their working products, maybe buy some accessories; using up all that time I would have wasted digging through paperwork…

But wait, isn’t Apple’s customer service top notch?  It is pretty good, especially when compared with other choices in the computer ecosystem.  Surprisingly, however, it doesn’t live up to the customer service I get from luxury car dealers.  When you take Apple out of the context of the computer business and compare to other high-end brands, there are some obvious improvements they could make.  What would I do to improve Apple’s customer service (rather than just complain about it)?

1. Loaner machines for people who have to ship their laptop for repair.  Car dealers do this “gratis” if you buy a luxury car.  Of course, the price of the loaner is baked into your $50 oil change.  Apple could do the same – or they could charge a flat rate ($100?) for a loaner.  $100 for 11 days of up-time isn’t too bad, considering the local Apple authorized repair shop charges $300+ for the same time-frame.  Alternately, offer it for free to people with Apple Care plans, and raise the average price of those plans a small amount to cover the difference.
2. Consider separating education sessions and wait-times from repair/replace wait-times.
3. Surprise and delight. Take a page from Zappos’ book – sometimes when someone comes into the Apple store out of warranty or without an Apple Care policy, go ahead and take care of them without charging, and tell them that that kind of service would be covered with the warranty if they want to have future repairs covered.  It is a great way to build brand loyalty.
4. On-site service.  Take a look at Dell’s servicing model – they’ll come to your office to fix your laptop if you buy the premium service plan.  Apple should consider adding this option to their service offering.

I’m sure other people have ideas about how Apple could improve their customer service – let’s hear ‘em.

Ben Horowitz writes in “Four Things Some VCs Do That I Don’t Like” one thing in particular which really resonated with me:

VCs often confuse marginal social courage with real courage. For example, they think CEOs who fire people easily are tough. I’ve fired dozens of people and laid off hundreds. None of them was easy—not a single time. Having an easy time firing your loyal employees indicates a lack of courage and a lack of leadership. More specifically, it indicates a lack of willingness to really understand the negative consequences of those actions. If you fire people easily, you likely lack the toughness to look in the mirror.

(My emphasis on the last sentence).

This statement gives me great insight into the character of Mr. Horowitz.  Because firing people *is* hard.  And when you have to do it (for performance or for financial reasons), you do it with heavy heart.  As he says, courage isn’t doing things easily.  Courage is doing the hard things even though they’re hard, if they have to be done.

Theo Priestly: Is the BPMS mightier than the COTS (Commercial Off-The-Shelf software)?

With the advent of similar suites such as Bonitasoft, Outsystems and Iceberg that allow organisations to build business process based applications directly, and others that offer the same web-based style workflow creation, could these BPMS tools eventually replace the more expensive COTS (Commercially Off The Shelf) software alternatives as they mature ?

Theo asks if this is Build or Buy – but I’ve seen many firms look at this as “Build vs. BPM+Build vs. Buy” – where BPM+Build is the middle-ground, leveraging several more simplistic transactional services and wrapping them into processes that make sense to the business.

Dr. Stein of Aris BPM Blog:

Computer users love to challenge each other by starting totally useless “flamewars”. Just think about how emotion comes up if people discuss Windows vs. Linux, Extreme Programming vs. classical software development, iPhone vs. Android, PHP vs. Ruby or EPC vs. BPMN. Wait, EPC vs. BPMN? Yes, I noticed several times that people have very strong feelings about both process modeling notations and tend to favor one over the other. For example, both groups (EPC lovers and BPMN lovers) claim that their notation is more expressive than the other one. But how could that be? Is one group lying? Or is there just a big misunderstanding?

I’ve personally never noticed this EPC vs. BPMN debate.