Friday, August 22, 2014

Recasting BPMN in it's proper place

I had a great discussion this week with a professional frienemy (a BPM enthusiast who works for a competitor) on the wisdom of implementing a process engine that directly executes BPMN (business process modeling notation).  As so often happens during a great exchange of ideas, thoughts that had been rattling around my subconscious for quite some time collided and gelled into a eureka statement:
Directly executing BPMN makes no more nor less sense than directly executing insert your favorite programming language here.
BPMN is a graphical notation for describing the business logic of a process. It's particularly well suited for describing processes that have a sequential flow of process activities.  If you wish to automate a business process, it is a much more productive use of your time to model the process with BPMN than it would be to code your process logic in some computer assembly language.

Let's recast the previous paragraph to substitute the Java programming language as the subject - Java is a high-level programming logic that's particularly well suited for System Programming.  If you wish to create a software application, it is a much more productive use of your time to code the application in Java than it would be to code the application in some computer assembly language.

The norm in Software Engineering is to write applications in the programming language that most closely maps to the problem domain, and then compile the results to the common primitives (assembly language/machine code). This allows authors to use a wide range of programming languages - yet execute all of the resulting programs on the same "engine".

The same should apply to executing business oriented programming languages. Use the language that most closely maps to the problem, and then compile down to the common primitives. This allows authors to use a wide range of tailored business programming languages that can all execute on the same "engine".

My personal (and simplistic) concept of that business engine looks more like an Event Processing Engine than a Workflow Engine...

  1. A Business Event occurs
  2. Logic is executed
  3. Actions are initiated
Processes defined with BPMN map very nicely to to this "engine":
  1. A Process Activity completes (a special type of business event)
  2. The BPMN Process Logic is executed
  3. The "Next" Activity in the Process is initiated
I'm pretty sure just about any practical Business Language that we come up with can be compiled down to these same "event processing" primitives - giving us way more flexibility than a BPMN specific engine.

Please feel free to throw rocks at the holes in my premise... that's how we learn and grow.


Friday, March 28, 2014

The curious tale of the passionate programmer...

Sometimes I question why I am attending a specific conference... The topics that are being covered are familiar, as are many of the presenters, and the pressures and deadlines of my job seem way more pressing than anything I might learn at the conference.

I have never felt this way about bpmNext... It's somewhere between a family reunion and the BPM practioner's version of Woodstock.  I always learn a lot, and I am never disappointed.

This year was just as much fun as last year, and as a special treat I got to meet Tom Baeyens in the flesh.



For those of you who don't know who Tom is, I like to describe him as the guy whose code probably runs more BPM solutions than any other individual.  Tom is the father of both jBPM and Activiti... by far the most pervasive Open Source BPM engines in the wild.  Of course It took a village to craft and polish both engines, but it was Tom's vision and passion that guided those teams.  His influence on BPM is undeniable.

Tom and I have been exchanging emails and forum threads for years, but no matter how well you think you know someone "online", you'll always be a bit surprised when you get to chat with them over a beer or a glass of wine.  Such was the case at bpmNext...

Apologies in advance if I don't recall the details accurately, but Tom told a story of the early days of jBPM that I would love to share...

As a young and passionate programmer, Tom had created a Workflow Engine that he felt had promise.  He'd written some code, and proved that it worked, but in addition to being passionate and young, he was also unfortunately poor.  Great idea, but he needed to pay the bills.  Tom knew he needed to attract the attention of a larger company to realize his dream, and JBoss was the logical choice...

What came next was one of those stories that I just love... I am sure I will muddle the details, but hopefully convey the spirit...

Tom learned of a JBoss training session that was close enough for him to attend... He had no interest in the classes, but this was his chance.  Tom coughed up the 500 Euros fee, packed up his laptop, and attended the conference.  Once there, he lurked in the hallway and stalked the JBoss staff until he was able to pull them aside and show them his project running on his laptop.... The rest is history (aka jBPM).

I've of course romanticized the episode, I love embellishing stories, but to me this is the classic myth towards which all programmers aspire.  Have a great idea, passionately execute the idea, and attract a sponsor to bring your idea to the market.  The modern version of Homer's tales.

Tom's now launched a new commercial effort called Effektif - pronounced "effective" - and I think it's going to be a winner.  Check it out, and dream about what your own passion for programming may accomplish some day.

Monday, January 06, 2014

Chromebook Thoughts

I bought my wife Teri a Chromebook for Christmas... an Acer C720p.  In honesty this was a gift for both of us... Teri is an educator who has wanted to learn more about Chromebooks and I can't resist the temptation to try out everything new.

Total cost was just under $300, bundled with a Chromecast  (another new gadget to play with).

My impression was that it's quite a nice piece of hardware for $300, and it simply works.  Turn it on, log on with your Google account, and it just works.  If there's anything that can be screwed up, I haven't found it yet.

The case is gray plastic, nothing fancy but not cheap feeling... slightly larger than an iPad but still easy to tote around:


The screen's not bad either... and it's touch sensitive.  The Touch screen added $50 to the cost, but I think it's well worth it:

The real test is of course in the answer to the question: "How useful is this thing?"

The answer lies in your need to use "traditional applications"... which certainly differs from person to person and business to business (or school to school).  Chromebooks are almost a no-brainer for schools that have adopted Google Docs - but almost a non-starter for those reliant on legacy applications.

Teri's very positive about her Chromebook as a "student computer" thus far, but did hit one snag already... Here in New Mexico many schools use Net Logo extensively in their curriculum, and thus far it appears that there isn't a cloud-based version available. This is likely true for many other programs teachers rely on, and a stumbling block for wider Chromebook adoption by more schools.

I've seen recent press about Chromebooks really taking off this holiday season - and counter articles deflating those claims a bit.  I have no way of knowing for sure either way - But for me the value for the price of this little Acer machine is terrific. 

Monday, August 26, 2013

The Solution Is Not “More Programmers”

There's a very nice article on FastCompany on Flow Based Programming and the hope that it's resurgence will lead to better things...

I'm not familiar enough with the technique to judge its impact, but I must say that the observations are spot on:
“What we need is not more programmers. What we need is to enable non-programmers to participate in the creation process, not just the ideation process,” says Kenneth Kan, CTO of a company called Pixbi and a recent convert to flow-based programming. “Rather than making us humans think like machines, it's time to make machines to be able to think more like us.” 

Tuesday, August 20, 2013

User Experience Design is the essential BPM skill

I've just read a very good interview with Nathanial Palmer that reaffirms my own observations - the essential skill for BPM is clearly User Experience Design.

In Nathaniel's words:
"They really need to look at BPM through the lens of user experience.  So it is not just necessary to have BPM experts or other process design experts; they also need business functionality and either user experience experts or those that have some keen knowledge of what the user experience needs to be. That way they can drive how the BPM-built application should behave.
From a team standpoint, it is good to still have a cross-functional team, where business leads – somebody who has a business function background or represents a voice of the customer, the “product owner” in the vernacular of agile SCRUM.  It may be the customer in the sense that if there is work to be done by a third party, it is somebody that owns that business application vision. There need to be skill sets for how to realize that– much more of a design-oriented skill set, whether it is someone specifically engaged in user experience design, or otherwise they are an architect that understands design factors, user interactions and the application."
Many of us have learned the hard way that the agility of our BPM solutions are often much more constrained by difficulties encountered in changing the User Interfaces of the solution than they are by changes to the process logic or underlying system integrations.

The mechanics of changing and deploying new screens are often cumbersome and arcane... but beyond the technical concerns lies the larger reality that many of our end users don't deal very well with changes to their software.  Even minor changes to the screens our users deal with can often lead to confusion and require substantial retraining - and that's a cost that our businesses can't afford when change becomes the norm.

Designing a User Experience that can continuously adapt to change without requiring extensive retraining of the process participants is an art that few have mastered... but it has become the crucial design skill for success.

The analogy that comes to mind is that of the relationship between a homeowner who is constantly remodeling their home and their designer.

The architect/designer that is fantastic as designing a new home is certainly a great artist, but when preparing to remodel or to build an addition you need a designer with different skills - You need someone who can produce a design that blends the new remodel or addition into the ambiance of the existing home and which anticipates future needs... and you also need a designer who takes into consideration the needs of the folks who are going to be living in the home while it is being remodeled.

Those types of designers are hard to find, but they are the key players for sustainable BPM programs.




Monday, July 01, 2013

Innovation Hubs for Global Wheels

Here in New Mexico we're very interested in fostering innovation to improve our economy...  I imagine that you could substitute just about any geography for "New Mexico" and make the same statement.  Economic health is a concern for all, and fostering innovation is a proven path for improving economic health.

Our latest local foray into fostering innovation is the UNM/City of Albuquerque Innovation Hub... and with two major National Labs (Los Alamos and Sandia) and easy access to Roswell's advanced top-secret Alien Technologies how could this effort possibly fail?

I tend to think like a programmer... and from that perspective I'd like to make some observations and suggestions about what a innovation hub should be and how it might prosper...

My first observation (which is widely recognized) is that innovative teams are no longer centralized.  Even small startups routinely have team members around the world. Distributed teams are the norm...

So what (if anything) would make a physical Hub attractive to a distributed innovation team? Does having a geographic center for the innovation activity really help? What aspect of innovation is fostered by having people physically in the same room?

Most of us certainly have a gut feeling that being in the same room with our collaborators adds a special energy that fosters innovative thinking. As a member of a huge distributed team I long for the opportunities to meet folks face-to-face, and I always come home energized and inspired...

My second observation is really an opinion...
The Hub, to thrive, must be a Destination...

The first thing a Hub must provide is a really cool destination to visit... Even if the remote folks hardly ever get to physically visit, they really need to want to, and the same goes for your local team members... the trip to the office has to be worth it...

The physical Hub needs to be an attractive and comfortable meeting space with great Feng Shui.  The work space needs to provide fantastic Internet connectivity and meeting rooms (both large and small) with state-of-the-art "Virtual Presence" features.

Outside the Hub, you need a surrounding neighborhood that's special and unique. Nobody is inspired to work in an anonymous building surrounded by acres of anonymous buildings. A pedestrian friendly neighborhood, parks, awe inspiring vistas... Many things can make a space "special", but whatever it is you have to have it.

I'll probably come back to this issue in subsequent posts, but I think I'll close for now.

There's still a need for physical Innovation Hubs (at least I think there is) but it's getting much trickier to understand what that need really is...