Wednesday, September 17, 2014

The Holy Grail of the Remodelled Business App

For many years we've been singing variations of a song about composing applications from reusable building blocks - those blocks may be services a-la SOA or they might be UI widgets, but the idea is the same.  Build things that will be of value for multiple solutions - not just one solution - and you will lower your overall cost of development and maintenance and you will speed (subsequent) application development.

I don't think anyone seriously questions the value of this approach... but I question whether or not it's really the Grail that we seek as business software developers.  It's a step on the path, but not the destination.

The destination, I believe, is hinted at in the following scenario:
John needs an application to help solve a particular business problem. John's kind of a lazy person, so he really doesn't want to build an application from scratch... Instead, he looks around for an application that's pretty close to the application that he needs, and then he copies that application's source as his starting point.  He creates the app that he needs by simply modifying and replacing the portions of the "pretty close" app that don't match what he wants.
For this to work, the "pretty close" application needs to be designed to be easily modified - and the author needs tooling that is optimized for modification - rather than for "from scratch" construction.

Returning to my favorite "software developer is like a home builder" analogy, these are tools for re-modelers and house flippers rather than for new home builders.

This does bring us back to those reusable building blocks.  It's likely that a composite application (one that is composed from building blocks with well thought out interfaces) will be easier to modify than a monolithic application... but only if it's really clear to the remodeler how the blocks have been wired together (so you can rewire them, replace them, etc).

The original structure of the application, just like the original structure of a house, will govern how easy it is to "remodel" the structure.  To be truly successful at reusing our work in the future, we need tools and frameworks that guide us to build "remodel-ability" into our business apps from the very beginning.  That will likely cramp the style of many creative programmers, but it's what we need.

So that's the Holy Grail we seek:  A land where Remodeled Business Apps are the norm.

As always, please don't hesitate to throw rocks at my ramblings if you disagree. That's how we learn.

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.