Here's my presentation from bpmNext 2013
Friday, May 10, 2013
Wednesday, April 10, 2013
Gathering, Reviewing and Approving are almost always Collaborative
When we look at the Activities in Business Processes we see that many of them are easily characterized... Information Gathering Activities, Review Activities, Approval Activities, etc.
In the past when I've implemented these things I've come to realize that Gathering, Reviewing and Approving are almost always Collaborative Activities.
When information needs to be gathered, often there are multiple information sources. When proposals are reviewed, there's often collaboration between the reviewers and between the reviewers and the submitters. The same is often true for approvals.
This simple realization points us to a limitation of our BPMN notation...
We tend to draw very explicit loops to indicate Reviewers seeking Clarification from the Submitters:
This diagram captures the reality that Reviewers often seek Clarification, but it often doesn't capture what really happens...
In reality, there are often multiple threads between Reviewers and Submitters executing in parallel. When reviewing a complex proposal, many questions are often raised, and the reviewers seldom have the patience to collect their questions and ask them all at once. Generally, people ask questions as they occur rather than following the nicely structured diagram we've drawn.
In the past when I've implemented these things I've come to realize that Gathering, Reviewing and Approving are almost always Collaborative Activities.
When information needs to be gathered, often there are multiple information sources. When proposals are reviewed, there's often collaboration between the reviewers and between the reviewers and the submitters. The same is often true for approvals.
This simple realization points us to a limitation of our BPMN notation...
We tend to draw very explicit loops to indicate Reviewers seeking Clarification from the Submitters:
This diagram captures the reality that Reviewers often seek Clarification, but it often doesn't capture what really happens...
In reality, there are often multiple threads between Reviewers and Submitters executing in parallel. When reviewing a complex proposal, many questions are often raised, and the reviewers seldom have the patience to collect their questions and ask them all at once. Generally, people ask questions as they occur rather than following the nicely structured diagram we've drawn.
Thursday, April 04, 2013
Moving Back and Jumping Ahead in a Business Process
One of the "easier said than done" aspects of implementing a Business Process solution is building all of the things you'll need if you want to be able to escape the pre-defined flow and "jump around" in your process...
Let's say you are at Activity C in the diagram below and you need to "jump" back to Activity A or "jump" forward to Activity E.
Clients ask me for this capability all the time - so let's think about what we really need to empower our end users to do this...
Jumping around in a process almost always requires extra work, and BPMN actually addresses this when we're "jumping back" with a construct called a Compensation Handler.
From the BPMN spec we get the following description:
So far so good, but BPMN doesn't (to my knowledge) really have constructs that help us with the "jumping forward" scenarios...
Jumping ahead in a process a bit different, but it also (just like moving back) almost always involves "additional work" that's necessary to "jump" to some arbitrary "future" point in the process.
When we define the sequential flow of a process we're in essence defining pre-conditions for any Activity that comes later in the flow. The "real work" that those previous Activities are supposed to perform is presumed to have been done before the later Activity starts.
If we want to Jump Ahead to some arbitrary Activity that would normally occur "later" in our process, then we will have to perform all of the work that would have been performed by the intervening Activities in some other way. We need something sort of like the converse of a "Compensation Activity" that performs all of the necessary "pre-required work" in some sort of streamlined way before you can make the jump.
Stating the obvious... If we want to be able to "jump back" then we have to keep a log of all of the "real work" that's already been done, and have the ability to execute "rollback" services for any of that work.
If we want to be able to "jump forward" then for every "target" activity we will need to have a set of preconditions - "real work" that is expected to be already performed before the activity starts - and access to services that will perform that work.
As I stated earlier in this post... "easier said than done"....but sometimes very necessary.
Let's say you are at Activity C in the diagram below and you need to "jump" back to Activity A or "jump" forward to Activity E.
Jumping around in a process almost always requires extra work, and BPMN actually addresses this when we're "jumping back" with a construct called a Compensation Handler.
From the BPMN spec we get the following description:
Activities perform real work, and in many cases additional work is required to undo that "real work" if a process is cancelled or when there is a need to return to a previous step of a process. Compensation Activities package up that additional work that "undoes" a previously completed Activity."Compensation is concerned with undoing steps that were already successfully completed, because their results and possibly side effects are no longer desired and need to be reversed. If an Activity is still active, it cannot be compensated, but rather needs to be canceled. Cancellation in turn can result in compensation of already successfully completed portions of an active Activity, in case of a Sub-Process."
So far so good, but BPMN doesn't (to my knowledge) really have constructs that help us with the "jumping forward" scenarios...
Jumping ahead in a process a bit different, but it also (just like moving back) almost always involves "additional work" that's necessary to "jump" to some arbitrary "future" point in the process.
When we define the sequential flow of a process we're in essence defining pre-conditions for any Activity that comes later in the flow. The "real work" that those previous Activities are supposed to perform is presumed to have been done before the later Activity starts.
If we want to Jump Ahead to some arbitrary Activity that would normally occur "later" in our process, then we will have to perform all of the work that would have been performed by the intervening Activities in some other way. We need something sort of like the converse of a "Compensation Activity" that performs all of the necessary "pre-required work" in some sort of streamlined way before you can make the jump.
If we want to be able to "jump forward" then for every "target" activity we will need to have a set of preconditions - "real work" that is expected to be already performed before the activity starts - and access to services that will perform that work.
As I stated earlier in this post... "easier said than done"....but sometimes very necessary.
Thursday, March 28, 2013
Business Machines
Our businesses have always been aided by machines... Humans are tool makers, and from the very beginning we applied those tools towards staying alive. As we evolved and prospered, we started doing business with each other, and we started creating and using tools to help our businesses prosper.
Today's computers and software are from the technology perspective infinitely more complex than an abacus - but their purpose is unchanged - Machines help our businesses prosper.
There are many different ways that machines help businesses prosper, including the following:
These correspond nicely to Business Activity Monitoring, Business Analytics, and Business Process Management suites (heavily leveraging Business Rule engines).
It's good to remember that all these "machines" exist to help businesses prosper. Often times we get wrapped up in the machines themselves and lose site of their purpose. We often rank and rate the technological aspects of the machines without actively considering the end impact on the business they are meant to support. It makes little difference if one machine has more cogs and gears than another unless those extra cogs and gears really do make a difference to the business.
Today's computers and software are from the technology perspective infinitely more complex than an abacus - but their purpose is unchanged - Machines help our businesses prosper.
There are many different ways that machines help businesses prosper, including the following:
- Watching the Business
- Analyzing the Business
- Automating the Business
These correspond nicely to Business Activity Monitoring, Business Analytics, and Business Process Management suites (heavily leveraging Business Rule engines).
It's good to remember that all these "machines" exist to help businesses prosper. Often times we get wrapped up in the machines themselves and lose site of their purpose. We often rank and rate the technological aspects of the machines without actively considering the end impact on the business they are meant to support. It makes little difference if one machine has more cogs and gears than another unless those extra cogs and gears really do make a difference to the business.
Thursday, February 28, 2013
The appeal of a platform from the programmer's perspective
I'm sure that many of you have seen the spate of announcements and articles for Firefox OS.
Will it succeed or won't it? That's the question of the day and the same could be said for ChromeOS, Windows RT, Backberry, etc.
To the extent that programmers can influence the success of a platform, I'd like to offer this advice... There are two questions whose answers attract most programmers to a platform:
I do hope that the HTML 5 runs well on lots of devices day comes soon... but for today the answer to the "Can I make a lot of money writing code for Firefox OS?" question is still in doubt. Eventually maybe - Maybe even probably - but that ability to make money has nothing to do with Firefox OS.
Firefox OS better be really cool.
Will it succeed or won't it? That's the question of the day and the same could be said for ChromeOS, Windows RT, Backberry, etc.
To the extent that programmers can influence the success of a platform, I'd like to offer this advice... There are two questions whose answers attract most programmers to a platform:
- Is the platform really cool?
- Can I make a lot of money writing code for that platform?
Number two is much more important than number one over the long run - COBOL ceased to be cool before I was born, but lots of folks still make their likelihoods writing COBOL.
So to the well meaning folks at Firefox OS I just have to ask:
Can I make a lot of money writing code for Firefox OS?Your answer is a bit of a diversion...
Write your apps with HTML 5Apps that run on Firefox OS will run on any HTML 5 device, so you'll make a lot of money because your apps will run on lots of devices just as soon as lots of devices start running HTML 5 efficiently.
I do hope that the HTML 5 runs well on lots of devices day comes soon... but for today the answer to the "Can I make a lot of money writing code for Firefox OS?" question is still in doubt. Eventually maybe - Maybe even probably - but that ability to make money has nothing to do with Firefox OS.
Firefox OS better be really cool.
Tuesday, February 26, 2013
Dealing with the unscripted
I've touched on this topic before, but feel that it bears repeating...
In a sense programmers are like playwrights... We write scripts to guide actors.
When our scripts are run on a production system, just as when a play is performed before a live audience, unscripted things may happen.
It's the responses to those unscripted things that we need to think about.
Unscripted things are really common in the business environment, so those of you who writescripts programs that run in business environments already know what I'm going to say... It's pretty much a fool's errand to "code for everything".
Open up the topic "What can possibly go wrong?" in a requirement gathering session, and your nice clean functional specification will quickly grow from a few pages to several volumes. If you're in the business process domain, using BPMN for modeling, your nice clean process flow diagram quickly begins to resemble a plate of spaghetti.
This increase in complexity by it's very nature is disturbing... but perhaps more disturbing is the likelihood that your solution will become very brittle. The more you handle (if done wrong) the more likely you are to introduce side-effects and conflicts.
This brings to mind this quote from Blaise Pascal:
So what's my point? Our programs execute in the real world, and in the real world unscripted things happen, and we've got to deal with those unscripted things... Don't we?
Drum roll please...
No. We programmers do not have to deal with those unscripted things.
Go into any business office during a normal work day and more than likely you are going to witness a lot of unscripted activity. The lion's share of the events that are taking place are routine - maybe even mundane - but stick around for awhile and you'll likely hear a stressed out or raised voice conversation. Many times those are in reaction to unscripted events.
When the unscripted happens in the business workplace, the Knowledge Workers do exactly what Actors do when the unscripted happens while performing a play... They ad-lib.
A prop crashes to the floor... A quick witted actor responds (while staying in character)... His quick witted comrades play off his response (while staying in character) and together they guide the ad-libbed activity back towards the original script - The play must go on.
Our lesson from this - or at least my take on it - is that programmers don't have to try to deal with unscripted things. Instead, we need to recognize that ultimately it's people who are going to have to deal with the unscripted - not our code.
With this in mind, it becomes a bit more clear that our task is to empower the users - the Knowledge Workers - to deal with the unexpected.
Something bad happens... A Knowledge Worker responds...
What are the tools and the options that the Knowledge Worker needs to examine the situation, intervene to make a change, and get the show back on the road? What do your Knowledge Workers need to effectively ad-lib their lines?
Figure that out and supply those tools to your Knowledge Workers and we'll have made progress.
For those of you who still aren't quite satisfied with leaving others to clean up a mess that you could have avoided... Let's go a bit further.
Instrument the "ad-libbing" tools that you give your Knowledge Workers. Capture the ad-libbed work that's going on... analyze the effectiveness of what transpired... cogitate on how useful it would be to incorporate these responses into your own code... and now you're truly on the path of continuous improvement.
In a sense programmers are like playwrights... We write scripts to guide actors.
When our scripts are run on a production system, just as when a play is performed before a live audience, unscripted things may happen.
It's the responses to those unscripted things that we need to think about.
Unscripted things are really common in the business environment, so those of you who write
Open up the topic "What can possibly go wrong?" in a requirement gathering session, and your nice clean functional specification will quickly grow from a few pages to several volumes. If you're in the business process domain, using BPMN for modeling, your nice clean process flow diagram quickly begins to resemble a plate of spaghetti.
This increase in complexity by it's very nature is disturbing... but perhaps more disturbing is the likelihood that your solution will become very brittle. The more you handle (if done wrong) the more likely you are to introduce side-effects and conflicts.
This brings to mind this quote from Blaise Pascal:
"Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte."
"I have made this longer than usual because I have not had time to make it shorter."I interpret the meaning as "a short but well written script is more accurate than a long rambling one"...
So what's my point? Our programs execute in the real world, and in the real world unscripted things happen, and we've got to deal with those unscripted things... Don't we?
Drum roll please...
No. We programmers do not have to deal with those unscripted things.
Go into any business office during a normal work day and more than likely you are going to witness a lot of unscripted activity. The lion's share of the events that are taking place are routine - maybe even mundane - but stick around for awhile and you'll likely hear a stressed out or raised voice conversation. Many times those are in reaction to unscripted events.
When the unscripted happens in the business workplace, the Knowledge Workers do exactly what Actors do when the unscripted happens while performing a play... They ad-lib.
A prop crashes to the floor... A quick witted actor responds (while staying in character)... His quick witted comrades play off his response (while staying in character) and together they guide the ad-libbed activity back towards the original script - The play must go on.
Our lesson from this - or at least my take on it - is that programmers don't have to try to deal with unscripted things. Instead, we need to recognize that ultimately it's people who are going to have to deal with the unscripted - not our code.
With this in mind, it becomes a bit more clear that our task is to empower the users - the Knowledge Workers - to deal with the unexpected.
Something bad happens... A Knowledge Worker responds...
What are the tools and the options that the Knowledge Worker needs to examine the situation, intervene to make a change, and get the show back on the road? What do your Knowledge Workers need to effectively ad-lib their lines?
Figure that out and supply those tools to your Knowledge Workers and we'll have made progress.
For those of you who still aren't quite satisfied with leaving others to clean up a mess that you could have avoided... Let's go a bit further.
Instrument the "ad-libbing" tools that you give your Knowledge Workers. Capture the ad-libbed work that's going on... analyze the effectiveness of what transpired... cogitate on how useful it would be to incorporate these responses into your own code... and now you're truly on the path of continuous improvement.
Wednesday, February 06, 2013
TypeScript
I'm a bit late to the party, but I'd just like to encourage folks to take a look at TypeScript as a role model for how we can reduce coding illiteracy...
TypeScript is a (brilliant) Microsoft effort to add features to JavaScript that professional programmers miss. They've learned from the mistakes of many other programming languages and have made this effort completely open for all to use... but more importantly they are not introducing yet-another-language that our tooling must support.
TypeScript compiles to JavaScript, much like other languages compile to byte-code or machine-code. This is what makes the effort brilliant - the code is much easier for professional programmers to write and the end-users (you and me) don't have to install anything to run it. As I keep saying - brilliant.
Yes, that does put some limitations on what TypeScript can do, but it's a good trade off. The point of TypeScript is to make it easier to express the "logic" of any program that can be implemented in JavaScript - not to extend what JavaScript can do. Language developers need to keep those two goals separate, and quite frankly they need to concentrate more on making things easier than on increasing functionality.
As an aside - as a person who is more comfortable with C++ and Java-style classes than JavaScript's prototypes, I find the TypeScript playground particularly educational. Examining the generated JavaScript gave me much more insight into how classes can be implemented in JavaScript.
TypeScript is for professional programmers - and apparently is tracking proposals to ECMAScript that are on the horizon. Traditional Programmers rejoice!
As for the Business Programmers - not so much yet. I'd love to see a BusinessScript effort similar to TypeScript for those who primary concern is business logic... and perhaps with Microsoft's background we'll see them moving in that direction. One can only hope...
TypeScript is a (brilliant) Microsoft effort to add features to JavaScript that professional programmers miss. They've learned from the mistakes of many other programming languages and have made this effort completely open for all to use... but more importantly they are not introducing yet-another-language that our tooling must support.
TypeScript compiles to JavaScript, much like other languages compile to byte-code or machine-code. This is what makes the effort brilliant - the code is much easier for professional programmers to write and the end-users (you and me) don't have to install anything to run it. As I keep saying - brilliant.
Yes, that does put some limitations on what TypeScript can do, but it's a good trade off. The point of TypeScript is to make it easier to express the "logic" of any program that can be implemented in JavaScript - not to extend what JavaScript can do. Language developers need to keep those two goals separate, and quite frankly they need to concentrate more on making things easier than on increasing functionality.
As an aside - as a person who is more comfortable with C++ and Java-style classes than JavaScript's prototypes, I find the TypeScript playground particularly educational. Examining the generated JavaScript gave me much more insight into how classes can be implemented in JavaScript.
TypeScript is for professional programmers - and apparently is tracking proposals to ECMAScript that are on the horizon. Traditional Programmers rejoice!
As for the Business Programmers - not so much yet. I'd love to see a BusinessScript effort similar to TypeScript for those who primary concern is business logic... and perhaps with Microsoft's background we'll see them moving in that direction. One can only hope...
Subscribe to:
Posts (Atom)
