tag:blogger.com,1999:blog-251781182024-02-06T22:04:24.208-07:00Thoughtful ProgrammerJohn Reynolds' Blog on Programmers and ProgrammingJohnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.comBlogger229125tag:blogger.com,1999:blog-25178118.post-51101639081616272422017-01-05T10:36:00.001-07:002017-01-05T11:03:22.900-07:00Automating Process Automation<div dir="ltr" style="text-align: left;" trbidi="on">
<blockquote class="tr_bq">
<span style="font-size: large;">Once upon a time business people were excited by the idea that they could use software to make their business processes much more efficient and to be able to quickly adapt those processes to changing conditions...</span></blockquote>
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/bscuPAVymHs/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/bscuPAVymHs?feature=player_embedded" style="clear: right; float: right;" width="320"></iframe></div>
Towards this end, a great number of business oriented programming languages and tools (such as BPMN) were crafted and employed, and to varying extents those efforts were successful, but the realization dawned on the business people that their problems weren't that easy to solve with software alone. Software could indeed automate the execution of almost any business process, but developing that software (even with business-friendly tooling) required a great deal of time consuming collaboration and interaction between Business and IT to get produce useful software solutions.<br />
<br />
At the dawn of 2017, that's pretty much where we are. Businesses have many wonderful Business Rules, BPM and Case Management offerings to choose from, but it's still relatively "hard" to develop and deploy a <i><b>truly useful custom enterprise-scale business solution</b></i>. It's much easier to develop point solutions for business than it once was, but it's still a big challenge to implement solutions for the <b><i>core business processes</i></b> of the <a href="http://fortune.com/fortune500/" target="_blank">Fortune 500</a>.<br />
<br />
Meanwhile, there are indications that a radical paradigm shift is in progress from what we've know as Business Process Management to Cognitive Business Process Management (Cognitive Process Management for short)...<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-16267847218707723792016-03-20T12:24:00.002-06:002016-03-22T13:29:01.410-06:00Why aren't programmer worried about robots taking their jobs?<div dir="ltr" style="text-align: left;" trbidi="on">
There's quite a bit of angst among the workers of the world. The rapid advances and application of Artificial Intelligence powered automation (robots) in businesses has <a href="http://www.bbc.com/news/technology-33327659" target="_blank">eliminated a lot of jobs</a>, and many people are worried that they will be the next to be replaced.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVcBQkoP9TKlOM1N45oF4Q4rN4hhBY4v3bnonLkunOSY4HwVglUU2gCDiFIaPgyt1Opgl1IWmAqnM8wmtzr07JNyV_s_NoPKFEoBoZ3QNvfPKwg88YouDH2b9QyT_b1toMTqLS0A/s1600/20160102_115037_HDR-2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVcBQkoP9TKlOM1N45oF4Q4rN4hhBY4v3bnonLkunOSY4HwVglUU2gCDiFIaPgyt1Opgl1IWmAqnM8wmtzr07JNyV_s_NoPKFEoBoZ3QNvfPKwg88YouDH2b9QyT_b1toMTqLS0A/s640/20160102_115037_HDR-2.jpg" width="452" /></a></div>
There's one notable group of workers that seem <a href="http://www.roboticstrends.com/photo/10_jobs_robots_will_never_replace/9" target="_blank">blissfully unconcerned</a> by the prospect that robots will replace them: Programmers.<br />
<br />
The <a href="http://money.usnews.com/careers/best-jobs/computer-programmer" target="_blank">demand for programmers</a> has never been higher, and it certainly seems to be among the safest-from-replacement-by-robot career paths, but is that likely to continue?<br />
<br />
I certainly can't answer that question, but I can hazard an educated guess based on my own experiences as a programmer...<br />
<br />
To be a good programmer today, you must know a lot about programming languages like <a href="http://www.eweek.com/developer/javascript-most-popular-language-stack-overflow-report.html" target="_blank">Javascript</a>, <a href="https://www.google.com/search?q=apple+swift+programming+guide&oq=Apply+swyft+programm&aqs=chrome.2.69i57j0l5.15508j0j8&sourceid=chrome&ie=UTF-8" target="_blank">Swift</a>, etc. To be able to "code" a website or a mobile app that interacts with services and looks a certain way and interacts with people in a specific manner requires a lot of study and practice.<br />
<br />
That said... Robots are really good at learning things, so it's very likely (in my opinion) that robots will soon know just as much as human programmers do about how to construct the code necessary to produce a website or app that meets<b> a specific set of requirements</b>.<br />
<br />
Fortunately for many programmers, "coding" a set of declarative requirements is actually the easiest part of their job. The hardest part of their jobs can be accurately <a href="http://www.codemag.com/article/0102061" target="_blank">figuring out what the requirements really are</a> in enough detail to be able to "code" them.<br />
<br />
In my work, requirements come from many sources, but most often it's business people telling me what they need. Their business has some problem to solve or some opportunity for growth that software can help, and if they can make the problem or opportunity clear to me, then I can "code" the software that they need.<br />
<br />
The problem is that for many people it is very difficult to explain to someone else <a href="http://www.imdb.com/title/tt0061391/" target="_blank">exactly what it is that they need or want</a>. This is a problem for programmers, because the effectiveness of software in addressing a problem is extremely dependent on the accuracy of the requirements that dictated its creation. Computers execute precise instructions . If those instructions are inaccurate or incomplete, the software won't do what the client wanted... so the requirements that the business people provide have to be incredibly detailed and accurate.<br />
<br />
Unfortunately, many times business people either have difficulty in expressing to a programmer what they need, or they aren't really sure (in detail) what it is that they need. This is why software consulting generally pays more than "coding". Consultants that are good at understanding what clients are asking for, and who can help their clients validate and refine their requirements are a very valuable commodity.<br />
<br />
<blockquote class="tr_bq">
<span style="font-size: large;">My guess is that it's a bigger challenge to teach a robot how to gather software requirements than it is to teach a robot how to implement software requirements.</span></blockquote>
<br />
I think it's quite likely that robots will eventually be able to help business people refine requirements as effectively as software consultants can... essentially providing a "software consultant in a box". How soon this will happen is still just a guess... but perhaps programmers should empathize a bit more with those workers who've already lost out to the robots.<br />
<br />
<br />
<br />
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-34603914699295212142015-07-02T10:52:00.000-06:002015-07-02T11:39:50.117-06:00Rethinking the "I" in IDE (Integrated Design Environment)<div dir="ltr" style="text-align: left;" trbidi="on">
Most developers that I know take it for granted that the right way to develop an application is to use an integrated design environment (IDE), and in response to that expectation most development tool vendors either provide their own IDEs or provide plugins for popular IDEs.<br />
<br />
I've had some recent experiences that are making me doubt the wisdom of the capital "I" in the IDE approach...<br />
<br />
(If you scrutinize <a href="https://www.linkedin.com/in/johnreynolds" target="_blank">my LinkedIn profile</a>, you'll likely figure out which companies I am alluding to in the following examples, but please don't. This post is meant to share insights and lessons-learned, not to provide fodder for competitive bashing).<br />
<h2 style="text-align: left;">
From Thick (Eclipse) to Thin (browser) IDE </h2>
One of the companies that I worked for a few years ago had a great integrated design environment (IDE) for creating and maintaining <a href="https://en.wikipedia.org/wiki/Process-driven_application" target="_blank">process applications</a>. This environment was built on the extremely popular <a href="https://en.wikipedia.org/wiki/Eclipse_(software)" target="_blank">Eclipse IDE</a>, and was itself extremely popular with our developers - but the world changed...<br />
<br />
When we created our IDE, the norm was for developers to install "thick client" IDEs on their own workstations. The installation required a big download, lots of free space on their hard drive, and administrator privileges on the workstation for a successful install. Beyond that, it took several minutes for the installation process to run, but otherwise getting the IDE setup was relatively painless and error free.<br />
<br />
This <a href="https://en.wikipedia.org/wiki/User_experience" target="_blank">user experience</a> (UX) for setting up the IDE was perfectly fine for the personae that we originally targeted - frequent process app developers. These folks spent a lot of time in the IDE, generally had admin privileges on their workstations, and were quite frankly brainwashed by similar download and install procedures from other development tools.<br />
<br />
So far so good, but as our company's product gained traction, we found new personae to address, folks who used the IDE sporadically and infrequently. What we discovered was pretty obvious in hind-sight: After the initial solution was created and deployed, the need to make changes to the solution were very infrequent. When changes need to be made, they could generally be made quickly - assuming that the IDE was already installed on the developer's workstation.<br />
<br />
For the infrequent/sporadic developer persona, the "download and install" UX for our IDE didn't pass muster. The advantages of a thick-client IDE were outweighed by the "download and install" overhead.<br />
<br />
In response to our need to support this new persona, we in product management decided that we needed to replace our thick-client IDE with a thin-client IDE, specifically with a browser-based IDE that would only require the installation of a browser plugin. I'm sure you can anticipate our development teams response:<br />
<blockquote class="tr_bq">
"Great idea, but that will take years to build."</blockquote>
Our IDE provided significant functionality, literally dozens of types of artifacts made up our process solutions, and for each artifact type we had a tailored editor - and many of these editors interacted with related editors. Re-implementing the entire functionality of the Eclipse-based IDE with a new browser-based IDE was a monumental task.<br />
<br />
The solution that we arrived at was a compromise. Instead of trying to re-implement everything in a "big bang" effort, we chose to start with a hybrid approach. We built what we believed to be a <a href="https://en.wikipedia.org/wiki/Minimum_Viable_Product" target="_blank">minimal viable product</a> (MVP) browser-base IDE that provided navigation links to the Eclipse-based IDE. Our hope was that the UX of this hybrid approach would be acceptable to both the frequent and sporadic developers.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a7/Frankenstein%27s_monster_(Boris_Karloff).jpg/170px-Frankenstein%27s_monster_(Boris_Karloff).jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a7/Frankenstein's_monster_(Boris_Karloff).jpg/170px-Frankenstein's_monster_(Boris_Karloff).jpg" /></a></div>
<br />
On the initial release, the UX for most developers was pretty awful. We didn't have quite enough in the "new" thin IDE to minimize the need to switch over to the old "thick" IDE. We didn't have enough in the thin IDE for the infrequent developers, and we'd put some new stuff into the thin IDE that the frequent developers really wanted to utilize. We were pretty quickly able to improve the UX, especially for the infrequent developer persona, but it still feels like a <a href="https://en.wikipedia.org/wiki/Frankenstein" target="_blank">Frankenstein</a> experience for many of the frequent developers.<br />
<br />
It will take years to really provide a delightful design experience for all of the personae that we were targeting.<br />
<br />
<h2 style="text-align: left;">
From Thin (<a href="https://en.wikipedia.org/wiki/Microsoft_Silverlight" target="_blank">Microsoft Silverlight</a>) IDE to Thin (HTML5/JavaScript) IDE</h2>
<br />
Fast forward a few years, and I encountered another variant of "we need to re-implement our IDE". In this case, the company had already made the expensive switch from a thick Eclipse-based IDE to a thin Microsoft Silverlight-based IDE.<br />
<br />
The Silverlight-based IDE is great, but (no surprise if you pay attention to such things) the world changed and the future of Silverlight is not bright. In response to this, we in product management once again decided that we need to re-implement our IDE to remove the Silverlight dependency. The response from the development team?<br />
<blockquote class="tr_bq">
"Great idea, but that will take years to build."</blockquote>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/6/6b/Yogi_Berra_1956.png/200px-Yogi_Berra_1956.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/6b/Yogi_Berra_1956.png/200px-Yogi_Berra_1956.png" width="172" /></a></div>
<div>
<br /></div>
<div>
As <a href="https://en.wikipedia.org/wiki/Yogi_Berra" target="_blank">Yogi Berra</a> might have said: "It's <span style="background-color: white; color: #252525; font-family: sans-serif; font-size: 14px; line-height: 22.3999996185303px;"><a href="https://en.wikipedia.org/wiki/D%C3%A9j%C3%A0_vu" target="_blank">déjà vu</a></span> all over again".</div>
<div>
<br /></div>
<h2 style="text-align: left;">
There must be a better way</h2>
<div>
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/7/7f/James_Doohan_Scotty_Star_Trek.JPG/250px-James_Doohan_Scotty_Star_Trek.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://upload.wikimedia.org/wikipedia/commons/thumb/7/7f/James_Doohan_Scotty_Star_Trek.JPG/250px-James_Doohan_Scotty_Star_Trek.JPG" width="159" /></a>Twice burned. As <a href="https://en.wikipedia.org/wiki/Scotty_(Star_Trek)" target="_blank">Scotty</a> would scold: "Fool me once, shame on you. Fool me twice, shame on me." </div>
<div>
<br /></div>
<div>
I won't pretend to have a solution for this conundrum. It's a fact of our industry that technology, particularly user interface (UI) technology, changes frequently. The UX of our products is the single most important factor in the success of our products, so we have to incorporate the latest UI improvements or our products will slowly die. I get that.</div>
<div>
<br /></div>
<div>
What I don't accept is to continue to implement IDEs in the same old way. There are a lot of great new IDEs out there, such as <a href="https://c9.io/" target="_blank">Cloud 9</a>, <a href="https://code.visualstudio.com/" target="_blank">Visual Studio Code</a>, and <a href="https://www.google.com/webdesigner/" target="_blank">Google Web Designer</a> - but I fear they are repeating an inherent flaw in reasoning:</div>
<blockquote class="tr_bq">
Tight integration (the "I" in IDE) will inevitably lead to expensive (in terms of effort and time) re-implementation.</blockquote>
<h2 style="text-align: left;">
Rethinking the "I" in IDE</h2>
So let's take a trip back in time and review why IDEs were created in the first place... IDEs were created to increase developer productivity and to improve the user experience for developers.<br />
<br />
Prior to IDEs the UX for developers was pretty horrendous and time consuming for many. Not to knock the extreme power that <a href="https://en.wikipedia.org/wiki/Command-line_interface" target="_blank">command-line</a> utilities can provide, in the pre-IDE world the onus was on the developer to switch between tools to create artifacts and keep the elements of a solution in sync with each other. Integrating all of these tools into a common framework provided a much better UX and made developers much more productive.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a4/Knife_fork_and_spoon.svg/83px-Knife_fork_and_spoon.svg.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a4/Knife_fork_and_spoon.svg/83px-Knife_fork_and_spoon.svg.png" /></a></div>
Designing tools so that they work well with other tools is a good thing - A very good thing. Of equal or more importance is to design tools that do one thing very, very well.<br />
<div>
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Titanium_spork_Horizontal.png/120px-Titanium_spork_Horizontal.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Titanium_spork_Horizontal.png/120px-Titanium_spork_Horizontal.png" /></a>Tools that try to do too many things are often not very useful for anything.</div>
<div>
<br /></div>
<div>
A good starting analogy for an IDE is a tool box. You need a box in which to store your tools, and it would be great if the box also helps you organize those tools so you can get to them when you need them.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/2/2a/Clean_House_In_Your_Tool_Box_-_NARA_-_533971.tif/lossy-page1-120px-Clean_House_In_Your_Tool_Box_-_NARA_-_533971.tif.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://upload.wikimedia.org/wikipedia/commons/thumb/2/2a/Clean_House_In_Your_Tool_Box_-_NARA_-_533971.tif/lossy-page1-120px-Clean_House_In_Your_Tool_Box_-_NARA_-_533971.tif.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Analogies always break down at some point - but I think this is a good one. An IDE is there to help you find your tools, and those tools are designed to complement each other to do things that the individuals tools cannot do themselves.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
I fear that traditional IDEs have unwittingly fallen into the "<a href="https://en.wikipedia.org/wiki/Swiss_Army_knife" target="_blank">Swiss Army Knife</a>" trap:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/d/d5/Swiss_army_similar_knife(top).jpg/120px-Swiss_army_similar_knife(top).jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://upload.wikimedia.org/wikipedia/commons/thumb/d/d5/Swiss_army_similar_knife(top).jpg/120px-Swiss_army_similar_knife(top).jpg" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
An inherent flaw of the Swiss Army Knife is the need for each tool to conform to the constraints of the handle. This impacts the utility of each tool, but that's not really the concern I'm trying to address so I'm going to have to pose a "not very likely" question:</div>
<blockquote class="tr_bq" style="clear: both; text-align: left;">
What would the impact be on the blades and tools of a Swiss Army Knife if you radically changed the handle?</blockquote>
If you radically changed the handle of a Swiss Army Knife, you'd have to re-engineer all of the blades and tools. That's essentially what happened when we found it necessary to re-implement our IDEs. The tools within the IDE were tightly integrated with the IDE. They could not function on their own.<br />
<br />
I think understanding this dependency is the key to finding a solution to the "we have to re-implement our IDE" conundrum. We've got to develop tools that work just fine on their own, but with interfaces that allow them to be managed by our IDE (perhaps we should use the abbreviation iDE instead).<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjy6Ri_wBSULuNzR623024195n3q-0qkZSeN9tmQP-l_aaoiCN1uMT4xWecOu4K_lmxVKxmHtEBMUd7YX0Q4jaGrLIk51QN5gGDHEZ1eaHbtu1lKga7CCTl6NeK7x9BCJp5ECuzoA/s1600/IFFT.JPG" imageanchor="1" style="clear: left; display: inline !important; float: left; margin-bottom: 1em; margin-right: 1em; text-align: center;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjy6Ri_wBSULuNzR623024195n3q-0qkZSeN9tmQP-l_aaoiCN1uMT4xWecOu4K_lmxVKxmHtEBMUd7YX0Q4jaGrLIk51QN5gGDHEZ1eaHbtu1lKga7CCTl6NeK7x9BCJp5ECuzoA/s200/IFFT.JPG" width="140" /></a>I found a really good poster child analogy for this approach, <a href="https://ifttt.com/recipes" target="_blank">IFFT</a> (If This Then That). This is a pretty nifty service that lets you get information from one service and use that information to invoke an action on another service. For example, if you receive an email (in gmail) with specific characteristics, IFFT will pass that information to Evernote to store it.<br />
<br />
IFFT is in a very loose sense an IDE because it combines multiple tools in an integrated platform that allows you to create a solution that the individual tools could not implement on their own. Obviously this isn't even close to the functionality that a "real" developer needs, but it's a great start.<br />
<br />
Our iDEs need to be more like this. Each tool should be stand alone (like an App), and provide APIs that allows the tool to be externally managed. The iDE provides that management.<br />
<br />
Admittedly, the UX for the developers with an iDE might not be as delightful as the experience that they've come to expect from their IDE. It won't be as easy to come up with a delightful experience in a loosely coupled experience as it was to delight folks with a tightly coupled experience. That said, I think it's pretty clear that we have to try, or the need to re-implement our IDEs every few years will continue to drag us down.<br />
<br />
Thanks to all of my colleagues who've helped me come to this realization - You know who you are. And to all those who've been kind enough to read my ramblings, please let me know what you think.<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
</div>
</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-44050982940659952142015-03-26T14:39:00.000-06:002015-03-26T14:47:05.575-06:00Business Process Performance and Operator Productivity<div dir="ltr" style="text-align: left;" trbidi="on">
I have recently been having some very good discussions with my colleagues regarding the subtle differences between improving the performance of a Business Process and improving the performance of an Operator...<br />
<br />
Let me introduce a scenario that will hopefully clue you in on what we've been discussing...<br />
<br />
<blockquote class="tr_bq">
<i><b>John</b></i> has filled out a <i><b>Loan Application</b></i> form, and mails it to <i><b>SomeInsuranceCompany</b></i>. (Yes, John is old fashioned and is using paper... You'd be surprised how many important business transactions still start with paper.) </blockquote>
<blockquote class="tr_bq">
When <b><i>John</i></b>'s <b><i>Loan Application</i></b> arrives in the mail room at <b><i>SomeInsuranceCompany</i></b>, it is immediately scanned in, and the information that <b><i>John</i></b> wrote on the form is extracted from the image via a number of miraculous (and patented) marvels of technology. </blockquote>
<blockquote class="tr_bq">
The technology for extracting actionable data from images is quite good, but there are still things that the computer can't figure out. Fortunately, people can sometimes extract information from images that computers can't. For example, people are generally able to decipher bad handwriting better than computers (that's the premise for <a href="http://en.wikipedia.org/wiki/CAPTCHA" target="_blank">captcha</a> too). </blockquote>
<blockquote class="tr_bq">
<b><i>Scott</i></b> works for <b><i>SomeInsuranceCompany</i></b> in the team of people who deal with all of the forms that the aforementioned miraculous marvels of technology can't figure out. <b><i>Scott</i></b>'s team is there to take a look at the images of the problematic <b><i>Loan Application</i></b>s and try to make sense of them. The alternative would be to reject these applications, and that's something that <b><i>SomeInsuranceCompany</i></b> wants to avoid. </blockquote>
<blockquote class="tr_bq">
<b><i>SomeInsuranceCompany</i></b> wants <b><i>Scott</i></b> to be as productive as possible. They want to maximize the number of <b><i>Loan Application</i></b> images that <b><i>Scott</i></b> can process during his shift. This is a classic problem on how to improve operator productivity. </blockquote>
<blockquote class="tr_bq">
Once the data has been extracted from the images, the <b><i>Loan Application</i></b>s are routed for review and approval through a number of activities. <b><i>SomeInsuranceCompany</i></b> wants to minimize the time that it takes to let <b><i>John</i></b> know whether or not his <b><i>Loan Application</i></b> has been approved. This is precisely the sort of scenario that Business Process Management deals with.</blockquote>
<br />
I hope that you are still with me... that was a pretty big setup, but probably necessary before I ask this question:<br />
<br />
<div style="text-align: center;">
<span style="font-size: large;">Would the use of BPMN help you improve <b><i>Scott</i></b>'s productivity?</span></div>
<br />
<br />
To me, this question is rhetorical... The answer is no. BPMN is not very helpful in improving the productivity of an operator performing a single activity. It was not designed for that use.<br />
<br />
Scott's productivity will more likely be improved by analyzing his User Experience with the tools that he uses to review the images. We need to track his eye movements, number of key strokes and mouse clicks, etc. Perhaps there are process improvements that can help reduce his fatigue over the course of the day, but it's still mostly a matter of "Eyes and Fingers" (as a colleague of mine is fond of saying).<br />
<br />
So what's my point?<br />
<br />
BPMN is a great tool to have in your toolkit, but it's not the best tool (or even a good tool) for all of the things you need to do to improve your business operations. A purpose built tool for the job at hand will always serve you better, so fill your toolkit with the best tools you can find for the work that you need to do.<br />
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-64891648742125530272014-09-17T15:11:00.000-06:002014-09-17T15:11:30.796-06:00The Holy Grail of the Remodelled Business App<div dir="ltr" style="text-align: left;" trbidi="on">
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 <a href="http://en.wikipedia.org/wiki/Service-oriented_architecture" target="_blank">SOA</a> 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.<br />
<br />
I don't think anyone seriously questions the value of this approach... but I question whether or not it's really <a href="http://www.heroofcamelot.com/legend/holy-grail" target="_blank">the Grail that we seek</a> as business software developers. It's a step on the path, but not the destination.<br />
<br />
The destination, I believe, is hinted at in the following scenario:<br />
<blockquote class="tr_bq">
<i>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.</i></blockquote>
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. <br />
<br />
Returning to my favorite "<a href="http://thoughtfulprogrammer.blogspot.com/2011/06/builders-and-business-people.html" target="_blank">software developer is like a home builder</a>" analogy, these are tools for re-modelers and <a href="http://home.howstuffworks.com/real-estate/selling-home/house-flipping.htm" target="_blank">house flippers</a> rather than for new home builders.<br />
<br />
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).<br />
<br />
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.<br />
<br />
So that's the Holy Grail we seek: A land where Remodeled Business Apps are the norm.<br />
<br />
As always, please don't hesitate to throw rocks at my ramblings if you disagree. That's how we learn.</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-36339705126410301632014-08-22T10:53:00.001-06:002014-08-22T10:53:54.507-06:00Recasting BPMN in it's proper place<div dir="ltr" style="text-align: left;" trbidi="on">
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 <a href="http://www.bpmn.org/" target="_blank">BPMN</a> (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:<br />
<blockquote class="tr_bq">
Directly executing BPMN makes no more nor less sense than directly executing <i><u>insert your favorite programming language here</u></i>.</blockquote>
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 <a href="http://www.processmodeling.info/posts/highlights-from-bpmn-2-0-activity-types/" target="_blank">process activities</a>. 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 <a href="http://en.wikipedia.org/wiki/Assembly_language" target="_blank">assembly language</a>.<br />
<br />
Let's recast the previous paragraph to substitute the <a href="http://en.wikipedia.org/wiki/Java_(programming_language)" target="_blank">Java programming language</a> 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.<br />
<br />
The norm in Software Engineering is to write applications in the programming language that most closely maps to the problem domain, and then <a href="http://en.wikipedia.org/wiki/Compiler" target="_blank">compile</a> 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".<br />
<br />
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".<br />
<br />
My personal (and simplistic) concept of that business engine looks more like an Event Processing Engine than a Workflow Engine...<br />
<br />
<ol style="text-align: left;">
<li>A Business Event occurs</li>
<li>Logic is executed</li>
<li>Actions are initiated</li>
</ol>
<div>
Processes defined with BPMN map very nicely to to this "engine":</div>
<div>
<ol style="text-align: left;">
<li>A Process Activity completes (a special type of business event)</li>
<li>The BPMN Process Logic is executed</li>
<li>The "Next" Activity in the Process is initiated</li>
</ol>
<div>
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.</div>
</div>
<div>
<br /></div>
<div>
Please feel free to throw rocks at the holes in my premise... that's how we learn and grow.</div>
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-65387871081318025362014-06-20T10:27:00.001-06:002014-06-20T10:27:20.276-06:00bpmNext 2014 videos are live<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="https://www.youtube.com/watch?v=QNuPUDJ9HZY">My presentation with Amy Dickson</a></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-91928767951830829002014-03-28T09:04:00.002-06:002014-03-31T18:05:17.696-06:00The curious tale of the passionate programmer...<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">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.</span><br />
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
I have never felt this way about <a href="http://www.bpmnext.com/">bpmNext</a>... It's somewhere between a family reunion and the BPM practioner's version of <a href="http://en.wikipedia.org/wiki/Woodstock">Woodstock</a>. I always learn a lot, and I am never disappointed.</div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
This year was just as much fun as last year, and as a special treat I got to meet <a href="https://www.linkedin.com/profile/view?id=10078420&locale=en_US&trk=tyah&trkInfo=tarId%3A1396018632413%2Ctas%3Atom%20baeyens%2Cidx%3A1-1-1">Tom Baeyens</a> in the flesh.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/--PSkmiTKek0/Uzh-bCcrOeI/AAAAAAAADqw/zdDeFQEED1M/d/DSC08801.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/--PSkmiTKek0/Uzh-bCcrOeI/AAAAAAAADqw/zdDeFQEED1M/d/DSC08801.JPG" height="213" width="320" /></a></div>
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
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 <a href="http://activiti.org/">Activiti</a>... 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.</div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">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...</span><br />
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
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...</div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
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...</div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
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...</div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
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 <a href="https://www.jboss.org/jbpm">jBPM</a>).</div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
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.</div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.727272033691406px;">
Tom's now launched a new commercial effort called <a href="http://www.effektif.com/">Effektif</a> - 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.</div>
</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-75293040610024444632014-01-06T08:00:00.002-07:002014-01-06T08:00:24.727-07:00Chromebook Thoughts<div dir="ltr" style="text-align: left;" trbidi="on">
I bought my wife Teri a Chromebook for Christmas... an <a href="http://us.acer.com/ac/en/US/press/2013/72521">Acer C720p</a>. In honesty this was a gift for both of us... <a href="http://www.linkedin.com/in/terigallegosreynolds">Teri is an educator</a> who has wanted to learn more about Chromebooks and I can't resist the temptation to try out everything new.<br />
<br />
Total cost was just under $300, bundled with a <a href="http://www.google.com/intl/en/chrome/devices/chromecast/?gclid=CLX_5pyE6LsCFcpDMgodHFgA9w">Chromecast</a> (another new gadget to play with).<br />
<br />
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.<br />
<br />
The case is gray plastic, nothing fancy but not cheap feeling... slightly larger than an iPad but still easy to tote around:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsmoW3SJ1hQbMRxkOScyHjE_Xhz8Y79RKrnIoH55GccKJK8YwcaZblUSytUk7JcaiH88IswbCc8TPNl5hysH4AXuB-NOEStZvRwPcZrV2mahQNHsWNFHmQpS_Pk7KgfoIp-905lg/s1600/acer3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="222" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsmoW3SJ1hQbMRxkOScyHjE_Xhz8Y79RKrnIoH55GccKJK8YwcaZblUSytUk7JcaiH88IswbCc8TPNl5hysH4AXuB-NOEStZvRwPcZrV2mahQNHsWNFHmQpS_Pk7KgfoIp-905lg/s320/acer3.png" width="320" /></a></div>
<br />
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:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibxQR4Y0W1XHqSw31xywiRgnxzvMSCxq23CraWN-nRigfIdl5FeU6OerX0ba9OwFD_s_rJtdpWCZZYpR5gUo4mGb7dGWuZlbotHA2X_oxOIDVi792_cxRxDgV9NIEk1Q-aZFHHUA/s1600/Acer2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibxQR4Y0W1XHqSw31xywiRgnxzvMSCxq23CraWN-nRigfIdl5FeU6OerX0ba9OwFD_s_rJtdpWCZZYpR5gUo4mGb7dGWuZlbotHA2X_oxOIDVi792_cxRxDgV9NIEk1Q-aZFHHUA/s320/Acer2.png" width="319" /></a></div>
<br />
The real test is of course in the answer to the question: "How useful is this thing?"<br />
<br />
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 <a href="http://www.google.com/enterprise/apps/education/#utm_campaign=en&utm_source=en-ha-na-us-bk&utm_medium=ha&utm_term=%2Bgoogle%20%2Bdocs%20for%20%2Beducation">Google Docs</a> - but almost a non-starter for those reliant on legacy applications.<br />
<br />
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 <a href="http://ccl.northwestern.edu/netlogo/">Net Logo</a> 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.<br />
<br />
I've seen recent press about Chromebooks really <a href="http://venturebeat.com/2013/12/28/chromebook-sales-surge-during-holidays-raising-big-questions-for-microsoft/">taking off this holiday season</a> - and counter articles <a href="http://www.iclarified.com/37167/google-chromebook-sales-rocket-past-apple-macbook-sales-in-2013-chart">deflating those claims</a> 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. </div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-31713412266566961492013-08-26T10:28:00.000-06:002013-08-26T10:28:17.643-06:00The Solution Is Not “More Programmers”<div dir="ltr" style="text-align: left;" trbidi="on">
There's a very nice article on FastCompany on <a href="http://www.fastcolabs.com/3016289/how-an-arcane-coding-method-from-1970s-banking-software-could-save-the-sanity-of-web-develop">Flow Based Programming</a> and the hope that it's resurgence will lead to better things...<br />
<br />
I'm not familiar enough with the technique to judge its impact, but I must say that the observations are spot on:<br />
<blockquote class="tr_bq">
<span style="background-color: white; color: #222222; font-family: Colfax, Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px;">“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.”</span> </blockquote>
</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-79434941469600721432013-08-20T08:27:00.000-06:002013-08-20T14:36:35.191-06:00User Experience Design is the essential BPM skill<div dir="ltr" style="text-align: left;" trbidi="on">
I've just read a very good <a href="http://data-informed.com/what-big-data-means-to-bpm-more-event-sensors-process-simulations/">interview with Nathanial Palmer</a> that reaffirms my own observations - the essential skill for BPM is clearly User Experience Design.<br />
<br />
In Nathaniel's words:<br />
<blockquote class="tr_bq" style="text-align: left;">
<div style="background-color: white; border: 0px; color: #141414; font-family: 'Helvetica Neue', HelveticaNeue, Helvetica, Arial, 'Lucida Grande', sans-serif; line-height: 19px; margin-bottom: 18px; padding: 0px; vertical-align: baseline;">
<span style="font-size: x-large;">"</span><span style="color: #555555; line-height: 18px;"><i>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.</i></span></div>
</blockquote>
<blockquote class="tr_bq" style="text-align: left;">
<div style="background-color: white; border: 0px; color: #141414; font-family: 'Helvetica Neue', HelveticaNeue, Helvetica, Arial, 'Lucida Grande', sans-serif; line-height: 19px; margin-bottom: 18px; padding: 0px; vertical-align: baseline;">
<span style="color: #555555; line-height: 18px;"><i>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.</i></span><span style="font-size: x-large;">"</span></div>
</blockquote>
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
The analogy that comes to mind is that of the relationship between a homeowner who is constantly remodeling their home and their designer.<br />
<br />
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.<br />
<br />
Those types of designers are hard to find, but they are the key players for sustainable BPM programs.<br />
<br />
<br />
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-27701614486497369322013-07-01T08:53:00.000-06:002013-07-01T08:56:07.218-06:00Innovation Hubs for Global Wheels<div dir="ltr" style="text-align: left;" trbidi="on">
Here in <a href="http://www.newmexico.gov/">New Mexico</a> 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.<br />
<br />
Our latest local foray into fostering innovation is the <a href="https://stc.unm.edu/">UNM</a>/City of Albuquerque <a href="https://stc.unm.edu/news/news.php?newsid=421">Innovation Hub</a>... and with two major National Labs (<a href="http://www.lanl.gov/index.php">Los Alamos</a> and <a href="http://www.sandia.gov/">Sandia</a>) and easy access to <a href="http://www.roswell-nm.gov/">Roswell</a>'s advanced top-secret <a href="http://www.roswellufomuseum.com/">Alien Technologies</a> how could this effort possibly fail?<br />
<br />
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...<br />
<br />
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...<br />
<br />
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?<br />
<br />
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...<br />
<br />
My second observation is really an opinion...<br />
The Hub, to thrive, must be a Destination...<br />
<br />
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...<br />
<br />
The physical Hub needs to be an attractive and comfortable meeting space with great <a href="http://en.wikipedia.org/wiki/Feng_shui">Feng Shui</a>. The work space needs to provide fantastic Internet connectivity and meeting rooms (both large and small) with state-of-the-art "Virtual Presence" features.<br />
<br />
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.<br />
<br />
I'll probably come back to this issue in subsequent posts, but I think I'll close for now.<br />
<br />
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... </div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-69981905329323249762013-05-10T17:48:00.002-06:002013-05-10T17:48:40.241-06:00Thoughts on Data Centric BPM at bpmNext 2013<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
Here's my presentation from bpmNext 2013</div>
<script src="https://www.brighttalk.com/clients/js/embed/embed.js" type="text/javascript"></script>
<object class="BrightTALKEmbed" height="507" width="656">
<param name="player" value="webcast_player_widescreen"/>
<param name="domain" value="https://www.brighttalk.com"/>
<param name="channelid" value="9291"/>
<param name="communicationid" value="74157"/>
<param name="autoStart" value="false"/>
<param name="theme" value=""/>
</object></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-78015098280034366502013-04-10T10:10:00.001-06:002013-04-10T10:10:31.971-06:00Gathering, Reviewing and Approving are almost always Collaborative<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
In the past when I've implemented these things I've come to realize that Gathering, Reviewing and Approving are almost always Collaborative Activities.<br />
<br />
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.<br />
<br />
This simple realization points us to a limitation of our BPMN notation...<br />
<br />
We tend to draw very explicit loops to indicate Reviewers seeking Clarification from the Submitters:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgAGsiJzLY0t3WVgz3QvzRyTxI87nGdXWtxIhPIZ959QxW597xbdnoKkX9hQoukHbUsC-ABVdZtwwmjQaus3-Kg061kbxt8sFMqIBHtSSU1FGTBtfe3ZXOPXEWBlOBisgt3824kog/s1600/ProposalReview.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgAGsiJzLY0t3WVgz3QvzRyTxI87nGdXWtxIhPIZ959QxW597xbdnoKkX9hQoukHbUsC-ABVdZtwwmjQaus3-Kg061kbxt8sFMqIBHtSSU1FGTBtfe3ZXOPXEWBlOBisgt3824kog/s1600/ProposalReview.JPG" /></a></div>
<br />
This diagram captures the reality that Reviewers often seek Clarification, but it often doesn't capture what really happens...<br />
<br />
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.<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com4tag:blogger.com,1999:blog-25178118.post-56314643614617482002013-04-04T11:22:00.000-06:002013-04-04T12:02:02.277-06:00Moving Back and Jumping Ahead in a Business Process<div dir="ltr" style="text-align: left;" trbidi="on">
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...<br />
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.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyPXJ5Ej4SGbHhkrAn0R__x1wEvO_boIo8aIA6y1P2JOQQoOWBTRFs5YGszJApgNrtNYNk24Mpol4dXxBQWN3W4dougAwU0nWmlDlDpFnSVegEj6DskhVGxE-uCJJVIe4fyhS8Kg/s1600/ProcessJumpSimple.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="139" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyPXJ5Ej4SGbHhkrAn0R__x1wEvO_boIo8aIA6y1P2JOQQoOWBTRFs5YGszJApgNrtNYNk24Mpol4dXxBQWN3W4dougAwU0nWmlDlDpFnSVegEj6DskhVGxE-uCJJVIe4fyhS8Kg/s640/ProcessJumpSimple.JPG" width="640" /></a></div>
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...<br />
<br />
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.<br />
<br />
From the BPMN spec we get the following description:<br />
<blockquote class="tr_bq">
<blockquote class="tr_bq">
"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."</blockquote>
</blockquote>
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.<br />
<br />
So far so good, but BPMN doesn't (to my knowledge) really have constructs that help us with the "jumping forward" scenarios...<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtAShCJ-aIImvWSTJJ-fSVabN3DXC5U2JEJVnU-ymHTQ1iJFXLwZsL1IsAKCt0Xpoa8S2c2vgqrx25vD379cIx5uzXh4SuKFFBs7o0s_a6J8tYgypMtP0nJoPOY83b4-zuyIeEZQ/s1600/ProcessJump.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="214" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtAShCJ-aIImvWSTJJ-fSVabN3DXC5U2JEJVnU-ymHTQ1iJFXLwZsL1IsAKCt0Xpoa8S2c2vgqrx25vD379cIx5uzXh4SuKFFBs7o0s_a6J8tYgypMtP0nJoPOY83b4-zuyIeEZQ/s640/ProcessJump.JPG" width="640" /></a></div>
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.<br />
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.<br />
<br />
As I stated earlier in this post... "easier said than done"....but sometimes very necessary.<br />
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-30377384326301526442013-03-28T09:15:00.000-06:002013-03-28T09:15:21.712-06:00Business Machines<div dir="ltr" style="text-align: left;" trbidi="on">
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. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://upload.wikimedia.org/wikipedia/commons/e/ea/Boulier1.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="http://upload.wikimedia.org/wikipedia/commons/e/ea/Boulier1.JPG" width="320" /></a></div>
<br />
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.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
There are many different ways that machines help businesses prosper, including the following:<br />
<br />
<ul style="text-align: left;">
<li>Watching the Business</li>
<li>Analyzing the Business</li>
<li>Automating the Business</li>
</ul>
<br />
These correspond nicely to <a href="http://en.wikipedia.org/wiki/Business_activity_monitoring">Business Activity Monitoring</a>, <a href="http://en.wikipedia.org/wiki/Business_analytics">Business Analytics</a>, and <a href="http://en.wikipedia.org/wiki/Business_process_management">Business Process Management</a> suites (heavily leveraging <a href="http://en.wikipedia.org/wiki/Business_rules">Business Rule</a> engines).<br />
<br />
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.</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-38200832424400969492013-02-28T10:25:00.000-07:002013-02-28T15:29:48.022-07:00The appeal of a platform from the programmer's perspective<div dir="ltr" style="text-align: left;" trbidi="on">
I'm sure that many of you have seen the spate of announcements and articles for <a href="http://www.mozilla.org/en-US/firefox/partners/#">Firefox OS</a>.<br />
<br />
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.<br />
<br />
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:<br />
<br />
<ol style="text-align: left;">
<li>Is the platform really cool?</li>
<li>Can I make a lot of money writing code for that platform?</li>
</ol>
<div>
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.</div>
<div>
<br /></div>
<div>
So to the well meaning folks at Firefox OS I just have to ask:</div>
<blockquote class="tr_bq">
Can I make a lot of money writing code for Firefox OS?</blockquote>
Your answer is a bit of a diversion...<br />
<blockquote class="tr_bq">
Write your apps with HTML 5</blockquote>
Apps 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 <i>just as soon as lots of devices start running HTML 5 efficiently</i>. <br />
<br />
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.<br />
<br />
Firefox OS better be really cool.<br />
<blockquote class="tr_bq">
</blockquote>
</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-14917784350222783962013-02-26T08:45:00.001-07:002013-02-28T09:10:45.784-07:00Dealing with the unscripted<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://thoughtfulprogrammer.blogspot.com/2012/10/ad-libbed-activities.html">I've touched on this topic before</a>, but feel that it bears repeating...<br />
<br />
In a sense programmers are like playwrights... We write scripts to guide actors.<br />
When our scripts are run on a production system, just as when a play is performed before a live audience, unscripted things may happen.<br />
<br />
It's the responses to those unscripted things that we need to think about.<br />
<br />
Unscripted things are really common in the business environment, so those of you who write <strike>scripts</strike> 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".<br />
<br />
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.<br />
<br />
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.<br />
<br />
This brings to mind this <a href="http://quoteinvestigator.com/2012/04/28/shorter-letter/">quote from Blaise Pascal</a>:<br />
<blockquote class="tr_bq">
"<span style="background-color: white; color: #373737; font-family: Georgia, 'Bitstream Charter', serif; font-size: 15px; font-style: italic; line-height: 24px;">Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.</span>"</blockquote>
<blockquote class="tr_bq">
"<span style="background-color: white; color: #373737; font-family: Georgia, 'Bitstream Charter', serif; font-size: 15px; font-style: italic; line-height: 24px;">I have made this longer than usual because I have not had time to make it shorter.</span>" </blockquote>
I interpret the meaning as "a short but well written script is more accurate than a long rambling one"...<br />
<br />
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?<br />
<br />
Drum roll please...<br />
<br />
No. We programmers do not have to deal with those unscripted things.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 - <a href="http://en.wikipedia.org/wiki/The_show_must_go_on">The play must go on</a>.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Something bad happens... A Knowledge Worker responds...<br />
<br />
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?<br />
<br />
Figure that out and supply those tools to your Knowledge Workers and we'll have made progress.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com1tag:blogger.com,1999:blog-25178118.post-67968934722924974192013-02-06T08:20:00.000-07:002013-02-06T08:21:14.355-07:00TypeScript<div dir="ltr" style="text-align: left;" trbidi="on">
I'm a bit late to the party, but I'd just like to encourage folks to take a look at <a href="http://www.typescriptlang.org/">TypeScript</a> as a role model for how we can reduce coding illiteracy...<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsNrIIYEuDAUhphLLHmtuXBzSootgy8HcLnf0fWOxYEUWv1gV-fqlPNElt2u2PMk9yEZnlDa7JKt7tn3Ky4IIuckZ-8aBwUxE-MagcqeSZ00JAiSWzDxlsFpOtJ3nT6BE7YwNf9w/s1600/TypeScript.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="253" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsNrIIYEuDAUhphLLHmtuXBzSootgy8HcLnf0fWOxYEUWv1gV-fqlPNElt2u2PMk9yEZnlDa7JKt7tn3Ky4IIuckZ-8aBwUxE-MagcqeSZ00JAiSWzDxlsFpOtJ3nT6BE7YwNf9w/s400/TypeScript.JPG" width="400" /></a></div>
<br />
<br />
TypeScript is for professional programmers - and apparently is tracking proposals to ECMAScript that are on the horizon. Traditional Programmers rejoice!<br />
<br />
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...</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-47793947985154000212013-01-09T09:33:00.003-07:002013-01-09T09:33:38.821-07:00Formula.js<div dir="ltr" style="text-align: left;" trbidi="on">
Just a quick post to highlight the great work that Ishmael Ghalimi and his <a href="http://www.kickstarter.com/projects/936813051/stoic-platform">STOIC</a> crew are doing that will benefit everyone who has ever tried to do any sort of serious accounting math with JavaScript... <a href="http://stoic.com/formula/">Formula.js</a><br />
<br />
Ismael and crew have tackled the obvious task to implement JavaScript functions for all of the spreadsheet functions provided by MicroSoft's Excel (and Google's spreadsheets). It's astounding that these libraries haven't been generally available before - and wonderful that STOIC is releasing them under the MIT license.<br />
<br />
Thanks guys!</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com1tag:blogger.com,1999:blog-25178118.post-35923873929615573792012-12-14T08:56:00.004-07:002012-12-17T12:29:29.866-07:00Praise to the Humble Spreadsheet<div dir="ltr" style="text-align: left;" trbidi="on">
I have been rather obsessed by the idea that normal people ought to be able to learn how to create their own useful programs...<br />
<br />
In my youth (or so I remember) there was a fairly common belief that people would write their own software... Microsoft began as the purveyor of <a href="http://en.wikipedia.org/wiki/Microsoft_BASIC">BASIC</a> (so anybody could program their new-fangled Personal Computers)... Apple's Macs boasted <a href="http://en.wikipedia.org/wiki/HyperCard">HyperCard</a>... Writing your own programs was expected and encouraged.<br />
<br />
Now we have the iPad and its brethren, and we're just supposed to install Apps and play them. Programming is for someone else to do, we are just supposed to play Apps the same way we used to play vinyl records, CDs, etc. Personal Computer replaced by Personal Media (created by someone else) Device.<br />
<br />
But not really.<br />
<br />
Many of the most popular Apps are those which allow folks to create Media, and the closer you look the more it appears that many Apps are heading in the direction of creating (simple) programs involving media and sharing. It's not the overt message of "write your own programs" heralded by BASIC, but the undercurrent is there. People (well, some people) really do want to write their own programs once in awhile.<br />
<br />
If I am right (and I am just arrogant enough to believe that I am right), then the world still needs a Personal Programming Language that mere mortals can learn and use on a semi-regular basis to write their own programs.<br />
<br />
Curious as to whether or not others agree, I started searching for examples without much luck until I stopped searching for <a href="http://www.easyprogramming.net/">Easy Programming</a> (it's a cruel joke to associate C++ with easy anything) and I started searching for <a href="https://www.google.com/search?q=spreadsheet+programming&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a">Spreadsheet Programming</a>. <br />
<br />
Spreadsheets have a proven track record for learn-ability, perhaps not by anyone but certainly by a wide range of people with diverse backgrounds. Any efforts to create (or find) tools for Personal Programming really needs to start with what's been learned from Spreadsheets.<br />
<br />
There really are some great efforts out there to expand on what's been learned from Spreadsheets, and to take them to "the next level" in terms of programming. Here's a partial list for you to look at:<br />
<ul style="text-align: left;">
<li><a href="https://www.smartsheet.com/">Smartsheet</a></li>
<li><a href="http://www.boardwalktech.com/">Boardwalktech</a></li>
<li><a href="http://stoic.com/">STOIC</a></li>
<li><a href="http://www.kdcalc.com/">KDCalc</a></li>
</ul>
<div>
Please let me know of others as you find them.</div>
<br />
<b>Update:</b> Nice articles on <a href="http://web.engr.oregonstate.edu/~erwig/papers/SpreadsheetProgramming_ECSE09.pdf">Spreadsheet Programmng</a> and <a href="ftp://me.oregonstate.edu/pub/burnett/icfp03.excelFunctions.pdf">User Centered Functions</a><br />
<br />
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com3tag:blogger.com,1999:blog-25178118.post-60510237252496715502012-12-05T16:49:00.001-07:002012-12-10T16:24:03.501-07:00What does "Free" software cost?<div dir="ltr" style="text-align: left;" trbidi="on">
What does "Free" software cost?<br />
<br />
My poor mother is probably rolling in her grave that I chose one of the only professions on the face of the planet where most people believe that the fruit of my labors should be free.<br />
<br />
Case in point, my own attitudes when installing apps on my iPad or Android phone... with very few exceptions I only install apps that are "free". If I really like an app, like <a href="https://play.google.com/store/apps/details?id=com.duduapps.craigslistfree&hl=en">Craigslist Mobile</a>, then I will cough up 99 cents for the "pro" version - but that's the exception rather than the rule.<br />
<br />
In contrast, I will happily pony up much more than that for any number of gadgets that connect to my iPad or phone. I plunked down $39 for a zippered case and $19 for a power adapter just the other day without even thinking about it.<br />
<br />
Physical gadgets cost money - Software gadgets are free.<br />
<br />
I blame hardware manufacturers for this sorry state of affairs. Software was something provided for free to get you to buy hardware in the early days - and then it became something that was provided for free to keep your hardware platform from being made irrelevant...<br />
<br />
I also blame programmers for this sorry state of affairs. Software should be Open Source - which means I don't have to pay to use it in my own products.<br />
<br />
So much for blaming others for my own bad behavior - Software is supposed to be free and I just need to stop grousing about it.<br />
<br />
But wait... Software is free (to me), but it's incredibly expensive to write, and if it's cloud-based it's incredibly expensive to host. Who pays for it?<br />
<br />
Interesting question... but increasingly the answer is "People who want to sell you things".<br />
<br />
No surprise there... Those are the same people who pay for the production of TV shows. Advertising revenue is the grease that primes the pump.<br />
<br />
But wait... What are the advertisers paying for?<br />
<br />
On Free TV advertisers are paying for air time, plain and simple. They are paying to broadcast a message to whomever happens to have their set on at a specific time. Annoying but otherwise harmless.<br />
<br />
On Free Software advertisers are paying for targeted ads. They are paying to have their ads aired to users that fit specific profiles. That's a better deal for them - they don't waste time advertising to folks who aren't likely to respond.<br />
<br />
Sounds harmless... but wait... How are they targeting me?<br />
<br />
Ads are targeting by prying into your private affairs. They watch what you watch, they snitch your list of contacts, and they snoop on whatever they can get to on your workstations and online data stores. That's how they learn enough about you to send you targeted ads.<br />
<br />
So now we have an answer to the question I started with...<br />
<br />
What does "Free" software cost? - Your privacy.<br />
<br />
I'm not going to judge whether "Free" is worth it or not, that's up to each individual, but I am going to assert that it's very important that everybody who uses "Free" software should understand this. Understand what's paying for that "Free" software before you use it, and you won't get disappointed or jaded down the road. It's really just a simple economic equation that you need to understand - and with that knowledge you'll be fine.<br />
<br />
So with that in mind - head on over to Facebook and vote on their new <a href="https://www.facebook.com/settings/?tab=privacy">privacy policies</a>. It's your way of helping them understand what you're willing to pay for "Free" software, and it will make both of you happier.<br />
<br />
<b>Update:</b> Too late, <a href="http://www.computerworld.com/s/article/9234561/Vote_ends_on_Facebook_privacy_changes_for_good">the results are in</a>.</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-91503286497345055582012-11-21T08:41:00.000-07:002012-11-21T08:41:49.081-07:00Separation of Concerns or Arbitrary Concerns?<div dir="ltr" style="text-align: left;" trbidi="on">
<h3 style="text-align: left;">
"But BPM doesn't do that!"</h3>
<div>
Replace BPM with "Case" or "Rules" or any of the other fiefdoms of Business Software and you've probably heard this phrase...</div>
<div>
<br /></div>
<div>
Enthusiasts - for every approach towards building software solutions - always seem to make the same two mistakes:</div>
<div>
<ol style="text-align: left;">
<li>They try to solve every problem that they encounter with their preferred approach</li>
<li>They arbitrarily constrain their approach to require complex solutions to simple problems</li>
</ol>
<div>
I am as guilty as anyone else. I get excited by the promise of something (I used to be an Object-Oriented Bigot) and immediately I become an Evangelist For The Cause... and then when confronted with a problem that doesn't really fit my approach I charge ahead with a solution anyway (even though it's a lousy solution).</div>
</div>
<div>
<br /></div>
<div>
Take a look at whatever forum you wish, and you'll see that True Believers are almost always eventually proved to be wrong... There certainly are some beauties on my old <a href="http://www.java.net/blogs/johnreynolds">Java.Net</a> blog that I'd love to erase.</div>
<div>
<br /></div>
<div>
As with all True Believers who have fallen from grace - I'd like to atone for my sins and help others avoid the same pitfalls. With that in mind, here are some observations about building solutions that might prove helpful to remember:</div>
<div>
<ul style="text-align: left;">
<li>It's always about Data</li>
<li>It's always about Process</li>
<li>It's always about Events</li>
<li>It's always about Rules</li>
<li>It's always about Services</li>
<li>It's always about Human Interactions</li>
</ul>
<div>
Full solutions entail a lot of things... and many of those things require different approaches to develop and maintain. Don't lock yourself into an approach that forces square pegs into round holes - You'll always regret it eventually.</div>
</div>
</div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com0tag:blogger.com,1999:blog-25178118.post-30057012526792391412012-10-06T11:13:00.000-06:002012-10-07T10:51:57.093-06:00Robotruckers<div dir="ltr" style="text-align: left;" trbidi="on">
I'm very excited <a href="http://thoughtfulprogrammer.blogspot.com/2006/07/distracted-drivers-is-moretechnology.html">about the progress</a> in <a href="http://www.wired.com/geekdad/2012/10/self-driving-cars/">self-driving cars</a>, and surely hope I can afford one some day. I think they'll be as transformative to our cultures as the <a href="http://en.wikipedia.org/wiki/Brass_Era_car">horseless carriages</a> of the early 20th century.<br />
<br />
But I don't think personal transportation will lead this wave - I think it will be trucks.<br />
<br />
In a very few years, I'm guessing that every trip that you take on an Interstate will expose you to a robotrucker.<br />
<br />
Think about all the Walmart trucks you see on the road today. Their routes are already carefully planned to deliver the maximum load for the minimum energy cost and minimal wear and tear on the trucks, and they're guided and monitored by GPS every step of the way. I'd never accuse the drivers of these Walmart trucks of being robots - but I think it's really clear that in the very near future they could likely be replaced by robots.<br />
<br />
<a href="http://www.fmcsa.dot.gov/rules-regulations/truck/driver/truck-driver.htm">Federal regulations</a> require human drivers to rest every few hours - Robots never have to rest. Perhaps labor lobbyists will succeed in enacting Federal laws to impose the same rules on robots to level the playing field, but I doubt it. More likely, Federal laws will quickly expand the self-driving footholds in California and Nevada to cover the whole country. Once that happens, and once it's cheaper to insure a robotrucker than a human driven truck - companies like Walmart will take the plunge in mass.<br />
<br />
This is bad news for truckers. Their profession won't disappear overnight, but it will be their last generation - something like the fate of most cowboys when the railroads eliminated the need for big cattle drives in the 1880s. The long trail drives from Texas to Abilene Kansas ended for good when the railroads reached the ranches near <a href="http://www.abilenetx.com/about/history.htm">Abilene Texas</a>. Cowboys survive to this day, but their role in the transportation of cattle ended long ago.<br />
<br />
Inching a bit further out on the predictive limb... My guess is that the rise of robotruckers will correspond with the pervasive use of <a href="http://www.consumerenergycenter.org/transportation/afvs/cng.html">compressed natural gas</a> as the primary truck fuel. CNG is far from a perfect fuel, but natural gas is plentiful and has a well established distribution network. Pipe gas to truck stops, compress it using solar or wind power, and you've got a cleaner and more plentiful fuel than the diesel most trucks currently use. Maybe not as green as batteries or fuel cells, but much less exotic, and thus more likely to gain traction... and if CNG becomes readily available at truck stops it will become much more available for personal vehicles - a win for those of us who would like that option.<br />
<br />
But I digress... The fuel preference of robotruckers will likely have less of an effect on the rest of us than the high likelihood that robotruckers will be tattle-tales - they'll likely report every speeder and reckless driver they encounter. <br />
<br />
Imagine a world where every truck that you pass is a rolling red-light camera and radar trap...<br />
<br />
Robotruckers only concerns are selfish. They need to get their loads to their destination as efficiently and predictably as they can. Their owners are likewise selfish - and the cost of accidents and insurance premiums motivates them to do whatever they can to reduce the number of the first and the cost of the latter. What better way to make life for the robotrucker safer and more predictable than to report drivers who represent a threat?<br />
<br />
In many cities, the public has been able to block the universally dispised red light cameras by pressuring public officials - but public outrage won't ever silence those who report unsafe drivers - and a legion of dispassionate and accurate robotruckers reporting every transgression is going to force the rest of us to drive a lot more carefully (or leave the driving to our cars). A bit annoying - but safer for everyone in the long run.<br />
<br />
Perhaps this isn't quite as exciting as <a href="http://en.wikipedia.org/wiki/Transformers">sentient trucks that can transform into robot warriors to defend us from evil</a>, but it is a plausible future that's a little better than today. <a href="http://en.wikipedia.org/wiki/List_of_CB_slang">10-4 Good Buddy!</a><br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com3tag:blogger.com,1999:blog-25178118.post-75768485390343519902012-10-01T09:21:00.005-06:002012-10-01T09:40:06.477-06:00Ad-Libbed Activities<div dir="ltr" style="text-align: left;" trbidi="on">
Unscripted, spontaneous, on the spot actions and decisions... Such are the bane of the Business Process automation control freak within me.<br />
<br />
I'd love to be able to script every movement, anticipate every event and have a scripted answer for every situation before it arises, but that's just never going to happen in the business world. My carefully crafted <a href="http://www.bpmn.org/">BPMN</a> process diagrams are never really going to guide any more than the "Happy Path" and a few obvious "Exception Paths" through my Business Process. <br />
<br />
I can't anticipate everything that's going to happen, and quite frankly even if I could it's doubtful that the effort to plan for every eventuality would make business run any smoother. More likely I'd end up with an extremely brittle solution rather than the resilient process that I had intended.<br />
<br />
What I have to accept is that Unscripted Things Happen - and deal with it.<br />
<br />
For most Business Processes there is a natural order to the Activities that should be performed to produce the desired outcomes. For some (if not most) Activities there are definite prerequisites that must take place before the Activity can be started. Scripting the precedence of Activities and automating the transition from one to the next brings order and efficiency to the Business Process, and it often prevents a lot of errors.<br />
<br />
What we mustn't forget is the difference between Natural Order and Required Order and the difference between Activities that Should Be Performed and Activities that Must Be Performed. In Business, almost everything is optional if the boss says it's optional.<br />
<br />
More importantly, Unscripted Things Happen.<br />
<br />
Business doesn't happen in a vacuum. Stuff that you didn't anticipate happens all the time, and stuff that you expected to happen either doesn't happen when you expected it or doesn't happen at all. Your people often have to "ad-lib" their lines to get things back on track.<br />
<br />
With this reality is mind ... Every Activity in your Business Process is potentially an Ad Hoc Activity. Every Activity can potentially be performed at Any Time and in some cases it can be performed Multiple Times.<br />
<br />
Activities really have to check their own prerequisites, and provide guidance to those who try to perform them "before they're ready". Activities also need to check to see if they've "already been done once" and make the proper adjustment. If work has already been done that needs to be "undone", then guidance on how to undo that work needs to be provided.<br />
<br />
This "ad hoc" focus does go against the grain of those of us who strive for process efficiency... but it's often the difference between providing a "toy" solution and something the business can really rely on.<br />
<br />
Start thinking of your Activities as "Tools for the Ad-Libber" and perhaps your business will be able to run a bit smoother when those unscripted things happen in the future.<br />
<br />
<br />
<br /></div>
Johnhttp://www.blogger.com/profile/13852313153136272800noreply@blogger.com1