The first go-round on Process Debt got quite a few reads and private emails and comments that motivated me to keep thinking about his topic and how to further clarify process debt so that we can use this concept to help manage our process development efforts.  It also motivated me to run a small session at bpmCamp on Creating and Retiring Process Debt.

We had a good discussion during the presentation and lots of examples from recent history to draw on in this room.  A couple of folks from the same company were in the room and as a result they tell me that they now have a common, useful vocabulary for describing trade-off process decisions which are made *all* the time in BPM groups.

Presentation embedded here, but also some rough notes below for those who prefer reading text…

(Incidentally, I used a tool called “Prezi” for this which I find pretty useful for organizing thoughts about a topic that requires a lot of context or gets past a certain number of slides… Something about the spatial relationship of the elements helps maintain context in the discussion.)

First, let’s agree that there is such a thing as Technical Debt, as defined by smarter folks than I. But also, that we can repackage it just a bit to more closely align with Process terminology and concerns.

Why we incur Technical Debt (borrowing heavily from McConnell):

1. Time to market – we want to get our process built quickly so that we can start to reap the ROI quickly – and time is money.  If a process can save you $1M per month, each month of additional development effectively costs you $1M.  Time to market matters.
2. Preservation of budget (for startups, preservation of capital)- We have a limited budget, and we want to make sure we spend it on the things that give us the most leverage for getting ROI.  These are likely the same things that will help justify budget for additional improvements going forward.
3. Delaying development expense.  As a system nears end of life, it takes a very high degree of return to justify anything but expedient fixes -because when a system is retired, its technical debt no longer matters and isn’t paid within that system – it is being paid by whatever is replacing it.

What are the types of Technical Debt that we can be concerned with:

1. Unintentional Debt – debt incurred due to poor technical choices, but not with forethought.
2. Intentional Debt – debt incurred for strategic reasons, with explicit trade-offs.
   1. Short-term debt:  sacrifices made to get a specific release out by a certain date.
   2. Long-term debt:  typically architectural decisions (assuming only one database platform, for example) that can be good trade-offs measured in years.

And then we have “Product Design” debt – which I believe can occur in process projects where functionality is added over time until the originally simple screens have become cumbersome and unwieldy.  This isn’t quite the same as Process Debt – but process projects can become afflicted with it.

Finally, we have Process Debt itself.  I think we can follow on the Technical Debt framework and build on it:

1. Unintentional debt
   1. Process Shift – this happens when performance of the process degrades over time.
   2. Requirements Shift – this happens when the external realities change but your process fails to adjust adequately.
   3. Squeezing the balloon – the local process gets optimized at the (greater) expense of other parts of the organization (or customers or vendors)
2. Intentional debt
   1. Short-term trade-offs to get a release out – scope removed, etc.
   2. Experiments to find out which possible solution is the right one
   3. Manual work-arounds in place of system integration (SOA team can’t give you your webservice in time? will a manual work around work for the first few weeks or months?)
   4. Sub-optimal integrations (batch instead of real-time, etc. )
   5. Assumptions around geography or localization or product line support.

Tracking Debt:

1. Enter tasks into work tracking or defect tracking software to track both the items that need to be worked on and the effort required to retire the debt incurred.
2. Measure the process for squeeze-the-balloon effects (can be difficult if the other parts of the balloon are not measured).
3. Teach the team not to take short-cuts that “aren’t worth entering compensating tasks in the software tracking tool” – if they’re not worth it then the short cuts aren’t worth it either.
4. Another suggestion (from James Shore) is to measure Source Lines of Code (SLOC) as an approximation for technical debt. It isn’t an exact measure, but since lines of code will affect cost of maintenance, it is a reasonable proxy.

The starting point is that you have to have a system for tracking your work and work backlog – and from there you can mature the way you think about Process Debt based on what works for your organization.

As of February 1, BP3 is in new offices.  We’ve moved just a short distance from our old office on Balcones Drive in Austin, to our new office at Plaza 7000, at the intersection of Far West Blvd and MoPac Expressway.

We’re really happy to have the extra space, and our new co-working arrangement with Red Velvet Events.

Today, I unwrapped a little present for the new office that makes it feel like home to me, and that’s an espresso machine:

First latte at bp3 headquarters

Its a Nespresso Citiz, and yes, I’m expecting to be wide awake at the office from now on, and a little less cash will be going to Starbucks this year.

At bpmCamp we had a great session on BPM Requirements led by Zelda Durden.  Often the answer to the question “How much is enough?” is “I know it when I see it” – but we wanted to go deeper, and Zelda offered to help shape the discussion. How can we tee things up so that we know how much is enough as part of our requirements process?

She broke things up into two phases for consideration:

1. Exploring – no budget approved yet, no Project Manager either.
   1. Strategy – what needs to be improved from 50,000 feet, and what are the business priorities and goals.
   2. People – who and how much commitment from the business?
   3. Process- scope, SIPOC
   4. System – What is the current system?  Current state of the process?
   5. Discussion:
      • getting people commitments is difficult at this stage
      • using this information to help prioritize projects – along with ROI and other tools
      • scope management is difficult once users see what is possible.
2. Discovery – a real project is on the books, with budget.
   1. Strategy – Critical Success Factors (CSFs), ROI calculations if necessary, alignment with corporate objectives
   2. People – current skill set of process users versus new required skill set?  Change management: figure out the influential people and engage with them.
   3. Process – full process audit/investigation.
   4. System – plan for legacy systems, determine the extent of Teamworks (BPMS) in the solution.
3. Development Starts

First playback drives a lot of requirements changes.  Not planning for that level of change is just kidding yourself.

• Iterative development – iterations range from 3 weeks to quarterly – which keeps the lifespan of requirements to some reasonable level.
• Initial “onboarding” of process focussed on keeping it very simple (no integrations, or as few as possible) – get the process right first.
• Best process information comes from the end users – have to get in front of them and get feedback.
• Blueprint could be used for initial process modeling / analysis – but has the disadvantage of forcing you to consider licensing issues (unless you have a site license, etc. )
• Some people don’t get flowcharts: figure out the tools that work to communicate with them.  Draw on the whiteboard, for example.
• Teamworks as a process document repository (even for processes that are never intended to be TW apps).  While this isn’t the primary use of Teamworks, there was general support for this idea.
• “BPM Document” like a mini-BRD
• BRD still developed for interfaces / web services, etc
• Plan to develop process for project selection/kickoff

There was much more discussion than what we’ve captured here – but that is the nature of these things – you get into the conversation and you forget to take notes!  A few related thoughts come to mind for me, which I’ll share here.  Our CEO, Lance Gibbs, has some great common sense yardsticks that he often communicates to people on BPM projects who aren’t familiar with how to think of requirements:

• Does it affect ROI?
• Does it impact business objectives?
• Does it impact customer service?
• Does it impact throughput?
• Does it impact quality in a measurable way?

You can think of similar questions.  If a requirement doesn’t address any of these concerns, it should probably go in a secondary bucket to “come back to later” after you’ve first dealt with requirements that DO affect these criteria.

We applied a similar approach to documentation:

• Does it reduce work?
• Does it reduce waste?
• Does it reduce risk?
• Is it required for regulatory or other legal reasons?

It turns out we as an industry turn out a lot of doc that does none of these things.

More to come from bpmCamp 2010 @ Stanford…

Interesting developments in the land of “tablets” and “netbooks”.

It isn’t really my area of primary interest but because I like following Apple’s product direction I follow the news.

First, there’s this article from the day after the keynote, in which Andy Ihnatko goes into great detail with his iPad experience.  I like that he took the time to actually use the device rather than rushing to get a story out and cutting short his time to experience the device.  I’ll note that most of the journalists who stayed and laid hands on it actually had a more positive impression than those that didn’t.  That’s surprising (usually expectations meeting reality is a set up for disappointment).  And it says something about Apple’s attention to detail.

Some of the comments that jumped out from Andy’s review were that it “felt right”.  The “rightness” of products is something Apple has really been excelling at in the last few years.  Another was his commentary on its speed – that it actually feels like you are moving something – not just gesturing and waiting for the phone to move it – a much more complete experience, if you will.

The implications for the iPhone are that Apple may be able to squeeze its A4 (or similar) design into an iPhone and offer this kind of speed in the smaller form factor.  I think there’s limited runway for SPEED to differentiate with phones – and we’ll hit those diminishing returns faster than the 20 years or so it took with PCs -  but right now there’s a lot of room for improvement over my iPhone 3G, and it sounds like Apple has a chance to do that – and still preserve battery life.  That’s impressive.

The truly impressive thing Apple did was leverage the App Store to make the iPad instantly relevant instead of making it a platform in search of applications and utility.  The Kindle and other single-purposes devices suddenly pale in comparison.

Also, regarding the most oft-reported shortcoming (no Flash support):

Months ago, I installed a browser plugin for Safari called “ClickToFlash.” It blocks all Flash content. You’ll see a placeholder image in the webpage and if you want to view the content, give it a click and it’ll load in. I have not noticed any drop in my ability to enjoy the Web. What I have noticed is that my browser is faster and more responsive, and that I can leave a couple of dozen tabs and windows up for weeks without having to force-restart my Mac.

Interestingly, I do this as well, and it doesn’t diminish my experience one bit – in fact it enhances it.  Granted, I do like the option of turning on flash for, say, streaming stock quotes.  But HTML5 can handle that level of animation and is “more standard” than Flash… I think Apple has done the smart thing here by protecting their platform and brand image, and putting pressure on Adobe to step up and make Flash a better product, or get out of the way and make way for HTML 5.

Next, the North Temple blog has an interesting post: On iPads, Grandmas and GameChanging, but I would have called it, so a Grandma, a Technophobe, and a Luddite meet in a bar… The short point here: people he never expected to be interested in a computing device are interested in the iPad.  I had a similar experience when my parents told me they were “buying each other iPhones for Christmas.” And then they asked me if they should get the 3G or 3GS… seriously?  I was tempted to tell them 3G just so they wouldn’t leap frog me technologically.  Then, I find out they’re Netflix subscribers.  When my parents start buying something technical – it is going to be big – because they are NOT early adopters anymore by any stretch.  But they are influencers.  My dad proudly tells of all the guys at the golf club who now have gone out and gotten iPhones to keep up.  And hey, they like the big numbers on the phone.

On a surprising, but I think intelligent response to the advent of the iPad, Acer says it will not release a competing device per se.  I think it is refreshing that Acer is sticking to what it does best.  Honestly, I think this is what RIM should do – make the keyboard experience better and better, rather than try to be a touchscreen phone company.  Acer understands that if they make a tablet it will lack the advantages of Apple’s iPad, but it will have all the same disadvantages.  So they’re punting (for now). Smart move, in my opinion.

Many pundits surmise that Apple won’t have a 2 year lead this time… but I think they will have at least 1 year before a competing system (an Android tablet?) will come along that can leverage apps (android apps?) that even come close to putting it in the same league.  And Apple is also adding pressure by having what looks to be better performance that will be tricky to match in the short-term. The key points from Lin of Acer:

Lin pointed out that designing an iPad-like device would not pose any technical challenges for Acer, but said such a product does not fit into Acer’s business model.

Apple is able to support the iPad through its iTunes ecosystem, while few other makers, including Acer, have comparable experience in operating an online store, Lin noted.

Astute analysis.

Now, StevenF argues that the iPad is a signal of the New World, versus the Old World.  Gen X being smack in the middle of old world computing, and the New World being targeted at those both older and younger than Gen X.  I’m not a big fan of generational themes like Gen X, but he has a point.  If computers in the future will “just work” and reduce the expertise required to use them, they become accessible to more people, and become more important to our society.  I’m constantly trying to get people (rather, the people who ask me IT questions) to switch to Macs because the number of IT-related issues is so much less (as judged by how often they ask me for help).  But an iPhone? I never get questions about how to get some driver installed or printer to work with it… !

I especially enjoyed reading how stevenf railed against the iPhone’s closed system at first -but a month later came back and used it full time.  Because it is just a better phone / smartphone experience, and the open/closed argument doesn’t really matter outside of technophiles like me.  And even I can see that it shouldn’t matter to 99% of the world’s population.  When it is your phone, or your car, you just want it to work. Period. No BSOD. No crashing.  To that end, foursquare can you please fix your app? It crashes more than any other 3 apps I use combined.

So how are things going elsewhere in smartphone land?  Jay Yarrow of the Insider says that the Google Android app store is a joke… You don’t often hear Google described as “sloppy”.  The fact that Android developers feel they can make more money on the Apple App Store is not a good sign for Google/Android. And it is an indication that doing this stuff right is harder than many of us assumed.  From Skyhook Wireless:

In December, wireless firm Skyhook Wireless produced a report about developer frustration with Android. Skyhook interviewed 30 mobile application developers and concluded, “developers are not generating real revenue via Android apps.” As a result “developers are becoming hesitant to invest more time and effort into apps that do not pay off.”

Ouch.

Finally, some would argue that the iPad is a sign of the third revolution…

I’m looking forward to laying hands on the iPad. But more than that, I’m looking forward to iPhone 4.0 – I want to see if it is worth upgrading!

Well, after much celebration before announcing the details, we now have some (just some) facts about Appian’s 2009.

It sounds like it was a good year – as MWD reports, its license revenue was up 59% (but we don’t know from what base, much like Lombardi’s reported numbers before it was purchased), and customers doubled.  Of course, another way to phrase this is that ASP declined by 20% (if my math is right), or that revenue mix has shifted from prepay (enterprise license revenue) to either post-pay or subscription revenue.

MWD’s assessment is that international revenue will grow faster than domestic revenue.  And while this argument makes sense, having worked at more than one company Appian’s size in my career, I can attest that international revenue can be very erratic.  For a few reasons:

1. When starting from a small base, a single deal (or two deals) can dramatically affect the percentage growth internationally or in a region.  However, with so few data points, it may say next-to-nothing about going forward revenue.
2. Even off of a bigger base, international revenue has so much to do with your sales operation, and so little to do with your product.  There are other products out there.  There are big consulting shops out there. Whether you capture the money (revenue) that is being spent to solve the problems your software solves depends almost entirely on your sales and marketing operation.
3. American companies of this size rarely understand the international markets well enough, and make mistakes which cause big revenue swings up and down.  This is true because the executives usually lack field operational experience overseas, and though they may hire that experience, they may not be able to successfully evaluate those international experts and may end up throwing good money after bad.
4. I’ve seen a single sales rep bring in 30% or more of a small company’s revenue for a single year, only to bring in zero revenue the following year.  Individual sales rep performance is crucial to small enterprise software companies.

Appian may well overcome all of these pitfalls.  But revenue in both the US and Internationally is coming off of a small enough base that we should expect to see high beta for any of the smaller vendors.

The conclusions that Appian’s results really drive home:

• BPM is growing, not dying.  And growing faster than enterprise software generally. (Not just from this datapoint, but from Lombardi, IBM, Savvion, Pega reported results)
• The BPM pure plays were doing well in 2009.
• The remaining pure plays may still have legs and room to run while Lombardi and Savvion acquisitions are digested – even if those acquisitions are quite successful.

Great piece by Kasparov on the combination of human process and machine computation to allow amateur chess players to beat some of the world’s best chess masters.  This is a darn good read – and though not really a BPM article, it should inspire us all to improve with the aid of process and computation.

bpmCamp's patio

Last week Stanford hosted the first “bpmCamp” for Lombardi Teamworks and Blueprint practitioners.  By all accounts the event was a success – sold out at 40 participants – and with some truly great interactive sessions and discussion that is hard to have at a bigger forum.  Our Stanford hosts did a wonderful job hosting, including all of the little details like name badges and maps, but also helping organize logistics around lodging, transportation, parking, and providing an excellent facility in which to have our meetings.  Encina Commons is one of the older buildings at Stanford – sandstone and arches and wide covered patios, surrounded by lots of green – a perfect atmosphere for sharing.  We were lucky to get a reprieve from the rain for 2 days so that we could really enjoy the surroundings (and make the occasional trip for espresso).  Thank you to Lombardi, and Apex (and bp3) for sponsoring the dinner on Thursday night at Pampas – an all-you-can-eat Brazilian feast.

The lawn outside Encina Commons / bpmCamp

And thanks most of all to everyone who came and led a session, contributed their opinions, reached out to their colleagues and made new friends and contacts.  What a great experience.

We’ll follow-up with a series of blog posts based on bpmCamp to share some of the content with a chance to step back and editorialize a bit. The biggest takeaway that I had was that the community needed an event like this to step out of the daily grind of delivering processes and process improvement – to see what others are doing, to see the forest for the trees.  Sessions ranged in size from 5 people to 40, and discussions were often lively…

bpmCamp in Session

Meanwhile, we’ll start with a short session from Friday morning, when we had a cameo appearance from Phil Gilbert, giving his impressions of the acquisition and the plans for Lombardi products for the next 6 months.  There’s a clear focus on proving that they can deliver and innovate “even faster” after the acquisition, as Phil put it.  And they have set themselves some very high, but relevant goals.  In particular, making it as easy to install Teamworks on Websphere as it is to install Teamworks on JBoss today (cur

Phil Gilbert holds forth @ bpmCamp

rently JBoss is your option if you want an embedded appserver), and making upgrades to Teamworks 7 a truly good experience.  The goal is to bring the ease of use of Teamworks to IBM’s customers, and to leverage key IBM technologies but expose them in ways that let you cut through the noise and focus on delivery. It was a motivating message for our bpmCamp crowd because clearly Phil’s attention is still on the BPM game, and this prioritization will keep Teamworks relevant for the audience.  Knowing the developers that IBM/Lombardi are putting on this project and upgrade paths, I also know that this is a crack team of some of the best engineers at Lombardi, which says something about the commitment from the executive team.

Someone in the audience noted afterward that this was a more tactical set of goals than they expected to hear from Phil- who usually talks in terms such as “the Second Decade of BPM“… but if the focus on the tactical reveals that they believe the tactical may BE the strategic right now, I think its a welcome shift-  because truly, what’s holding people back from BPM is not the knowledge that it has value – the press and blogs are full of information on that score – but rather, its the “getting started” effort required that slows things down.  The easier a software company can make the transition from “business problem conceived” to “BPM project underway” the more likely it is that BPM software is applied to that problem instead of sticky notes and a change order on an ERP system scheduled for 2 years out.

There were so many more great sessions to report on, so there will be more posts here about the sessions.  One thing anyone reading this can do for me that will help – is let us know if you’d be interested in attending a future bpmCamp, and if you would travel to attend, or if not, where you’re located so we can judge where we have critical mass for another event.

Thanks again to everyone who participated, and watch this space for more information!

Also, lest you think that BPM was the only educational opportunity at Stanford last week, I stopped by the Cantor Museum for Visual Arts and took a few photos of Rodin sculptures – the collection is the second largest in the world and nearly every piece was on display:

the infamous "Gates of Hell"

Lest there be any doubt that BPM skills are in demand, Tom Baeyens has pointed out that SimplyHired stats claims the average jBPM salary in CA is US$114,000.  Not bad.  Lombardi BPM shows similar numbers.  It supports what we’ve been saying all along – BPM skills are in demand, and it should be a great career for the next decade (or two, or more).  Its just hard to see “process” going away as an important concept in business. So what the SimplyHired stats tell us is that the technical side of BPM is in demand – regardless of the tool set, there is a mismatch between supply and demand right now that is going to take time to fill – and knowing the technical side of the coin is only half of it – the other half being the business process side of things.  I can tell you from experience that not all great technical people have an interest in business process, and not all of them can make the adjustment to focusing on the process over the technology.

In the meantime, your best bet to get up to speed is to get a job that will let you learn on the job, attend training, etc.  There really aren’t any formal education programs at universities that are widely recognized (although there are a small number of universities that have a small number of opportunities to learn about business processes).  There are classes you can take from the software vendors or the likes of Bruce Silver, and there are certification programs-  but no sense paying for certification until you know what you’re doing.  Once you get started, then try to take advantage of the many resources on the net, and resources like bpmCamp.

Continuing on the theme from yesterday, we’ll point out a few more topics here.

• We’ll have a session (or several sessions) on UI frameworks inside and outside of Teamworks, discussing trade-offs of various approaches and benefits of each.
• The relationship between the BPM solution and systems of record.
• Offshore BPM – what is effective / ineffective – discussing real world experiences.
• BPM Requirements Analysis – how much is too much?  How do you know when to say “when”?
• A/B Testing for process improvement

I met with Lee Merrick at Stanford yesterday and we’ll be meeting again today for some final prep for tomorrow’s conference.  We’re excited and looking forward to working with everyone attending to create a great experience.  Thanks to everyone for supporting this idea with your participation and willingness to speak!

Well, as Sandy Kemsley pointed out, this deal closed fast.

Equally quickly, Lombardi shows how a SaaS product can catch up to the news (or at least start to), by releasing Blueprint to Websphere Business Modeler integration today.

Good start to the new relationship – I just wish all the products were as easily rationalized!

I’m excited about the topics taking shape for bpmCamp this week, and I’m going to send out a few teasers before the event starts on Thursday morning.  We’ll do our best to capture as much as we can and share insights with readers of this blog as bpmCamp happens, so keep an eye on this space or bookmark the bpmCamp tag.

Some of the sessions we’re looking forward to:

1. Phil Gilbert is going to stop in to discuss the acquisition by IBM and take questions from customers.
2. We’ll have a few members of the Lombardi product team in attendance to give us some insights into Teamworks 7’s operations, and upgrading to Teamworks 7.
3. We’ll talk about what “Fixed Effort” means as a way to focus on delivering value.
4. A case study discussion of an application of Agile to a project.

There are 20 other topics on the potential list, more to come tomorrow…

MWD Advisors has a post up regarding Running IT as a Business. As they put it, the main objections to this idea seem to be “daft” – that they depend on assuming that IT will run this business in the worst-possible “order-taker” fashion.

As MWD points out, there’s no requirement that IT run their business badly!  However, I will say I can identify with the skepticism that IT can be run like a business, because although “running X like a business” doesn’t have to be interpreted in the most simplistic order-taking terms, I’d be dishonest if I said I hadn’t seen just that happen.  All too often that over-simplification is what the company executives seem to think they want.

So, I think what we have here is a difference between what it should mean to run IT more like a business, and the reality of what people have confronted in their work life.  I think everyone would agree that when IT takes too myopic a view of their role in the success of the business, it is detrimental to everyone.  And if IT provides more business value… that’s good for everyone.

Where IT and Business meet is something that we have had a lot of experience with at BP3 because we’re involved in BPM projects.  You can’t do BPM projects without bridging the gap between IT and Business, and in our experience, the closer aligned IT can get with the business, the better.

I couldn’t agree more with Fabrice Grinda’s post on Why you Need a Partner.  Perhaps I’m biased, since BP3 started with two co-founders.  But I also have a lot of friends who own their own business.  And I’ve worked for people who own their own business.  And it just is true that very few people can be good at everything they need to be good at to run these businesses well.  If their business makes enough money, they can hire the help they need to run their business.  But early in a company’s life, it is really useful to have people on your team who ACT like owners (whether or not they are).

Finding the right partner can be problematic – but my recommendation is to try.  Find someone who is different, but make sure that you appreciate and value the differences, rather than finding them annoying.  And make sure the reverse is also true.  This should be someone you would want to partner with no matter what the startup idea was – not just because this person makes sense for this one idea.

And if the partnership isn’t working, exit stage left and try again- but don’t make each other miserable.  Life is too short to get stuck in an unhealthy business relationship.  Make sure you have a fair separation agreement in place from the moment you form your business.

We’re partners of Lombardi, and we’re avid users of their BPM software, as it is one of our preferred tools.  And we use the coach designer all the time, but I’d like to take a moment to propose a “Top Ten” list for improvements I’d like to see in the coach designer and UI generally.  The coach designer was originally conceived to have the product better support the agile methodology of the professional services team at Lombardi – and it succeeded in that.  It makes building UIs that display, edit, and leverage process data trivial to build.  However, like any good old friend, it also has room for improvement, and as friends, we’d like to put our ideas down on paper (bytes?) for what Lombardi/IBM should consider in their roadmap for the Coach Designer.

1. Either adopt a 3rd party standard UI framework for component-izing UI controls, or add component-building capabilities to the Coach Designer.  Presently, you can build template controls, but they aren’t first order library components (Teamworks authors will know what I’m referring to).
2. Provide controls and control-flow for building mashup UIs.  This is already possible via a html controls in Teamworks, but too much of the code ends up inside the coach, rather than abstracted in the service layer.  Intalio’s mashup editor is one example to look at, but there are lots of others (including inside IBM), which could be leveraged. I think the key is to consider how to make this interact with the service layer in Teamworks, because the end-product to display in the UI may depend on a series of external calls rather than just one client-side javascript call-out.
3. Ajax as a native capability.  Sure, there are a couple of controls that can be populated or pre-populated via Ajax calls to Teamworks services.  But the Ajax calls need to be modeled in a way that can be seen in the Activity/Service modeler.  The way to make really rich Ajax interfaces currently obscures a lot of what is going on in javascript code.
4. If you look at some of the open source solutions out there- they are working to support existing forms development frameworks, rather than developing their own.  This might be the path of the future.
5. Perhaps easy integration of GWT, YUI, etc. so that they can be first class components in the Coach Designer.  After all, GWT is heavily used by blueprint, so we know Lombardi has the in-house talent on the toolkit to put it to work.
6. Access to tasks should be opened up considerably – available via RSS feed, or via twitter. SMS text to my phone.  Give me options.  No more notification-by-email or go-to-the-browser-page.
7. The process instance could be viewed more as a stateful webservice, which I can manipulate through web services calls even more than I can today through the external activity interface.  These external mechanisms of advancing the process should interact seamlessly with internal mechanisms (for example, if I push a close-activity event from a webservice, it shouldn’t require the model to be different than if a user closed that activity from a Teamworks Coach – and I should be able to force the process to soak up the outputs from the active activity rather than ignore them).
8. Break the portal up into component pieces that are accessible as UI fragments or as webservices.  But don’t just replicate the exact portal functionality for each of those pieces – because some of that functionality really doesn’t make sense once you separate from the portal at large.  Really think about the API someone would want, not just the API required to support the portal/coach functionality today – there is a gap there. (technically the portal isn’t a coach… but maybe it should be)
9. Make it easier to skin the Coach Designer with whatever look and feel makes sense.  Currently its easy to change color scheme, but not very easy to change structure and size of elements, etc.
10. Keep investing.  If you make the right investments, you can get a multiplier effect – meaning, the investment will give process authors more power over the UI, at less development and maintenance cost, to the development team.  If you make the wrong investments, coach designer will become a closed system incapable of building the right kinds of UI the processes require.  But no investment could be worst of all – as no investment in the Coach Designer could mean that customers and consultants abandon it altogether as the cost of building UI’s outside of Teamworks continues to decline as the tech improves.  The right investments will let Teamworks ride on the coattails of these outside technologies at minimal cost.

I’m sure other people have their own ideas.  And I could write a similar list for other products.  Maybe at bpmCamp next week other attendees will have better ideas than mine for their top ten!  Welcome your top-ten comments below!

Ok ok, what could possibly be interesting about Hadoop-based systems and Mathematics?

Well, it sounds fancier to say Hadoop-based system… but really this basic math applies to any batch-oriented system and those of us who have been writing batch processing solutions now-and-then for the last 20 years should at least be intuitively aware of the math presented in this article, if not consciously thinking about it at design time.

The key equation:

Runtime = Overhead / (1 – {Time to process one hour of data})

Or, stated differently:

Runtime = Overhead + {Time to process one hour of data} * {Hours of data}

Where hours of data and runtime are equal.  These equations help explain why a perfectly healthy batch processing system can suddenly fall tragically behind – if the time to process an hour’s worth of new information is greater than an hour, you have a problem – and the problem will just keep getting worse until you:

• Improve the runtime of the algorithm
• Apply more resources to your server / cluster.
• Filter the incoming data better (if possible) to improve your signal to noise ratio and thereby eliminate unnecessary data processing

In the BPM and CEP worlds, often that third bullet is a key element to improving performance – it doesn’t require more hardware – it just requires you to move your filter “upstream” from your BPM infrastructure to your EAI infrastructure or your ESB infrastructure… or from your EAI/ESB infrastructure to the source of the noise… Some would say this is squeezing the balloon, moving the bottleneck elsewhere, but actually, filtering better up stream may make those systems more efficient as well (if generating the payload and calling out to a webservice or ESB requires cycles, then not doing it as a result of an efficient filter may well reduce processing cycles… )

At any rate, its a good read.  Andrew Paier, figured you especially would get a kick out of this article, given our experience back in 2003…

bpmCamp 2010 @ Stanford has sold out!  The waiting list is open, however, and we’ll evaluate additional attendees on a first-come-first-serve basis if we get any cancellations.

We’re looking forward to seeing 40 participants from at least 11 companies, plus independent practitioners.  Topics of discussion will likely include:

• Teamworks 7 and upgrading
• Scaling Teamworks 7
• “Process Debt” and BPM programs – creating and removing process debt
• Delivery Challenges: Moving to BPM Software Delivery (Value Driven) from a Waterfall experience base (Plan Driven)
• BPM Requirements Analysis – How much is enough?
• UI frameworks with Teamworks
• Teamworks and Rules
• Teamworks and Systems of Record
• A/B testing and BPM
• Myriad additional technical and project and process-improvement topics

We’ll continue to revise the agenda topics and schedule as we approach the first day of the conference – and we’ll continue to accommodate new ideas even during the conference.  Look for more on the conference as it approaches, and afterward we’ll share some of our impressions and nuggets of wisdom that we’re able to glean.

Tom continues to update the world with jBPM updates – in this case, using jBPM 4 and Drools to blend process and rules. His updates definitely play to the technical audience rather than the business – but I don’t find that too surprising in the open source world.  From a technical perspective, it is certainly interesting.  Proof that these memes seem to emerge on their own : Bruce Silver has also recently posted on rules and BPM (part 2 of a previous effort).

At some point I look forward to digging into jBPM more thoroughly, and now that it supports BPMN 2, I’m more inclined to make the time, its starting to get interesting for the kinds of problems we look at.  However, I still fear that it is just a bit too technical in terms of what it requires of process authors still.

A previous update confirms that jBPM now supports BPMN 2.0, as of version 4.0.  This is a niche I think open source can help fill – potentially fully implementing a spec that probably won’t be fully implemented by any commercial software vendor.  (Filling out the corners is just the kind of academic exercise that seems to get tackled by *someone* within an open source effort)

Chris Dixon recently wrote that the next big thing will start out looking like a toy.  No, he’s not presaging the rise of toys as the next trend in retail or tech (although, with 100,000 Apps on the App store and 3billion downloads, one could be forgiven for assuming that that would be his point).

Chris is pointing out that the next big thing often starts out looking like a toy because one cannot accurately predict how something simple will behave when it achieves network effects due to scale.  And this is why incumbents often don’t identify the next big thing very quickly – because they dismiss it as a toy (at first).  In fact, I’d say they often go through a few stages of denial:

1. It is just a toy, not worth wasting time on
2. It will only work for a certain niche
3. It will never scale
4. It will never work for enterprise customers (or, it will only work for well-heeled consumers)
5. It will never solve the really high end problems
6. Buy a competing product, or buy the original

I’m sure someone could come up with a better list than mine, however.

Time to register for bpmCamp …7 days left to register, and we’re nearly sold out.

Man. Steve Blank writes some great stuff.  Makes me wish I had gone to epiphany back in the 90’s!  He explains that if you’re going to go work for someone, make sure they have big plans, plans to grow the enterprise – because that growth is what you will benefit as a member of the team.

I thought his IMVU example was pretty interesting.  He mentions Will Harvey and Eric Ries (of Lean Startup fame) as being cofounders who wanted to swing for the fences and turned down buyout offers.  So, being me, I click on the link for Will Harvey – and I see he is at “Finale | Fireworks” along with Chris Hondl.  What a blast from the past.  Will was the TA of a Motorola 68040 assembly language class when I was in college (Stanford CS 110 if I recall) and Chris was the star student in the class.  We had a “robot simulation” game where we programmed the strategy for a robot to interact in a maze.  Mine was one of the four finalists, but Chris’ was a class above the rest in terms of the elegance of design and economy of action. Chris went to work with Will at Sandcastle, and most of us in class were fairly in awe of Will for his chops as the writer of music software for the Mac.

There are times when you realize it is a small world.

At bp3, we’re building a business process company, just like the tag line says, making no little plans.