It’s a great vision, but BPM isn’t there yet.

The concept of Process on Demand enables you to build dynamic processes that can be changed “on demand” to meet changing business needs. This dynamic process selection provides a substantial improvement in flexibility and agility and reduction in design complexity.  But we have to see if those advantages are sufficient enough to achieve the gains in agility, scalability, and robustness to meet the ever changing needs of today’s business environment.

The blog goes on to describe his new approach to process application development.  The conclusion:

What we have defined here constitutes an entirely different approach to the way we think about application development.  Providing services on demand removes almost all of the complexity of handling multiple options, exceptions, change, and uncertainty— all of that is transferred from the process developer to the system.  The consequences of which are dramatic. More complex applications can be built, far easier and faster simply because it is no longer necessary to encode all the special cases for dealing with a complex, unpredictable world.

This description is a bit too Utopian – someone still has to handle all those special cases and exceptions… that just doesn’t go away entirely.  And the “entirely different approach to the way we think about application development” is actually exactly the approach that startups building applications in Amazon Web Services (and other cloud infrastructure providers) use to think about building applications.  So there’s actually some proof in the world of this approach, outside of BPM.

Certainly it will be interesting if these “mashup” processes are manifested “on demand” as Jon describes.  This approach will work better for processes “outside the four walls” of a given business rather than internal processes that happen inside the four walls (Why? Because for the moment, critical internal systems aren’t exposed via services to machines in the cloud).

Luckily, we don’t have to jump straight from internally hosted, on-premise software to this Utopian dream.  There are shades of grey that are achievable today, and tomorrow… (more on that in a future post).

Related posts:

1. Ismael Defines Cloud Computing for Business Users
2. Demand = Jobs
3. Congratulations to Demand Media, Austin

But to actually deliver on the promise of re-use, agility, and scale, if the BPMS doesn’t support your efforts organizationally you will run into roadblocks that have consequences… We’ll get to those in a moment… Here’s Neil’s take:

Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model your even close to finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above – and specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.

The quality of this “separation of concerns” in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.

Neil has hit it exactly.  The separation of concerns seems like quibbling between different philosophical approaches at first – but it is more important than that.  But when the separation of concerns is poor, or when the support for agility is poor, what are the consequences?

• The level of product and technical expertise you need to maintain your solutions goes up.  You can’t easily integrate people who are new to BPM to your project, and even when you do they have to be incredibly skilled computer scientists.
• The level of specific knowledge required of your business (and your technical hacks) is too high to easily bring new people into the project.  Anything they touch may have unintended consequences – sometimes far reaching and affecting more than just the process they intended to affect.
• Fear of change.  If a small change can have broad negative consequences or unintended side-effects outside of the process we’re editing, we will fear changing it.  We lose agility.  We might abandon a common implementation in exchange for process-specific implementations – and therefore losing the benefits to efficiency that re-use provide.
• Testing overhead.  If a small change in one process or process area can affect a broad array of other processes, the testing overhead is quite high.  Essentially I have to re-test everything.

But these are just the tactical problems. The real problem is that your BPM team won’t achieve the business outcomes you’re looking for – the I in ROI will be more expensive, the time to market slower, and the R lower.  It can wipe out much of the promise of BPM in the first place.

You can see some of this differentiation when you hear pundits and gurus talk about how “rigid” BPMS’ are – this says more about the BPMS they’ve been using than it does about the notion of a BPMS.  Meanwhile, some of us are pretty happy with how flexible our BPMS is… draw your own conclusions.

Neil’s next point:

Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of “a place for everything, and everything in its place”, other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.

Reading this, it reminds me how much hue and cry there was over a certain company with a BPM product, buying an upstart company with an allegedly overlapping BPM product…. There was real differentiation in the process repository and in the basic architecture of the design environment.  But it was the kind of differentiation that customers and analysts would often miss – because the value isn’t as apparent in iteration 1 of project 1 (although it is apparent if you do them side by side).  It becomes much more apparent in iterations 3 and 4, projects 5 and 6.  If you’ve owned a BPM product for more than a year and you’re still looking at getting process #1 deployed, I’d recommend two things:

1. See about getting some professional help from a boutique consultancy focused on project success.  If you’re already working with one, consider a new one.
2. If that doesn’t get you on the path to more productivity and better use of your product, consider a different BPM platform.  You might have picked the wrong one.

Meanwhile, keep an eye on MWD’s research and their attempts to delve into the real differentiation between BPM vendors, and don’t just get caught up in the bright shiny features they’ll parade in front of us.

No related posts.

Have you noticed an increased presence of Apple products in public spaces and workspaces in the last few years? Turns out that 21% of information workers are using one or more Apple products for work. Almost half of enterprises (1000 employees or more) are issuing Macs to at least some employees – and they plan a 52% increase in the number of Macs they issue in 2012.

But that’s just Macs.  The numbers are actually more stark for iPads and iPhones. 11% of the workforce using iPhones, 9% using iPads, and 8% using Macs.  The trends are most highly supported by execs and managers – who use Apple products at twice the average rate (over 40%), and with the youngest workers, who also use Apple products at twice the rate.  Great trends for Apple products in the work place.  Think about that – you can reach the most influential members of business – 40% of them and growing – via Apple product-focus.

So the debate of which mobile OS to target first for your mobile app has been an interesting one.  Last year (actually late 2010) Fred Wilson came down on the side of Android first.  But while this might have been a good “by the numbers” recommendation, there are some subtleties that I would have argued made iOS still the place to start for most mobile apps:

• iOS device owners spend more money on apps (and content in general).
• iOS device owner demographics trend toward higher income brackets ( desirable demographics to sell to and advertise to )
• Apple’s iPhone and iPad had healthy halos around them that made them attractive “launch” vehicles for an app.  Wherever you look at ads for an institutions “mobile app” the premier imagery features a prominent iPhone.  Later on these institutions started including Android phones that look… well, they look just like iPhones anyway.

Finally, regardless of which OS you target first, or even if you’re cross-platform from the beginning, you might as well release on each platform one at a time – and get the press release mileage out of it.

Articles like the Forrester article, and of course Apple’s amazing Q4 performance, are reminders that the iOS platform is still the one with cachet, with the halo.

Related posts:

1. iPhone in the Enterprise
2. Six Barriers to BPM Adoption in the Enterprise
3. Fascinating TechCrunch Article on the New Enterprise Customer

Businesses all over the world need more programmers. Every company I know is hiring engineers (e.g. see this list of NY tech startups). Top programmers can make $100K+ right out of college. Yet there were only about 14,000 computer science (CS) majors last year. Meanwhile about 40,000 people got law degrees even though demand for lawyers has been shrinking. America is suffering from what economists call structural unemployment:  jobs are available but our labor force isn’t trained for those jobs.

Plentiful job opportunity is just one great reason for people to learn how to code (program).  Unfortunately, after the dot-com bust, the news media and many cynical people convinced many college students that software jobs were going overseas and never coming back.  It was a classic market-driven overreaction to a correction. In places where students have good data about market dynamics (e.g. Stanford) the number of computer science majors are up double-digit percentages each of the last 3-4 years.  Additionally, there’s been a big increase in software-related fields, not typically classified as Computer Science (like Symbolic Systems, electrical engineering, and certain types of engineering and product design).

Chris also points out that programming is a great foundation for starting a tech company.  Hard to argue with that.  If your goal is to start a company, knowing how to code will give you a much better chance of achieving that dream than just about any other skill.  Taking BP3 as an example-  a services company that you might not think requires programming skills to start: I have a computer science background, and Lance knows how to write code, though it isn’t part of his job description(!).  Knowing how to code and being able to do it were what allowed us to start BP3.  And those skills translate well to nearby fields like statistics, that require structured or algorithmic thinking.

Programming is good for your brain – to misquote (slightly) Steve Jobs, it is like a bicycle for the mind. You’ll be amazed at how well you can remember not only where specific lines of code are in your work, but by how long you can retain this knowledge, often even years later being able to trivially skim through your code to the right spot to fix a defect.

An even better point Chris brings up is this one:

  Programming is an important part of being “culturally literate.”

It is hard to underestimate this today.  I’m raising two children.  We’re exposing them to an immersion school that teaches them to speak fluent Spanish (as well as their native English).  But the school (and through some help from outside of school) we’re also teaching them Mandarin (and a little Cantonese).  If our children graduate from college fluent in English, Spanish, and Chinese – they’ll be able to do business almost anywhere in the world and converse with people from all over the world.  They’ll be much better off than their monolingual father, to face the challenges of the future.  But there are two more “languages” I will try my best to pass on to them:

• programming.  If our children learn how to write software, it will open up vast opportunities to them.  It isn’t about how many software languages they learn – even one will be a big head start heading into college.
• product design.  I don’t think it matters if it is physical design or software design, but I want to impart to the kids something of the language of design – the terminology, the flavor, the subtlety of how you talk about it.  I once compared “design language literacy” to the way chefs talk about food and cooking.  If you want to communicate with a chef (or a foodie) about food, you need to learn their language and vocabulary.  Similarly, for design, we need to learn the vocabulary and thought processes to communicate effectively – even if we don’t intend to become a designer.

These programming and product design skills are “meta” languages in a sense.  They transcend national borders and historical language affiliation.

The comment section of Chris Dixon’s blog puts the exclamation point on the value of this post to the general school of thought about coding.

So who should learn how to write code?  You should.  Your children should.

Related posts:

1. Alain Breillatt: You Can’t Innovate Like Apple. (But You Can Learn a LOT)
2. Don’t Learn the Wrong Lesson from Zappos
3. All #BPM Asks You to Do

Leveraging the success of that forum, SXSW has created the Startup Village this year.  The 4th floor of the Hilton will be converted to startup mecca.  I thought the “Lean Startup SXSW” track might have gone away in favor of this modified (and bigger billing) approach.  Apparently not so.  Today SXSW.com announces that they’re bringing Lean Startup SXSW back – and some of the chief instigators are involved again – Eric Ries, Dave McClure, Steve Blank, 500 Startups, et al:

The Lean Startup SXSW will take place on Saturday, March 10th from 9:30am – 6:00pm at the Downtown Hilton (across from the Convention Center), and the most up-to-date agenda can be found here.

So, more central location, same Saturday location in the schedule (good call).  The agenda already has enough speakers identified for me to plan my Saturday schedule.

Once again, good evidence of how SXSW adapts and co-opts good ideas from the outside.  Congrats to the organizers, I’m looking forward to it.

Related posts:

1. SXSW 2011 day 2. The Lean Startup Phenomenon
2. Lean Startup SXSW: Introduction
3. What BPM Can Learn from the Lean Startup

Forward

If you haven’t already done so I highly recommend you “tool up” for iOS (iPhone) or Android development. Speaking more on the Android platform with this point, but Android is based on Linux – meaning that the Android “smartphone” is a small, pocket-sized Linux computer. And, behind this tiny, touch-screen UI, we have an event-driven framework suited for wireless IO (communication) and  distributed client (end-user) services. This makes a good fit for BPM mobility as it applies focused, via platform constraints, user-to-process interaction.

So, in warming up to enterprise-scale BPM Mobility, I want to first walk through a few system architectures – this prior to diving into the details of Android computing. Goal being a build-up towards mobile device UI/IO requirements: from current state to future capabilities.

BPM Desktop Client: Web-portal, JSP Struts/Tiles

The portal has been with BPM practically from the very beginning and it exists today mostly in its original form as a JSP STRUTS/Tiles web-application.

Though somewhat dated in its technology, we must give credit as it has been and still is the BPM workhorse: delivering process execution, management, tracking, and reporting to our end-users. However, the portal leaves us wanting. Today’s users require a “rich web” experience – something beyond the reach of traditional architectures (form based: HTTP get/post). And, though the BPM Portal remains unsurpassed in features it simply cannot function as a mobile application.

For example, with the portal loaded into a 10″ tablet web-browser, there are just too many active features and UI elements for reasonable touch-screen interaction. I found myself constantly zooming in for navigation and then back out again to review effects and options. However, dashboard and charting elements do work well when broken out on their own as separate elements.

IBM-BPM v751 – Advanced: Dojo, Widgets, ReST API

Business Space enhances end-user experience with iWidgets and supporting dojo infrastructure.  Users now have rich web-applications without the downside of additional overhead costs required for custom in-house web development.

New BPM ReST APIs also opens the door to previously unattainable (within reason) web capabilities. Fully in-browser, JavaScript libraries now have direct access to process management. This leads to better performing web applications with reduced UI-interrupting side-effects caused by (legacy) HTML “post” and “get” operations.

Though very close, I’m not sure that we’re at mobile computing. I need to qualify this however because Business Space runs well on Tablets. The catch is that it requires screen real-estate, network bandwidth, and additional CPU. Honestly, these are negligible on today’s desktop/laptop computers. Even reasonably powerful tablets are fully capable of running Business Space over WIFI.

Business Space on a smart-phone though does spot-light a few problems.

Screen real estate is tight on smart-phones! Slow performance is also noticeable as the phone’s CPU just doesn’t seem to keep up and deliver on the same snappy performance previously experienced on both desktop and tablet execution.

Phones require their own native BPM application.

Mobile Applications for Mobile Process Management

Writing native applications feels counter-intuitive but it’s our only alternative given the constraints and limitations for mobile computing. Moving task services to Android (for example) significantly improves performance. Execution latency and UI “lag” disappear as timings drop into sub-second range.

With local execution, we’re looking at:

Reduced IO traffic via local application loading

• Discrete JSON server requests via ReST APIs.
• Native (java) run-time execution
• Local device data-storage. For example, Android includes a database usable for both caching and offline process execution.
• Local application services. These include: notification, document viewers, contacts, identity, and geo/mapping.

Conclusion

In working towards an architecture suitable for mobile BPM we take into account accompanying constraints and capabilities. We’re on a different path in that we’ve re-focused on building native phone applications.

Smartphones require discrete UIs, optimized coding techniques, and light-weight network IO. These challenges though are well worth the investment as mobility advances user-to-process interaction to near-personal proximity.

Acknowledging the tens of millions of new users purchasing smartphones, new expectations are set/re-set on almost a daily basis. Now’s the time to revisit our architecture and build-in these future capabilities.

Related posts:

1. Server Side Javascript
2. With Competitors Like These…
3. App(le) or Website?

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.

Related posts:

1. MWD on OpenText + Metastorm
2. OpenText Picks up Global360
3. More on OpenText and Global 360

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.

Related posts:

1. BlueworksLive May 2011 Update
2. New BlueworksLive Features
3. Blueprint December 09 Update

1. Come up with an idea for a product that you think people will want, but you don’t see satisfactorily provided to the market.  (ideas are often for art projects or music albums, not just consumer products like this)
2. Build a prototype and put together a pitch video to sell the idea
3. Do the research to figure out how big a production run you need to do to make the object “affordable” (whatever that means for what you are pitching).
4. Put your kickstarter project page together, including a fundraising goal that supports your minimum requirements.
5. Wait to see how many people and $ show up to support your project.
6. When (if) project funds, get started building the product (or producing the benefits the contributors are entitled to).
7. Ship it.  If it sells well, consider selling more of the product online, knowing that you now have won over an early adopter fan base.

It favors small production runs, prepaid by motivated customers.  The magic is that you don’t put capital at risk until buyers have paid (up front!) for the product.  It is a great way to get pre-commits from a motivated community. And to my way of thinking, this is just a new (and better) process for finding demand when you don’t have the capital to “build it and hope they come.”

If we relate this to the Lean Startup, or specifically to Steve Blank’s incarnation the Lean Launchpad – one of the key tenets is to “get out there and talk to customers”.  Moreover, to find paying customers.  Not just customers who say they will buy it, but customers who will literally write checks to you.

And when they do this – in great dollar amounts or numbers of customers – then you move into production. Kickstarter gives the product team a chance to do this with physical goods in a way that was nearly impossible 10 years ago.  It also allows an innovative team to address niche demand in a way that they previously couldn’t.  In the same way that eBay allowed people to find markets for niche products, so does kickstarter – in one case auctioning used goods, in the other case contributions toward products that don’t yet exist!

This moves physical products into the realm of a process that looks like:

1. Design
2. Sell
3. Build

Which is much more capital efficient than

1. Design
2. Build
3. Sell

As it allows for less waste (building products that no one wants- akin to getting the requirements wrong in software and BPM projects).  And it allows for some feedback loop between design and selling, before moving into the build phase.

It feels like something that could be truly transformative for small business product development.  I have several friends in the business of producing physical objects for sale (furniture, productivity tools, gadgets), and I’m telling all of them they have to try this process and see if it works for their business, and reduces the risk for them.

As a buyer, the other thing that is really fascinating is the exposure to the process, or craft, behind the production of these objects.  The videos and written updates about the procedures are quite educational.  As a process guy, I see it all through the lens of repeatable process with, typically, an irreplaceable human component.  Gratifying craftsmanship.

Related posts:

1. #IBMImpact: Introducing Complementary IBM products to Lombardi customers
2. Improving the Process for Teaching Entrepreneurship
3. A Process is only as Simple as it is

Well, we know Steve Jobs was not a big fan of the stylus.  And I’m happy Apple didn’t design touch interfaces that required them.  But like many others, I still want to be able to draw my ideas on an iPad with more precision than my fingers will allow.  There are a bunch of these products on the market now, but at the time the kickstarter project for Cosmonaut was kicked off, I hadn’t seen one that didn’t look cheap yet.

Marco Arment has done us all the favor of reviewing the Cosmonaut – “I’ve tried a lot of iPhone and iPad styli, and I haven’t liked any of them before. But this one’s very different.” and also trying out lots of other products.  I haven’t personally used any other stylus for the iPad, but I agree with Marco’s general sentiments:

• First, that the packaging is excellent, and nice branding to boot.
• Second, that the wide grip of the Cosmonaut is a big advantage – because you really do use it more like a whiteboard marker than a pen or pencil.
• Third, that it is the first product I’ve used that actually feels good when you use it. The rubber tip requires just the right amount of pressure to register with the iPad, and glides effortlessly and smoothly across the surface (even if that surface has the sticky finger prints of your 2yo son on it).
• It exudes quality.  And since we were part of the kickstarter project, we know why.  The creators were meticulous about finding the right materials.  They switched manufacturers more than once.  Getting the right grip, the right aluminum core, and the right tip were all quite time consuming (to, I think, the frustration even of the creators).

Choice quotes from Marco’s review:

There’s no foam anywhere in it. The soft rubber tip gives slightly when pushed, because there’s a small air pocket between it and the solid aluminum core.

and:

It doesn’t feel like a brick of solid plastic writing on glass, and it doesn’t feel like a flimsy sponge on a stick. It feels like a marker, as designed.

I forgot to bring it with me on vacation (I switched laptop bags) and I’m actually annoyed.  I was hoping to try out additional drawing applications. I’ve used penultimate and a few others. But the feature I really want is an “infinite” canvas, or at least a canvas much larger than the screen.  That way I can use rough handwriting with the stylus, then shrink the whole thing down to fit on a screen and reduce to “normal” writing size.  Hopefully I can find an app that does this without too much trouble – it would make a perfect companion to the Evernote note-taking app (though truly, I wish Evernote would just solve both problems… a rare case where you want the app to do two things well, rather than just one).

At the end of the day, the team at Studio Neat worked hard to produce something that looks deceptively simple.  It just looks like a rubber stylus.  But it has the right heft, the right feel, the right size.  It takes a lot of work to produce the right, simple, product.

Good news, you can now buy your own here.

No doubt the Cosmonaut will come in handy for me when I need to sketch an idea or process while attending a meeting.  But my daughter’s first contribution to the blog is a bit of artwork… what surprised me is how much better it is than what she usually sketches with her finger, and the process she used to draw it.  First she colored everything blue, by hand (she could have done this by changing the background color, which I’ve seen her do before… she told me she liked the texture).  Then she drew the clouds and flowers on top… green shoots first, then flowers, then a bit of yellower grass at the bottom.  This is a process that works much better in software than it works with pen and paper, though you can do something similar (with some mess) with crayons.  But try drawing white on top of blue in almost any medium – it doesn’t work too well!  Her work is already better than some of my process drawings!

Related posts:

1. A Short Hiatus, and Some iPhone 4 Thoughts
2. Quick Review of “Social #BPM”
3. Sandy Kemsley’s Review of Metastorm M3