David Brakoniecki has some good commentary on OpenText’s Q2 results on his blog.  Not about the financials of the call, but about implications in the BPM market:

In their core market of electronic content management (ECM), the Opentext world is neatly divided in two:  Microsoft/Sharepoint and SAP are allies and ECM Documentum and IBM Filenet are the enemies.

At least this simplifies their strategy.  They know who their friends are and who their “enemies” are.  Companies rally around relatively simple strategies and objectives.

Also interesting were the comments about BPM integration (two BPM suites integrating, not to mention integrating them with the rest of OpenText’s offering):

• 2012 will be a year of product development to bring the products together and create a coordinated roadmap
• The combine BPM product line will be integrated with the rest of the Opentext business in 2013

So far David’s blog has been the best way to keep up to date on OpenText’s BPM developments.

In Brakoniecki’s post on Lean Start-ups and the idea of Entrepreneur, he delves into the apparent conflict between the Taylor “Great Man” theory, and the Lean Startup’s emphasis on leadership, and learning (all while in essence refuting the idea of the Great Man). I commented on his blog directly but thought I’d share my thoughts here as well:

The relationship between the Great Man theory and Entrepreneur is a bit of a quandary in the lean startup community.  On the one hand, many people in the startup business contend, paraphrased, that “entrepreneurs are born rather than made.”  But the lean startup seems to say that entrepreneurship can be taught, learned, rather than born inside you.

The “born with it” argument, to me, seems to be in alignment with the idea of building companies around Great Men (very Ayn Rand, in my humble opinion).  But that doesn’t make it correct.  In my experience, these things aren’t mutually exclusive.

I’d put it this way.  For some people, being a good entrepreneur *appears* to be innate.  We don’t know the person well enough to know how this talent developed, and what their experiences were – they’re a black box. To us, as if by magic, they are really good at entrepreneurship (and leading).  For others, it is more obviously a learned, thoughtfully acquired skill.

But I would argue that for literally everyone – born with it or not – if you decide to begin the journey of entrepreneurship, you can improve your chances if you learn.  And learning what Lean Startup has to offer is clearly a benefit- even if you choose not to apply lean startup methods to your efforts, at least you’re making an informed decision.  If you do apply lean startup, then of course the goal is that you also learn about your potential market and customers faster as well.

One thing clear to me is that lean startup (any startup) still requires leadership.  It’s hard to imagine any other possibility.  Critical decisions, pivots, and hires have to be made.  I just don’t see how you do that without good leadership.

And of course the other wrinkle is that not all leadership looks the same.  Contrast Tony Hsieh‘s style with Steve Jobs for example…

David Brakoniecki chimes in on ACM’s product/market fit problem, and hopefully he won’t mind me quoting liberally from his post.  On the one hand, there is the rock:  free or nearly free software from various providers that addresses the freelance/collaboration use case…

Freelance Web designers and developers need a tool to collaborate with clients and to manage projects. They simply can’t afford to pay much for it but there are thousands of them. Basecamp pretty much plays perfectly to this market. It’s SaaS delivery model and freemium pricing makes it easy for users to get started quickly.

On the other side is the hard place: difficult integrations that must be completed before something like ACM or BPM can be successfully implemented…

If your target market is hospitals or insurance companies then just setting up the integrations and data migration is a massive upfront investment. The promised business agility depends on getting the set-up right and the compelling difference with other case management and BPM technologies is less.

And in this latter market, you find yourself up against established technology companies with robust BPM and separately, robust integration offerings (often well-integrated into a single suite).

This doesn’t shoot holes in the “methodology” side of the ACM pitch, but it sure points out a problem for the technology side of the house.  And there is some market evidence to support this view.  A few of the “ACM” vendors have run into the reefs – e.g. ActionBase (which I still think had the best articulation of a product that reflects ACM values, and yet was clearly not a BPMS).

I liked Dave Brakoniecki’s analysis of OpenText’s December comments on their BPM strategy. Like Dave, I find it interesting that they think they’ll be most often running into Pega and IBM.  Dave’s thoughts:

OpenText probably need to acquire some rules technology to really compete with Pega and IBM. Shame that Progress snapped up Corticon a few days ago.

His analysis is spot-on in that without a rules engine, OpenText has a chink in the armor that the other vendors can exploit.  And they’re not exactly a pure play vendor that can appeal to the “best-of-breed” argument with their customers.  It just looks like a tough hill to climb.

Rules engines aren’t that complicated, per se.  It is thinking through the design of user interface and maintenance of these rule systems that is where the value is, and where the challenges are.  Incorporating them with a BPM suite is another interesting problem to solve, though one option is obviously to leave them loosely coupled.  I think OpenText has their work cut out for them to differentiate themselves in this market, but we’ll certainly have a chance to see how it develops.

IBM has released a new update to BlueworksLive, on December 17th.  We had a preview just two days before it went live to discuss some of the thought behind the features. What interests me isn’t just the outcome but the thought and direction behind it.  Once again the specific features seem “small” but have interesting consequences and implications.

Starting with the shorter topics first:

The Word Export is much more pleasing to the eye than previous versions.  Having the graphics of severity and the diagram itself exported are a big help to the overall readability of the document.

The expand-all/collapse-all functionality in the Process Diagram is also convenient – especially when prepping to export a large diagram.

The BPMN export API works as advertised.  This is an important step to allow people to use BlueworksLive without feeling locked in.  After all, in a cloud “rental” model, one of the big fears is that your data is residing on someone else’s servers.  IBM needed to provide a clean way to get at that data and make it portable.  Not to mention, this lets customers apply some of their more standard SDLC to their requirements production in BlueworksLive.

First, there was quite a bit of attention given the Decision Discovery feature added to BlueworksLive.  I’d heard that this was coming, but I was picturing it as something that would be added to the automation features of BlueworksLive – I should have realized that the “Discovery” in the name implied that it would be part of the modeling (“Blueprinting”) part of the product.

The premise is that you set up a few Considerations (one or more).  The combination of these considerations is like a truth table.  However, BlueworksLive also lets you provide more than one conclusion – which is nice.  When modeling, we can label the column headers smartly, allowing the contents of each cell to be concise and simple (Yes/No, >$500/<$500, etc.).  Finally, we can label the conclusions well- “Adjustment Required”.  If we have more than one conclusion, it gets its own column to keep ideas separate.

A couple of surprising perks:  you can reorder columns and rows with a simple drag-and-drop.  Look, this makes sense given the point of the tool – flexible discovery of decisions.  But this is the kind of fit-and-finish often missing in enterprise software.

I also appreciated that they thought through why the cells should be free-form rather than constrained to integers or strings or a particular data type. The goal is to leave discovery unconstrained.  Plenty of time for constraints when you move into modeling for execution (had this been targeted at execution, you can bet there would have been tight treatment of data types).

Like David Brakoniecki, I think BlueworksLive is showing that it will live up to its promise as a BPM discovery tool.  Not because it does everything it needs to do today, but because IBM have shown that they’ll keep turning the screws until they get there.  His take on the impact of tiny changes at this point in the maturity of the product:

Now, at the push of a button, the process documentation and process diagram can be exported into a single word document. Basically, this document becomes the high-level scope of any potential BPM deployment or process improvement initiative. All of the great power of Blueworks around social collaboration and process discovery now can painless produce a document to playback to the client or business teams for review and iterative improvement.

SaaS products really emphasize the benefit of incremental improvement.

It isn’t easy to fill in the white space.  It is harder to design a good software solution from scratch than to fix a bug in an otherwise working solution, or to design a small addition to a working piece of software. What if you could have tools that just help you right away, and then later infer the process (filling in the white space for you)?  That’s the promise of “process mining”.

Along those lines, Dave Brakoniecki tackles the idea of “inverting the process life cycle“, in response to a post by Keith Swenson on the subject:

Imagine a patient file or case. This is a favorite example in the ACM space since the expertise of the doctor defines the process or work to be completed. How useful to the doctor is a case management tool that has no information on the patient and no ability to schedule tests? Not very – all of the work would need to be done outside the tool and duplicated in the tool. Still, building integrations to the patient records and to the systems that organize blood work, for example, would be better done at design time than run time.

Even if this was possible at runtime, few doctors would be interested in doing it.

(incidentally, I think this is why something like IBM Watson is getting good airplay in medical / healthcare circles.  It has data and context on a subject domain)

So, a lack of preloaded or pre-integrated data seems like a problem. But supposing you have this pre-existing data, there are a small number of firms prepared to help you discover the processes you are already executing without realizing it.  It isn’t yet clear to me how big these services projects are (there aren’t any shrink-wrap solutions that require no services).

And Dave points out another issue:

In most organizations, what is problem with their Sharepoint deployment, their Lotus Notes application or that little Access database application they wrote three years ago? In almost all these cases, the problem is the same. End users were given a powerful and flexible tool without training and ending up building a system that is impossible to maintain but essential to the business.

I have seen many successful projects start from this position: The end users actually asking for more help in managing the technology so they can spend more time doing their jobs.

This is summarized nicely as “the Sharepoint Effect” in a previous post on this blog.  And I agree with Dave – many projects start exactly this way.

Then Dave gets into what might be an example of ACM in the wild – Basecamp.  Although it doesn’t bill itself as an ACM tool, one could argue that it is one, by accident.  In which case:

Perhaps the most important reason for the ACM camp to try and adopt a solution like Basecamp is that it would give them immediate mainstream legitimacy with tangible customers who have already inverted the process life cycle and will do it again next week. It probably also indicates the delivery model and price point required to disrupt the markets they are targeting.

I’m not sure the ACM vendors are prepared to be at those price points, however.

Keith makes some interesting points in his original post, not all of which are argued by Dave.  Certainly measurement before improving is A Good Thing.  We’ve been implementing “shadow processes” and listening to processes implemented in other systems for years, and using that data to inform our new process models.  But because we’re listening to real systems, we have to implement the broadcast or listening of those interesting transitions in the systems of record.

In short, there’s no magic bullet. But you can certainly do better by measuring twice and cutting once, as they say.  But we can do better than that. We can measure any number of times, and we can get more than one “cut” at the new and improved process by leveraging A/B testing to determine what actually produces the best results.

David Brakoniecki wrote a great post on “those pesky rules” last month and I just had to comment on it.  The startling finding was that at one insurance company, 30% of the rules were flat wrong.  As David says:

Given that the insurance business is really little more than sets of rules – underwriting rules, claims management rules, customer cross-sell rules – and that it is a heavily regulated business, incorrect rules are more than bad business but potential regulatory nightmare.

Bingo.  The problem with rules is that many of them are simple, but the interactions between them are not.  The resulting outcomes are not.  There are better ways to represent these kinds of solutions (constraints, heuristic search, etc.) but they require pretty advanced education to model, and most companies are looking to de-value expertise rather than invest in expertise. So simple rules are used – simple in each instance, but complicated when taken as a whole. Unpredictable as well.  The right abstractions are not available for modeling, so granular abstractions are used, and they’re just not good enough.  It becomes unmanageable or inaccurate over time.

As Dave goes on to say, it just isn’t realistic for the business to maintain rules without assistance from IT.  We have to get past the idea of IT or Business owning the assets of the business.  Both parties need to take responsibility for the health of the business and the health of the assets that allow that business to perform smoothly, or at all.

Dave Brakoniecki writes about Technical Debt:

The fundamental metaphor underlying technical debt is easily understood in technology circles but nearly incomprehensible outside of them. Unless you understand in detail the technical trade-off you have no appreciation for how you are ‘borrowing’ which makes it a trust issue between the business and IT teams. If this trust exists, then you don’t need the metaphor to make the problem explicit. If the trust doesn’t exist, then the metaphor won’t help you.

A counterpoint to this – I recently saw a talk by HomeAway’s CEO, Brian Sharples (at Capital Factory).  I also had a chance to talk to one of their lead developers (a friend of mine from way back).  When I asked my friend how it was going these days, he said (paraphrased) “we’re paying down a ton of technical debt right now… and when I look back, and ask if we should have done anything different, the answer is no.  I think we made the right call.”  Interesting. Thanks to Eric Ries, I knew what he meant by Technical Debt.  I also knew what he meant about paying it down (HomeAway has been acquiring companies, and paying it down in this context means they are consolidating these companies onto common software systems instead of maintaining fragmented systems… )

In their terminology, technical debt is a cost that has to be paid in the future.  It can be estimated in terms of work effort.  But consider a variable interest rate – you have the same problem. You estimate costs, but you don’t know for sure what the future cost will be.

Finally, I actually heard the CEO refer in his talk to paying down technical debt.  He had the same meaning the developers had.  What this told me is that he’s invested in the whole company, not just the “business part” of the company.  Those techies are his people too, not just an IT arm to be offshored later.  And they explicitly understood they were postponing a cost (integration) into the future, a future in which they could afford to pay it down (IPO money helps with that).

Dave goes on to say:

The reason the metaphor doesn’t hold is that the unit of borrowing can’t be quantified. Technical debt is an attempt to use the well-understood concept of financial debt to explain a software development problem but everyone (business and technical) understands what happens when you borrow money and the cost of that decision. It’s explicit.

If you borrow $1, well then the amount you owe is $1. People have mortgages and credit cards and use them to make decisions to borrow money so both everyone in an organization can be reasonably expected to understand the basic concepts of financial debt.

The same is not true of technical debt. The unit of measurement is entirely a trust issue between people. Most technical debt conversations are really the engineers saying to the business stakeholders: If you make me do it this way and in this timeframe, it will cost you more in terms of effort to support per month.

But, unlike the financial debt, the interest may not materialize. On your mortgage, you know exactly how much interest you will pay. It’s not a random number.

Getting a handle on the cost (future cost) of technical debt is hard, but it can be done.    You usually have an ongoing cost that you can think of as interest (the cost of maintaining two systems, for example, or supporting two databases when you only need one).  When you remove one of the two systems, it may have a lot of accumulated debt-  which is now all retired debt.  Presumably its functionality was either no longer needed, or replaced by implementing (and paying for) another system.

As to quantifying – this all comes down to estimation and convention.  A proxy is just lines of code (each line of code incurs some maintenance cost, in theory).  Another proxy is to put work estimates against it and cost those.

One might expect me to come down against metaphors – I’m not a fan of using them as proof in arguments or debates.  They’re better used to explain yourself or your thinking, than they are as “proof”.  But in this case, technical debt is a decent short-hand for work-effort we need to plan for in the future.  It avoids people thinking they’re avoiding cost when they take shortcuts – they’re really just spreading that cost out over a longer period of time (for perhaps a much higher overall cost).  Similarly, it assigns cost to gold-plating the software implementation (more lines of code = more debt).

Pretty interesting perspectives on the concept… for more about applying this concept to processes, check out these posts.

We have some contrary data points.  Pega’s last quarter was good.  So was IBM’s.  But they’re both big companies with too much complexity for outsiders to easily carve out BPM revenue.  However, what I hear on back channels from more than one vendor is that the big vendors are taking dollar share from the smaller vendors, and that the market is also growing nicely. I’ll be interested to see what Gartner and Forrester have to say in their reports on the subject when those are updated.

Jacob Ukelson reports that ActionBase is retrenching in the Israeli market and focusing on professional services operations.  With today’s ASPs for small enterprise software companies, this isn’t surprising – likely much (all?) of the real profit comes from the professional services operation.  Cost of sales for enterprise software is high – but yet there is downward pressure on Average Selling Price (ASP).

Appian reports good results from the first half of 2011 as well:

• “The company signed 34 new-name customers across government, financial services, healthcare, energy and other industries” – Unfortunately, it isn’t clear to me what “new-name” customers means.  Perhaps special terminology withing Government purchasing circles.
• “Sales orders for the Appian BPM Suite grew 158 percent over 1H 2010.” – Unfortunately, it isn’t clear if this is the # of orders, or the US Dollar value of orders… Obviously one interpretation is much better than the other interpretation.
• “… with Appian Cloud orders growing 181 percent over 1H 2010.” – Again, number of orders or Value in US Dollars?

They also call-out some of their accomplishments in cloud and mobile BPM – well deserved pats on the back.  But I do wish I could get to the bottom of the numbers they’re reporting.

Dave Brakoniecki is also a little frustrated with Appian’s specificity: 

The problem is:  Those three numbers are all the information in the release.

No information on absolute customer growth or way to extrapolate into any actual financial performance. I’d love to know how many developers they currently employ and how many salespeople.  What is the trend on all these metrics?

As one of the last pure play vendors standing, a full set of Appian results might have provided interesting insight into the trajectory of the sector.  Tibco, IBM and Pega all have all sorts of other product lines to complicate the picture. Appian might have provided a pure proxy for the BPM market generally.

Still, 34 new customers is more than 1 per week in 2011 so I guess we should expect some good case studies in the coming months.

Unfortunately, this private company specificity isn’t anything new… even with the Appian results in 2009.  In fact, if you look back at those results, there was talk about international expansion (which, as I noted back then, is more challenging than it looks).  Subsequent reports I haven’t noted any discussion of international, and the numbers aren’t apples to apples. The only thing that is truly clear from the release is that Appian is acquiring customers at a rapid rate.  We can’t tell if it is a good business, but it is a good growth rate of named customers.

Speaking as another private company, I’m not sure we want to release revenue numbers publicly either.  But then, I’m not sure anyone is trying to extrapolate from our numbers to determine if the BPM market is healthy or not.   Directionally, things are good for services firms across several vendors.

I’d love to hear from people about what they think the real #’s are for BPM software for all of the BPM vendors out there – IBM, Pega, Oracle, Tibco, Progress, Appian, and the other independents / pure plays.  Drop me a line if you think you have a read on any of these.  Or comment anonymously!

David Brakoniecki comments on the ACM discussion on LinkedIn:

Over on Linkedin, there is a spirited debate over several aspects of the Adaptive Case Management (ACM) movement going on.  The whole thread makes is worthwhile a read if you are trying to understand what exactly ACM is trying accomplish, how the community is organized and who some of big players are.

I commented on his blog but thought I’d repost here:

I saw this thread-  too bad it descended into something – how shall we say it-  not very professional.  I like the definition of DCM – it makes that particular definition much more apparent.  And I agree with you – almost every BPMS out there is also DCM.  I’m sure there are/were a few exceptions, but the surviving BPMS’ all have good rule systems to leverage (or can leverage external rules).

Now we’re just left with the muddy ACM definition.  I found it particularly amusing to see that people who have previously argued that BPM can’t succeed because we can’t agree on the definition, then turn around and argue that no definition of ACM is needed!

And I also find myself agreeing that I don’t see the technology issues with case management.  The differences that are communicated are at a really high level, unsubstantiated by an actual software artifact or code snippet or API (to give a few examples).  Philosophically the difference between basketball and “soccer” is quite large, but to a kid with a ball, it turns out he could play either one.  Actually, a kid could probably play either of these sports with any decent ball if he/she was motivated…

I’d recommend reading David’s summary more than the original thread, or at least stop reading the thread when it leaves off the constructive and starts to get a bit heated.

These are three different things.  Recently Dave Brakoniecki commented that most successful change implementations or BPM programs had executive sponsorship.  And I responded that, of course, there is selection bias involved- because successful programs will collect executive sponsorship.  I attempted to encourage those “stuck in the middle” to find a way to succeed, and use that success as leverage to get sponsorship and support from executives.

Jacob Ukelson commented (cleverly) that this could have been “more about Business Politics Management” – a subject he wrote about previously.  We even got a nice ebizQ discussion out of the topic.  Adam Deane followed up with a missive on Business Politics Management as well… but this is where I think our paths diverge:

The task should go to head of the department for his review. But everyone knows that Mister X needs to be bypassed. Sometimes it’s because he is a slacker, he will never do the task, he has been in the organisation for years, he doesn’t care about the “procedure” and there is no one to discipline him. Sometimes it’s because he is too powerful and can get away with murder. In any case, trying to force the process to make him do the task will end in tears. The best way is to bypass.

Actually, this isn’t the kind of business politics that interests me.  This isn’t leadership this is conflict avoidance (or resolution).  The politics around the particulars within a process are there – and you have to manage them – but the success or failure of your project depends more upon the leadership of your team and the sponsorship of executives – not the politicking of tweaks in the process.

And lest someone get confused, sponsorship isn’t the same thing as leading in most organizations, though it should be either leading or coaching (taking a vested interest in the outcomes).

Jacob returns to the subject here, but whereas Adam addresses design time of processes, Jacob focuses on run-time:

So yes, Business Politics Management is the cousin of Business Process Management – a kissing cousin. Most BPMS vendors don’t consider politics something a BPMS should address. In my opinion as long as BPMS tools ignore all the stuff that goes on around the process (i.e. politics), but has influence on the outcome of the process – they have a big hole in functionality.

Whether you agree with Jacob’s assessment of BPMS vendors or not, what Dave Brakoniecki and I were more focused on is whether executive sponsorship is a pre-requisite for success for your change management or BPM program?  Or is it sometimes a byproduct of a successfully run program?  Should you just give up if you can’t get the executive sponsorship lined up before you start the project?  (I’m not just talking about funding, I’m talking about truly sponsoring)

It seems even with Business Politics Management we have different ideas about what BPM means… But I’ll step away from the terminology and just focus on the funding and executive support – these are things you will have with successful programs by the end, but at the beginning you may have to go it alone for a bit first.

In every review of BPM best practices you’ll ever read, you’ll see listed with extra emphasis: executive sponsorship. Actually, this criterion is listed for ERP projects, CRM projects, Security projects… It is listed for pretty much every type of IT engagement.

There is so much emphasis on this in presentations on the subject that typically speakers on the subject will take extra time to clarify that they don’t just mean an executive sponsor that signs checks, but an executive that is intimately involved with the effort and promotes the effort or mentors it.

But I believe most projects start without this higher level of true executive sponsorship.  In a sense, the team below has to earn that sponsorship.  In many cases, the executive has sprinkled a few preliminary investments along with a few well-understood big bets.  Those preliminary investments are feelers-  to see what might shake out.  They don’t have the executive’s full attention, but they have a little runway and latitude to make progress before they are accountable.  Or they’re given a specific project to tackle, a proof point to the executive that both the team and the technical stack are up to the challenge.

So, if executive sponsorship is critical… and most BPM programs don’t start out with it… are all of these projects doomed?

Dave Brakoniecki writes on his blog:

Over time, there seemed to be a bit of a pattern in the conversation. Successful initiatives were about changing or transforming the organization and tended to be driven from the top. In these cases, senior management decided the direction and the businesses had developed over time very successful human processes and technology platforms for supporting and implementing change.

And further:

There were no stories that I can recall of bottom-up change being harnessed successfully. Innovation at front line of the organization and filtered back up the hierarchy to senior management seems like a harder nut to crack. Even organizations that devolved a significant amount of decision making in their change management process struggled to let the front-line drive the strategy behind the overall program.

I believe there’s a bit of selection bias here.  Successful projects that lead to successful strategy and programs, will have executive sponsorship.  Regardless of whether they start without that executive sponsorship.  Why is that?  Because the successful teams will lobby effectively for executive support, with real data and real successes to back them up.  Executives will choose to put more money on the winning horse.  The best executives will co-opt the best ideas from the effort, find synergies with corporate objectives and strategy, and then change the emphasis of the go-forward program accordingly.

Most really interesting innovations and opportunities will bubble up from the organization – the trick for the executive team is to spot those emergent opportunities and capitalize on them.

If you don’t have your executive sponsorship lined up, think about which executive(s) are likely to sponsor your go-forward efforts.  Think about what matters to them, what their objectives are, what the company objectives are over which they have influence.  And make sure you have good arguments to support your BPM initiative along those lines. If you do it right, it will almost feel like the realization of that executive’s ideas, rather than some “not-invented-here” idea that has to be thrust upon upper management.

Dave Brakoniecki’s post on Nokia, Apple, and the Commodity Trap takes issue with Henry Chesbrough’s argument that Nokia had fallen into a commodity trap – essentially that it was not thinking about its business as a service business.

But Dave argues that actually, the problem is that Nokia’s market has been commoditized at the low end by contract manufacturers around the world, and at the high end, by Apple and Android, which commoditized the app business:

While it was asleep, contract manufacturers made the fabrication of complex and high-quality products a commodity business.  As Chesbrough correctly notes this trend has eroded Nokia’s competitive advantage and their position in the market.  [...]

Ironically, at the other end of the market, Apple and Android have also commoditized the market, just a different market.

Yes, they are selling premium hardware but the handset market has always been heavily subsidized by telecom providers in exchange for long-term contracts.  [...]  First, Apple and then Android essentially commoditized application development in a way Nokia never managed.  Apple and Android have made the mobile data services market explode.

By including a usable browser and making app installation plug-and-play, suddenly anyone could build a data service.  There really isn’t that much the iPhone does that you couldn’t achieve on the Nokia N95 but the amount of effort and development pain involved simply made it pointless.  The pain outweighed the utility until Apple made it easier.

Put another way – Apple has commoditized its complements – application development, for example – more effectively than Nokia has.  And if you can commoditize your complements, then commoditizing is a good thing.

So far IBM is keeping to their word that they’ll keep the updates rolling with Blueworks Live.  Another update just went live over the weekend, and IBM’s summary of it is posted here.  As one might expect, with an update coming a bare 4 weeks after the initial launch of Blueworks Live, there isn’t a lot of meat on the bone to this update, but there are implications if IBM continues the trajectory.

What was added is simply the ability to post updates to one’s private feed (presumably, to specific “Spaces” within your company space).  I tested it out in the BP3 domain and it works nicely and offers the opportunity for others in our space to respond.

With this change (and, no doubt, changes yet to come), Blueworks Live is picking up more of the features found in a tool like yammer.  Of course, for these discussion-style features to be meaningful, the usage has to reach critical mass within a team or company.  It will be interesting when one can comment on a process update in the feed, and have that comment also appear alongside the actual process instance (or model) as well.  (There is already a commenting feature within process execution screens – the ideal place to put those comments).

David Brakoniecki’s blog post echoes some of my own thoughts – IBM is showing signs of learning from the MVP (Minimum Viable Product) school of thought, quite a departure from the usual software development process at companies their size. In the comments on my previous post, Marco Brambilla has wondered aloud if it is “too minimum”… but I think it is just a matter of giving it time – and seeing what IBM comes out with next.