Thoughtful Programmer

Fun with the Rocket Equation

2011-12-20T12:31:00.001-07:00

Paul Allen's recent announcement that he'll be building a massive plane for air-launching rockets spawned a discussion thread over on Space.com...

I was a bit confused about the economics of the proposal, since it appeared that the plan is to air-launch a Falcon 9 derivative, but with a payload 10,000 lbs less to Low Earth Orbit than a ground-launch Falcon 9. Fellow commenters pointed out that the rocket appears to be a Falcon 5 (rather than a Falcon 9), and based on an article I found on wikipedia it appears that air-launch is achieving a 50% increase in the payload carried to LEO (from 9,000lbs to 13,500 lbs).

What I find amusingly disturbing about this discussion thread are the helpful statements that aren't easily verified... Statements such as:

"launching from a carrier aircraft about doubles the payload, or alternately lets you use a rocket half the size"

Let's do a fact check on that statement...

There are many factors that differentiate the air-launch of a rocket from ground-launch of a rocket. The first factor that comes into mind is altitude...

Altitude, by itself, is a negligible factor. If you had a platform 1,000 miles high and stepped off the edge you'd fall right back to the ground. Orbits are dependent on velocity, not altitude (LEO velocities are on the order of 17,000 miles per hour).

The altitude factor has more to do with wind resistance. Rockets have to 'push aside' the air, so the denser the air, the more resistance. As the rocket ascends, the air density lessens, so our calculations need to take that into effect.

Another advantage of altitude comes from the nature of the rocket's engines - the effectiveness of an engine in converting fuel to velocity is called specific impulse, and the specific impulse for an engine at sea level is lower than the specific impulse of the same engine in a vacuum - on the order of 20% lower. The higher you go, the closer to vacuum, the higher the specific impulse.

One advantage of 'air-launch' is that you can fly your rocket above the majority of the atmosphere before you 'light the fuse'.

We should note at this point in the interest of full disclosure that space agencies haven't been too keen on building launch facilities on mountains to take advantage of the lower air density. Most launch facilities are at sea level... so air density doesn't seem to be a huge concern in practice.

The latitude of a launch site is much more important than its elevation... Achieving an orbit is dependent on the velocity of the rocket, and a rocket sitting on the ground at the equator already has a velocity of over 1000 miles per how thanks to the rotation of the Earth. The closer the rocket is to the equator, the more it benefits from the Earth's rotation.

One advantage of 'air launch' is that ability to vary the launch location. In the simplest case, you can fly your rocket to the equator to get the full benefit of the Earth's rotation before you 'light the fuse'.

The initial velocity of the rocket is tremendously important... Rockets, unlike planes, carry all of their propellant. Planes carry fuel, but they burn that fuel using atmospheric oxygen. Rockets have to carry their own oxidizers in addition to their fuel. Oxygen is actually quite heavy... so the relative initial weight of a 'fully fueled' rocket intended to achieve a specific velocity is much more than a comparable 'fully fueled' plane (with an air-breathing engine).

When a plane accelerates, it only has to accelerate it's own mass and the mass of the fuel. When a rocket accelerates, it has to accelerate it's own mass, the mass of the fuel, and the mass of the oxidizer. That's why we've seen a great deal of interest in air-breathing hyper-sonic vehicles... the eliminate the burden of accelerating that oxidizer.

Allen's air-launch proposal relies on legacy commercial jet engines, so the initial velocity of the rocket is likely to be increased in the neighborhood of 600 miles per hour compared to a ground launch... By using a Rocket Equation Calculator that I found on the web, I plugged in some numbers and came up with the following rough estimates...

To launch 1000 kilograms to LEO using a rather common rocket engine, the initial rocket weighs about 23,000 kilograms. A similar rocket launched at altitude from an aircraft traveling at 600 mph would only weigh about 12,500 kilograms.

So the poster's comment about needing 'half the rocket' holds true given what we know about Allen's proposal... Now let's look at the payload claim. Going back to my Rocket Equation Calculator and sure enough - My 12,500 kilogram rocket can loft 1000 kilograms to LEO if I start at 600 mph at a very high altitude, but only 540 kilograms if I start at sea level.

Very cool, and very satisfying to boot... but also very, very rough estimates. The devil's always in the details... and obviously some details are missing from these 'back of the envelope' calculations.

It would be marvelous if sites such as Space.com would add tools to their sites to help their reader's 'fact check' their discussions. The more confidence you have in 'the facts', the more meaningful your conversations can be.

On a related topic, Elon Musk's Why it's so hard to build a reusable rocket.

Lessons to be learned from Phobos-Grunt

2011-12-02T14:14:00.001-07:00

Today European Space Agency attempts to help salvage Russia's Phobos-Grunt mission to Mars were ceased.

This is a big disappointment. Apparently the probe made it to a low Earth orbit, but the subsequent burn to send the craft towards Mars never happened.

Beyond the loss of this mission, it's a glaring reminder of how limited our mastery of space is. We have many superficially impressive assets in space, including a manned space station, but we don't have any real infrastructure in place to 'fix things'. We've got people in orbit, but in a real sense they are less able to fix anything than people on the ground.

Hopefully folks will wake up and reassess how we've been doing business. The US and Russia and China need to stop repeating the same old process of 'fitting the entire mission on a single rocket' and really and truly start building a space infrastructure that allows us to assemble things in orbit, repair and refuel things in orbit, etc.

Commercial companies are ready willing and able to launch payloads to low Earth and geosynchronous orbits. NASA and her peers should leverage that by developing real space-based assets that 'take over from there'. If that infrastructure had been in place today Phobos-Grunt may have been delayed rather than destroyed.

NASA and her peers need to totally ignore the problem of getting to Earth orbit. They need to assume that the starting point is with something that is already in a low Earth orbit - Something which can either be launched by an existing rocket, or which can be assembled by multiple launches of existing rockets.

Focus on propulsion technologies to get missions where they need to go as quickly as possible. Focus on technologies for transforming materials on the moon and asteroids into useful products. Quit trying to redo 'Apollo' (a one shot mission where everything was thrown away) and build the infrastructure needed to truly live in space (rather than just visit).

Process Management - From Trails to Rails to Roads

2011-11-29T07:00:00.001-07:00

I've been reading Trails of Historic New Mexico this week... I love traveling and I love history, so what's not to love about the history of travel?

Throughout history, travel has primarily been a byproduct of trade. If you wanted something that wasn't available locally, you had to travel some place to get it.

Trade routes begin with some greedy explorer or scout who through trial and error managed to travel from Point A to Point B. Often they had no idea where they were headed, but if there was something worth trading for wherever they ended up the result would be a trade route.
Once the explorers proved that you could in fact get from A to B, trail blazers set out to determine the best route for getting from from A to B on foot or horseback.
As the need to carry more goods between points A and B increased, the traders evolved the footpaths into dirt roads that their wagons could easily traverse.
As technology improved, rail lines were laid between A and B to carry goods more efficiently by train.
Trains were very efficient at hauling big loads from A to B, but the rigidity of the rails made it very difficult to deliver goods to any other destination, so the earlier roads were improved and expanded to meet the new needs with trucks.

This pattern was repeated time and time again - with Northern New Mexico being no exception...

When traveling by foot between Albuquerque, Santa Fe, and Las Vegas (New Mexico), people would tend to meander a bit, using landmarks to guide their progress, but varying their paths based on any number of factors (mountains, rivers, weather, wildlife, fellow travelers, etc.):

Despite these seemingly random variations in the routes the travelers would take, over time 'trails' (little more than ruts in the dirt) would develop, making it much easier for those who'd never made the journey to find their way:

As traffic between the three cities increased, the early trails became wider and smoother. Deep ruts were filled with gravel, bridges were built to cross gullies and rivers. The myriad braids of footpaths merged into a few rather nice roads.

Travel between the three cities became much more standardized and much more predictable. Life was getting better for the traders:

As the cities grew, the need to transport goods between the cities increased dramatically. To meet these needs a Railroad was built. Trains were much more efficient at hauling freight from one local to another, but trains have trouble on steep grades and rails were much more expensive to lay than dirt roads were to construct.
Consequently, the rails were only laid between Las Vegas and Albuquerque - bypassing Santa Fe. For those still needing to visit Santa Fe, a spur line was built off the main line at the newly founded town of Lamy:

The rail lines, although efficient for transporting heavy loads, were not flexible in terms of delivering goods to those who were not on the rail line. This lack of flexibility led to a resurgence of trucking once the old roads were improved and expanded:

We're not quite back to the routes of those original footpaths, but we're close. The modern roads provide the flexibility of routes and destinations that the old footpaths did coupled with the reliability and speed of delivery afforded by modern trucks.

So what's the lesson that we can learn by using the evolution of trails to rails to roads as an analogy for Business Process Management? (You knew I couldn't resist)...

Your company's processes evolve in much the same way as roads do. The goals are known - You have to get from Point A to Point C, and you have to visit Point B on the way. The precise set of steps that you have to take on your journey may vary quite a bit until you figure out the best way to accomplish your goal.

Once you've figured out the best way to get from A to B to C it's time to automate what you can. Use a BPM System to build those 'Rails' that guide your steps along the tried and true path... Life is now glorious.

But...
There's always a but...

Things always change.

If you build the equivalent of a Rail Line from A to B to C, then you're stuck. You can't adapt when something changes. What you really needed were Roads and a Truck instead of Rails and a Train.

I think this is why we're seeing rising interest in Adaptive Case Management systems. Folk have used BPM Systems to manage their processes, but they're finding that those processes aren't as structured as they thought they were. Way too often, they're finding that the process paths enforced by their BPM System are too rigid, and they're having to 'go outside the system' to get their work done.

This is a serious problem for many folks, and not one that I will trivially dismiss. BPM Systems 'work well' when processes are highly structured. When processes aren't highly structured a BPM System can be more trouble than it's worth.

That said... Process does exist. You need to get from Point A to Point C. You aren't just taking random steps, hoping to end up 'somewhere' - You have a definite objective that you have to reach.

The mistake that we often make is in thinking that there are a fixed number of steps in the Process and the order in which we take the steps is as rigid as those Rail Lines from Las Vegas to Albuquerque.

For every Set of Activities in a Process there's probably an Alternate Set of Activities that could be performed in special circumstances. For every Path Through The Process there's probably an Alternate Path that's appropriate at some time. At any point in your Process, you may need to Expedite the Process or you may need to Cancel the Process.

It's generally a fool's mission to try to define every possible Activity and every possible Path in your Process. Even if you did, things change.

So what we really need to define is a 'Typical Process'... a really good definition of the objectives and of what really needs to be accomplished.

When we define the Activities within our Typical Process, we have to be really sensitive to the fact that given enough pressure all Activities are Optional. Somebody somewhere can say "Skip That and Do This instead".

I've seen a lot of blogs and articles lauding the Knowledge Worker's inherent ability to "Do the Right Thing"... but in a complex work environment there are often many factors that workers aren't aware of. Workers are often scared to skip a step because they aren't sure that they know all of the ramifications of skipping the step.

To truly empower our Knowledge Workers, we need to (figuratively speaking) provide them with a Map in addition to Directions - transforming them from the Engineers who drive a Train down the Rails to the Truck Drivers who use their experience to pick the best Route.

Without a good Map, a Truck Driver can only follow the signs and hope he doesn't miss one. With a good Map the Knowledgeable Driver can always figure out how to get where they need to go.

You can't see the (public's) sky because the (vendor's) clouds are blocking it

2011-11-18T08:17:00.001-07:00

I received my Kindle Fire yesterday, and I'm sad to say that I'll most likely return it. I simply don't like the 7 inch form factor.

My best description for the 7 inch form factor is 'Not Quite'... It's not quite small enough to be as convenient as a phone and it's not quite big enough to be useful as a tablet.

If you are a person who loves the 7 inch tablets please don't be upset with me. It's simply a matter of personal preference.

The 7 inch form factor was the first disappointment for me, but when I found how difficult it was for me to access my non-Amazon content it spawned a much deeper concern.

The Kindle Fire experience doesn't feel like you're connecting to the web - it feels like you're looking through a keyhole into one little room of the web... or perhaps you're trapped in a hallway with many doors and many keyholes. Many of the keyholes are blocked.

That's when it hit me... Amazon isn't giving me access to 'The Cloud', they're giving me access to 'Their Cloud'. Everything that I purchase from them resides in 'Their Cloud'. The same is true for Apple. The stuff I buy from Apple ends up in the 'Apple Cloud'... Flash forward in time and I see myself carrying both an iPad and a Kindle, juggling them from one hand to another in order to access 'My Content' in 'Their Clouds'.

This is actually an extension of my Facebook vs. Google+ woes. The content that I post on either system pretty much stays in those systems. There are some 3rd party approaches for posting to both, but the fact remains that both vendors want to own (or at the very least constrain) access to 'My Content'.

If the Universe was fair, which it isn't, whenever I created any content it would be stored in 'My Cloud'. Whenever I purchased anything it would be stored in 'My Cloud'. Facebook, Google+, Apple, and Amazon would have to pull that content from 'My Cloud' to use it in their apps, and I would set the policies regarding access to 'My Content'.

There is absolutely no economic incentive for Facebook, Google, Apple or Amazon to support the concept of 'My Cloud' versus theirs... so we're probably stuck. Our future sky will be a very cloudy one, and none of those clouds will be ours.

Is BPM a subset of Case Management?

2011-10-31T12:23:00.000-06:00

Sandy Kemsley recently related a quote from IBM's Feri Clayton regarding BPM:

“BPM is now considered part of Case Manager”

Could that statement possibly be true?!?!
Could BPM be considered to be a subset of Case Management?!?!
Will cats start breeding with dogs?!?!

Well... except for that last sentence, yes. BPM is a subset of Case. In fact, BPM is a subset of a lot of things - it always has been, and that's caused a lot of marketing confusion over the years... but very few practitioners have cared much about such distinctions.

Process is an integral part of virtually all Business Management scenarios. In Case Management you're generally dealing with a Business Object, and there are many Processes that come into play over the life-cycle of that Business Object.

If we take a good look at any Business Management (software) solution, we're going to see these core elements:

Business Objects
Business Processes
Business Rules
Business Events

Changes to Business Objects are governed by Rules. The state of Business Objects can trigger Events. Business Processes are used to transform Business Objects. Business Processes can trigger or be triggered by Events... (You are also quite likely to encounter Business Monitoring and Business Analytics in your solution... But I digress...)

It's all very incestuous...

Any non-trivial Business Management solution - and that certainly includes Case Management solutions - is going to have aspects of data, process, rules and events. Any Case Management System worth its salt is going to incorporate support for data, process, rules and events.

So yes indeed, BPM is a subset of Case Management.

The curious Case of the disappearing BPM Programmer...

2011-10-24T10:04:00.000-06:00

I always enjoy reading through Adam Deane's BPM Quotes of the Week, and recently came across this great quote from Lynn Haber regarding BPM and Case Management:

“Case” and “process” are two distinct concepts. A case contains all the artifacts, including potentially multiple processes, associated with accomplishing a given piece of work. In contrast, a process is the path or paths that a case takes on its journey to completion. The process may or may not be explicitly defined prior to the case being started, depending on the type of work.

I'm going to quibble with Lynn's statement just a bit - 'a process is the path or paths that a case takes on its journey to completion' misses the mark ever so slightly because completion of a single process within a case usually doesn't "complete" the case itself... but that's just a quibble - Case and Process are distinct concepts.

Process is about transformation - In many processes you start with "something" and you end up with "something else" (a Loan Application becomes a Loan), but in Case you start with "something" and usually end up with the same "something" (but in a different state - such as updating a client's address).

Case is about coordination - Quoting Lynn again:

The best way to think of a "case" is to think about a coordinating object that has to be managed over time. The case folder is simply a single view into the data, tasks, documents and history of that entity.

Well put Lynn - Case is about managing "something" over time.

So where does this distinction between Case and Process leave the BPM Programmer? Are BPM skills irrelevant in the new world of Dynamic Case Management and Social Process? Are the BPM Programmer's skills doomed for irrelevance every few years just as the skills of System Programmers (C begat C++ begat Java begat Ruby etc.)?

Will BPM Programmers disappear into the mists of interesting but irrelevant oddities of the past?

Fear not, brave BPM Programmer - Your skills are safe.

Case without Process is like Process without Rules is like Rules without Events. Everything builds on everything else when it comes to Managing a Business.

When push comes to shove, you never were a BPM Programmer -

You've always dealt with Business Objects. Those Business Objects have always been associated with Business Rules. Those Business Rules have always been evaluated in response to Business Events. You've always dealt with coordinating changes to Business Objects by related but distinct Business Processes.

Nothing's changed dear colleagues. Your job has always been about writing software to Manage Business. Process is at the core of Business Management, but you always had to deal with Objects, Rules and Events.

You called yourself a BPM programmer, but in reality you've always been a Business Management Programmer (who was really passionate about Process). The "P" has disappeared from our monikers, but we're still alive and well.

Big Government, Big Corporations, and Buggy Code

2011-10-14T09:52:00.000-06:00

Off topic again... here in the USA the "left wing" has inevitably responded to the "right wing" - the Tea Party's conservative exasperation with big government has been joined by the liberal "Occupy" movement's exasperation with big corporations.

As a programmer, I'd like to councel both sides to step back and search for common roots for their exasperation. In the heat of rhetoric it looks like these folks are in vehement opposition, but from a programmer's perspective it sure does look like the "bugs" in big government are closely related to the "bugs" in big corporations...

Programmers understand a great many things about "bugs"... In the context of our profession "bugs" are coding mistakes... "code" (aka source code) refers to the instructions that make up our programs... but in a much wider context "code" can be thought of as the mechanisms that guide everything. DNA is the primary "code" that governs life, for example.

Programmers come to understand (through many painful experiences) that it is really, really hard to write "bug free" code (code that is not flawed). Any code that is non-trivial will probably produce results that were never intended (side effects). What seems like a perfectly straight-forward set of computer instructions can result in a hopeless or disastrous mess when executed.

Governments and corporations are also driven by "code". Rules, regulations, laws, edicts, procedures... all contribute to dictate how governments and corporations "run". Flaws in these rules, regulations, laws, edicts, procedures, etc.... Bugs in this "code" are what are exasperating the "Right" and the "Left".

The bigger the government or the corporation, the more "buggy code" there is driving it... and that's what makes it hard for policy makers to know where to start.

Often times, well intended attempts to "fix" something simply "breaks" something else... Attempting to fixi what looks like a minor bug often unleashes a major bug to ravage the system.

Programmers (at least the good ones) deal with bugs by going back to the source... What was the intent in the first place? What problems needed to be solved? What goals needed to be reached? Often the "bugs" in the system stem from from poorly crafted problem statements and goals.

In the case of "big corporations"... I think our exasperation stems from their basic goals and the mechanisms that are in place to achieve those goals...

Big corporations are "publicly traded". Investors buy stock in the corporation in anticipation of periodic dividends that will be paid back to the stock holders.

Early in the life of the corporation, the funds raised by selling stock provide the capital that the company needs to develop and market its products... but once the corporation becomes mature the value of the stock effects the investors more directly than it effects the operations of the company.

Consequently, investors beat up on CEOs to keep raising the stock value, and to keep paying higher and higher dividends.

Fifty years ago, very few people invested their saving in stocks. Most people saved their money in banks or purchased bonds (usually government saving bonds). This changed dramatically in the 1980s when large numbers of people began to invest in Mutual Funds via their IRA and 401K plans.

Interesting digression: These charts seem to indicate that there is some correlation between the Mutual Fund ownership trend and the trend in CEO compensation (rather than corporate profit):

Mutual Funds are generally collections of stocks (and bonds)... They "make it safer" to invest by spreading the risk over a variety of corporate stocks, but they also make ownership extremely abstract. Few people who invest in Mutual Funds have any idea of what corporations they are actually investing in.

Consequently, the investors in Mutual Funds have one, and only one, concern: The increase in value of their shares. Anonymous ownership leads them to focus on profits - Even when obtaining those profits may be harming them in other ways...

Many people who owned stock in US corporations lost their jobs when those same US corporations "offshored" work to other countries.

Government rules and regulations spurred the growth of Mutual Funds... which led to irresponsible Investor demands on CEO's, which lead to "record profits for the rich" but also tremendous losses in "good jobs" and domestic manufacturing capabilities.

Said another way - Poorly thought out requirements led to the creation of "buggy" rules, regulations, procedures, etc - and a lot of good people got screwed as a result (and a lot of shady people disproportionately benefited).

Hopefully, those on the left and those on the right will all come to see this... "Patching" the "code" to eliminate the side effects just won't cut it. Left and right need to join together to refine their requirements, accurately identify their shared goals and shared problems, and then "clean up the code".

In case NASA is listening

2011-09-16T13:45:00.000-06:00

Diverging once again from the world of programming...

NASA has just announced the new Space Launch System. No surprises here - they're taking the Shuttle components and reshuffling them. Similar proposals for Shuttle component variants were made back in the 1970s before the Shuttle ever flew.

There's nothing technically wrong with this new "big rocket" proposal - The problem is improper allocation of public resources: Spending $3 Billion a year on NASA is a great idea... but we don't need NASA to spend that money on building big rockets any more. Commercial companies like United Launch Alliance, SpaceX and Orbital Sciences can do that quite nicely.

NASA's building a new big rocket, using Shuttle hardware, in part to keep subsidizing the companies that supplied the Shuttle components... and that's just not fair to the commercial launch companies. If Rocketdyne wants to commercialize the Shuttle Main Engines on their own launcher, that's great. If ATK wants to try to commercially sell their Solid Rockets to launch people into orbit, that's terrific.

The point is, there's no new knowledge to be gained by NASA building another big rocket to get things to orbit. We already know how to do it with "off the shelf" technology.

"Big rockets" are so 20th Century anyway... There's little need for hauling "big" payloads in the first place - We've perfected orbital rendezvous and know how to dock spacecraft to assemble "big things" in orbit. If it's too big to fit on a Falcon Heavy or an Atlas V, then send it up in sections.

NASA should focus on what we do after we get to orbit.

NASA's spending should focus on Ion Thrusters and other propulsion technologies instead of on big rockets. Why take a 9 month journey to Mars on a "big rocket" when an Ion thruster craft could get you there in 39 days? (NASA plans to spend $3 Billion a year on their new "big rocket", but only $400 million a year on Game Changing technologies such as this)

NASA's spending should also focus on making things in space (or on the moon) instead of on hauling things up from the Earth. We'll never be more than visitors to space until we can build and repair things there. A Lunar base without a good machine shop won't last for long.

NASA's goals shouldn't be mundane "go to the Moon" or "go to an Asteroid" or "go to Mars". NASA's goals should be to enable us to actually live on the Moon, an Asteroid, or Mars. Anything less simply isn't worth doing.

Update: 29 Sep 2011:
Elon Musk of SpaceX announced his company's plans to create a reusable launch system... Somewhat along the lines of the DC X which languished and died back in the 90s. Big programs sucked up all the money, living very little for researching new approaches... Which is probably what the new SSL will do if it goes forward.

Update: 23 Oct 2011:
NASA rejects a study that concludes that NASA could forgo the heavy-lift and use existing smaller rockets, combined with fuel depots, to reach its targets more quickly and less expensively.

Visible Business

2011-09-12T10:43:00.000-06:00

The key to writing really good software is to truly understand why you are writing that software in the first place.

Occasionally I'll create software for my personal use, but most of the time I'm writing software for someone else. I write the software because "It's my job"... or more precisely because "It's my job to write software to satisfy the requirements that 'my boss' gives me". Perfectly true, but not in the least bit helpful. There's a rambling chain of events that leads from "an idea" to "requirements", and prior to that there are innumerable events and coincidences that lead up to "an idea" that's worth doing.

You often have to delve way, way back in time to truly understand why you are writing that specific piece of software.

I am going to suggest that if the software you are writing is Business Software, then at the innermost core of your requirements you are very likely to find something related to Business Visibility. The raison d'être for your software will be tied to someone's need to know what's going on in their business.

At the heart of most Business Software are Business Events. Something has happened.

You may be writing software to detect or determine that "Something has happened", or you may be writing software to deal with the fact that "Something has happened".

Either way, visibility is the key... your software is either making "something that has happened" visible, or your software is making "something that needs to happen" visible. Your software may be making "something" visible to people, or your software may be making "something" visible to another system. This is obviously a gross simplification... but it's often a useful one.

With Business Visibility as our goal, we can now begin to make sense of things:

Business Activity Monitoring - Some kind soul has been thoughtful enough to instrument their software. When "something happens", they make note of that fact. Often times they'll update a database table somewhere, or they may "broadcast a message". Business Activity Monitoring is all about seeing those changes.

Business Rules - You've got all sorts of data - and you need to figure out what to do with it. Perhaps "something just happened", but what you do about it depends on many other things. Business Rules connect the dots to help you see what needs to be done.

Business Process Management - "Something happened", and you figured out that "what to do about it" requires performing multiple steps. Business Process Management provides visibility into all the things that need to be done, when they need to be done, to whoever needs to do those things.

Business Analytics - A whole lot of "somethings" happened, and a whole lot of other things were done in reaction to those "somethings". Business Analytics is all about helping folks see (from numerous perspectives) what happened in the past, and using those insights to "see" into what's likely in the future.

As programmers, we're likely to be asked to write software that deals with any of these aspects, or any mix of these aspects, of Business Visibility. We'll likely get mired in the technology aspects of the problem very early on, and we'll likely spend most of our efforts overcoming the technical hurdles of the problem - but if we lose site of the fact that Business Visibility is the real goal we'll probably screw up.

Conceptually, the Visible Business is very simple to explain and to understand. Our Business colleagues know what they need to see, and all of the minutiae attached to those needs (security, timeliness, etc.). Let's do them a favor and not complicate that conceptual simplicity with our own arcane software concerns.

Why Johnny can't find a good job

2011-09-08T11:00:00.001-06:00

This post is a bit of a departure from my usual commentary... but I think it's good for programmers to occasionally think about the world beyond their boundaries. Today I'd like for you to think about why it's so hard for people to find "good jobs"...

I was born in the late 1950's, and from the following chart (courtesy of wikipedia) you'll see that the population of the world has roughly doubled in my life time...

That in itself should start you thinking... If there are twice as many people in the world today then there were when I was born, then we'd need twice as many "good jobs" for people to work as we did back in 1960.

You might think that the relationship between "workers needed" and "total population" would be a relatively constant percentage... and for most of human history it probably was... but that ratio is dropping as can be seen in the following model proposed by Colin Clark (also from wikipedia)...

It's a bit of a stretch, but let me assert that most "good jobs" fit into the category "Primary and Secondary Activities" in Clark's model. "Good Jobs" are generally those where you actually get to produce something. "Good Jobs" are those where your efforts result in a tangible contribution that benefits the lives of others.

Here in the USA: "manufacturing as a share of the economy has been plummeting. In 1965, manufacturing accounted for 53 percent of the economy. By 1988 it only accounted for 39 percent, and in 2004, it accounted for just 9 percent."

USA Manufacturing Jobs percentage over time

Many of those manufacturing jobs went elsewhere - but many simply disappeared as manufacturing technology improved.

Unfortunately, many of our efforts as Programmers and Engineers result (as a side effect) in the elimination of what were once considered by many to be "good jobs". We build machines and software to reduce the amount of human effort that is required to accomplish tasks. For example, when I was born, working in an Automotive Assembly Plant was considered to be a really good job... but now it's pretty clear that Industrial Robots have taken over most of what used to be "skilled labor" in that industry:

The end result (where we are today) is pretty easy to understand:

Increased Population + Increased Automation = Fewer "Good Jobs" Per Capita

And that's why Johnny can't find a good job.

The Never Changing Nature of Work

2011-09-01T14:20:00.001-06:00

Sandy Kemsley has posted a really short-but-sweet presentation on the spectrum of Business Processes and the way we need to manage them entitled The Changing Nature Of Work. I think Sandy is spot-on with her analysis... But call me a malcontent... she's mis-titled her deck. I just don't believe that the Nature Of Work ever really changes.

Some processes are 'Predictably Repetitive To The Point Of Being Boring', and other processes are 'Then A Miracle Happens' by nature. Most processes are a mix of these two extremes... and they always have been.

What's changed in recent memory is our ability to effortlessly interact with people "who aren't here" in real time. We haven't changed, so the number of people that we can effectively interact with hasn't changed... but now that group of people can be scattered across continents and hemispheres without adversely impacting the efficiency of our processes (in theory).

One of my favorite clients once told me:

"The only difference between theory and reality is that in theory there is no difference."

That's where we have to focus some of our "Social BPM" efforts... on reconciling the theory that geographic dispersion doesn't matter when the reality is that geographic dispersion really does matter.

Chatting "in real time" when it's noon in your time zone but 2 am where your colleague lives isn't going to solve many of your process problems.... and trying to coordinate simultaneous "face time" when your team is spread across the world is a major and often unreachable goal. Suddenly those people you've added to your process are a drain, not an asset.

We've got the Technology to "Flatten the Earth", but those darn Time Zones are still there... so our BPM tools really won't be Social until they make it easier to deal with that inconvenient truth.

Why WebOS didn't matter

2011-08-22T15:23:00.000-06:00

I was stunned when Hewlett Packard pulled the plug on the HP Touch and its WebOS after just a couple of months...

When I first read the announcement, I couldn't believe that a major player like HP would make such a mess of things, even more so than when RIM stumbled rolling out their Playbook. I honestly thought somebody had hacked the HP site and planted a phony story for laughs.

What's the world coming to when major technology players can't even succeed at being "also-rans" in the Tablet space?

Marc Andreessen probably has the right answer in his essay Why Software Is Eating The World:

The software is where the money is
The software runs "out there" in the cloud
The device end users access the software with doesn't really matter all that much to the service providers

That leaves Tablets in a very odd space... End users want cool Tablets, but nobody besides Apple and a bunch of Android clones will bother to build them. Sort of a replay of the PC world where extremely low profit margins led to the near impossibility of finding a well made PC... but what took years for PCs took months for Tablets.

I'm guessing that (just like PCs) Apple's iPad will continue to be a high quality device (which you'll pay more for), and there will continue to be dozens of indistinguishable Android Tablets for about half the price. Maybe Google's Motorola Mobile division will be the exception... but probably not.

Interdependent Tasks

2011-08-09T08:28:00.001-06:00

Sam manages Bob, Barb, Brad and Bill, and one of his many responsibilities is to review and act on their requests for vacation.

The Vacation Approval process is very simple:

The Employee initiates the Vacation Request
The Manager reviews the Vacation Request and renders a Decision
The Employee is notified about the Manager's Decision

So far so good... but implementing this process gets complicated pretty quickly.

Sam can't really (in good conscience) make a Decision about any Vacation Request in isolation. Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests. To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.

What looks at first glance like a simple Request Approval process has revealed itself to be a Parallel Request Approval process. The "Make a Decision" Task for one Vacation Request is linked to all other pending Vacation decisions.

Examples like these are what makes implementing "real world" processes hard. Processes seldom execute in a vacuum, and work done within one instance often influences other instances. Participants often have to consider multiple Tasks together, rather than performing each task in isolation.

Some of you are no doubt awaiting in breathless anticipation for me to reveal an elegant solution for dealing with Interdependent Tasks through clever BPMN modeling... but alas, I have no canned solution. When I encounter these situations I fall back on custom coding with varying results. My only advice (today) is to spot these cross-task dependencies early on in your projects and deal with them as best as you can.

Scratching the Programming Itch

2011-08-05T16:27:00.002-06:00

My wife Teri has been using Scratch with her students for quite awhile, and every time I take a look I just get more impressed at where it's leading...

Google's App Inventor is a good example of how Scratch is escaping it's play pen... It let's you build apps for your Android phone "without writing a line of code" ;-)

My favorite Scratch extension is BYOB (Build Your Own Blocks) which elevates scratch from elementary programming to something quite a bit more serious by adding procedures and lists. This is a fantastic example of how adding in a few simple constructs can greatly improve the power of a programming tool without making it any more complex for the new users.

Honorable mention certainly goes to Waterbear - a pure JavaScript blocks editor that points the way to Browser-Based Scratch (like) programming. Great work.

Block programming does indeed become tedious when building large programs, and good code editors can catch virtually all of the syntax errors that blocks prevent... but I think it would be a mistake to discount the approach. Blocks have proven to be a great way to get started in programming, and with the proper blocks most folks might not ever need much more.

Detecting Slips and Avoiding Mistakes

2011-07-08T12:02:00.000-06:00

I've been browsing my old copy of Donald Norman's book The Design of Everyday Things and find myself re-pondering Slips and Mistakes.

By Norman's definition:

"Slips result from automatic behavior... Mistakes result from conscious deliberations"

I've found myself slipping more lately.

To paraphrase Norman, when your goal is correct, but you get lost in the execution, that's a slip. When your goal is wrong, that's a mistake (especially if you accomplish that goal).

Our goals, by and large, are the right ones... but we're all too often trying to reach those goals by doing things the way that we've always done things. We're not consciously choosing our approaches for problem solving - We're automatically going through the steps.

As usual, I'm going to bring this back to the development and maintenance of Business Software Solutions...

We know that the environment that our business inhabits is constantly changing. New competitors enter the scene, governments change their policies, our supporting infrastructure becomes unreliable... We have to respond to these changes, or our business (government, country) will falter.

Adapt or perish.

The goal of Business Software Solutions is always two-fold:

Make the Business more profitable
Make the Business stronger (more able to weather changes)

Nobody ever makes a conscious decision to pursue goals that counter either of these... so when we don't reach these goals it's a slip.

Business must be able to run smoothly (to make a profit). Anything in our organization that helps us to run smoothly is "a good thing".

Business must be able to adapt to change. Anything in our organization that impedes our ability to adapt to change is "a bad thing".

IT groups help us to run smoothly, so they are indeed a very, very good thing... But when we rely on our IT groups to "drive" when our business must adapt to a change... well... then often the IT group is seen as an impediment to change (a very, very bad thing).

It's an error if you rely on IT to drive business change... IT doesn't know your business as well as you do. They know a lot of things that can really help you, but it's simply not their job to drive the direction of your business.

I'm going to make an un-founded assertion: Most businesses are unconsciously ceding the driving (of change implementation) duties to IT. It's not a conscious decision, it's an automatic response based on the deep seated insecurity that the "T" in IT is so horrendously complex that if business ever messed with it all hell would break loose.

Perhaps... but "I" is what's important. Information is the treasure, and business groks the information and decides what to do with it.

You have to drive, and if you abdicate that responsibility (consciously or unconsciously) you've made an error and taken us one step closer to the world described in The Marching Morons.

Business has to consciously hold the reigns, and IT has to respond to guidance. We can't have Software Development Life Cycle dogmas that tell business "you can't do that" and we can't have "Scrum Nazis" dictating to business which features get implemented or deferred.

To really make this happen - in my less than humble opinion - we have to stop slipping up and set a conscious goal of really enabling the business to drive our software projects, and to do that we have to set a conscious goal to make software solutions comprehensible to business people...

You can't drive what you don't understand... so we've got to subjugate our cool software development desires to the goal of "the business can see what you did". They may not understand everything that's "under the hood", but they can't drive unless they can see all the parts, see how they're combined, and understand what they do.

Do you really need thousands of apps to choose from?

2011-07-01T08:26:00.000-06:00

This post is a bit of a digression from my usual - But I'd like to ask those of you who read this to answer a question...

Do the Tens of Thousands of apps in the Apple App Store really matter?

I've been reading lots of reviews about HP's new TouchPad, most of which agree that the TouchPad is the 2nd best Tablet that you can buy (Care to guess who is Number One?), and they almost all say something like:

"the HP App Catalog store isn't exactly full of apps (there will be more than 300 tablet-optimized apps available at launch, according to HP), and the size of Apple's App Store gives it a major advantage over tablet competitors such as the TouchPad."

Is Quantity(of Apps) really an advantage over Quality? Or is Quantity making it difficult to find the needle that you are looking for in a really big haystack?

The answer is a matter of opinion, and I'd like to know yours.

Builders and Business People

2011-06-20T13:25:00.000-06:00

I spent this past weekend building a fence... well... not quite.
I spent this past weekend watching Juan and Jose build a fence.

I live just east of Santa Fe, New Mexico... and out here many folks have what's known as a "Coyote Fence". Juan and Jose are local craftsmen who (among other skills) are very good at building this type of fence.

My wife and I laid out the boundaries with stakes and twine, and then told Juan what we wanted (Juan's the eldest brother - so he handles the negotiations). I had all the materials on site prior to arrival, so when the guys showed up on Saturday morning they got right to work and had the project completed by Sunday afternoon.

During the build, Juan noticed a few things I'd asked for that were (in retrospect) just plain crazy. For one, I had the gate swinging the wrong way - He brought that to my attention and we changed the plan on the spot. My wife also had to run to the store to get some items I'd missed, but otherwise Juan and Jose worked like demons and I got to sit by and watch.

I could have built this fence myself. I've done similar projects in the past, and I'm not "that" old. It's hard work, but not more than I can handle... But I chose to "pay the experts" instead of building it myself.
They do this for a living... I make my living doing other things.

By now you've probably figured out that there's a lesson here that goes beyond home improvement...

I am a huge fan of enabling Business folks to build their own software solutions, but the fact remains that most people prefer to pay others rather than build things for themselves. No matter how "business friendly" our tools become, most businesses will bring in builders when they need them.

The keys to success for a business software project are the same as those which made my weekend project a success. The Clients (Teri and I) were able to lay out the boundaries and effectively communicate our requirements to the Builders (Juan and Jose). One of the Clients (me) knew enough about building to be able to effectively monitor the work, and someone empowered to make decisions (my wife Teri) was on hand to resolve any issues that came up (screwy gate orientation). The engagement was further enhanced by the professionalism of the Builder (Juan) to make suggestions.

Let's go a bit further though and note an important distinction between my fence project and a typical business software project... the solution that the Builders supplied for me is completely "open". I can see how it's put together, and I can see how to extend the solution. For example, with tools that I know how to use I will be able to add another gate should I ever need one. If the fence ever needs repairs, I know enough to be able to implement those repairs (but I'll probably just call Juan again).

This is where "Tools" for the Business folks have their place... Give the Business folks tools that allow them to "see" what's been built and to provide the answers that they need when it's time to make a change... and they'll be happier and you'll be happier...

... But I'm willing to bet they'll still call you to build "it" rather than built "it" themselves ;-)

Templates and Frameworks

2011-06-14T10:30:00.000-06:00

Sandy Kemsley posted a nice BPM Success Story "BPM Rapid Development Methodology" that has jogged me into publishing some thoughts I've been having about Templates and Frameworks as they relate to successful Business involvement in software projects.

Sandy relates:

"They’ve established best practices and templates for their user interface design, greatly reducing the time required and improving consistency. They’ve built in a number of usability measures, such as reducing navigation and presenting only the information required at a specific step. I think that this type of standardization is something rarely done in the user interface end of BPMS development, and I can see how it would accelerate their development efforts. It’s also interesting that they moved away from cowboy-style development into a more disciplined approach, even while implementing Agile: the two are definitely not mutually exclusive."

"This new methodology and best practices – resulting in a lean BPM team of analysts, PMs, developers, testers and report writers – have allowed them to complete five large projects incorporating 127 different processes in the past year. Their business analysts actually design the processes, involving the developers only for the technical bindings; this means that the BAs do about 50% of the “development”, which is what all of the BPMS vendors will tell you should be happening, but rarely actually happens in practice."

Admittedly I am drawn to this case study because their methodology and best practices mirror my own leanings... With the right approach Business folks really can drive (rather than be chauffeured around by the Technical folks).

Note that Sandy's tale mentions Templates, but it doesn't say a thing about Frameworks... and to me that's very significant...

As a Professional Programmer, my life revolved around Frameworks (OWL, MFC, Struts, Spring, etc.) Each of these Frameworks provided a wonderfully powerful foundation on which I could build my custom applications. I simply can't imagine life as a Professional Programmer without programming Frameworks.

Pardon me for over-simplifying, but a Framework is something that "you bolt pieces on to". The Framework provides the internal structure of your program, and you can build many diverse and wonderful programs on top of any really good Framework.

If you are an Occasional Business Programmer you've probably found that Frameworks aren't quite what you're looking for. Frameworks are really powerful and really flexible - but all that power and flexibility comes at a price - you really have to know what you're doing to use them.

Contrast Frameworks with Templates... a Template is something where you "fill in the details". The outcome of using a particular Template is always the same thing - the implementation details may be wildly different, but as long as those details "stay in the box" your result is going to be what you set out to build.

Historically the Technical folks have built the Templates and the Business folks have "filled them in" (usually using wizards) - but our BPM Suites are showing us that the converse can be equally as powerful - Business can build some of the Templates (for the process) and the Techies can "fill in the details".

It's all about Requirements and Constraints. Business folks can use Templates to convey Business Requirements to Technical folks, and Technical folks can use Templates to provide a "sandbox" within which Business folks can safely play (without breaking anything).

If you are a Business Guy composing a solution, and the "component " that you need doesn't yet exist, then just build a Template, ask your Techie colleague to "fill it in", and keep on going... You can't get much more rapid than that.

Tasks and Time

2011-06-01T17:20:00.000-06:00

Tasks are always associated with time... Tasks are started at some point in time and they are completed at some point in time. We're almost always interested in the duration (how long it takes) from the Start Time to the Completion Time.

Start Time and Completion Time are the biggies, but there are a few more timestamps that we're often interested in capturing (especially when tasks are performed by humans). Here's my list:

Assignment Time - the point in time when the task is assigned to a person (or group). In most of the process applications I've implemented we don't assign a task to a person until that task is ready to start... but sometimes we do know who should work on a task long before the task should start. If we relate this in terms of an appointment on your calendar, this would be the time when you made the appointment.

Scheduled/Estimated Start Time - the point in time when the human should (ideally) start working on the task. In many process applications we don't predict when a task should start - it simply starts when the process flow reaches the task. Explicitly scheduling or estimating start times can be very useful if you need to determine whether or not a specific process is "on track" to complete on time.
Ready To Start Time - the point in time when everything is ready for work to begin on the task.
Start Time (aka Actual Start Time) - the point in time when the human starts working the task. It's our fondest hope that the Scheduled Start Time, Start Time and Ready To Start Time are all the same - but when dealing with humans they seldom are.

Scheduled/Estimated Completion Time - the point in time when the task should be completed. This is really an expression of "how long the task should take". In most cases I've seen this set by adding the expected duration of the task to the Start Time - but there are cases where a hard and fast completion time is critical if you need to know whether or not the process can complete on time.
Completion Time (aka Actual Completion Time) - the point in time when the human completes the task.

There are also some optional timestamps we need from time to time that you may encounter:

Reassignment Time - It happens... and there can be multiple of these for a single task instance.
Task Cancelled Time - Often good to know - not every task gets executed to completion.
Task Escalated Time - This might possibly be redundant, since reassignment and cancellation are very common elements of task escalation.
Task Suspended Time - Sometimes things come up and work on a task just has to stop. As with reassignment, this can happen multiple times per task.
Task Resumed Time - If a task was suspended, you will almost certainly want to know how long it was suspended.

Analysis of all of these timestamps can help you figure out whether or not your process is running smoothly. For example, whenever the actual Start Time is later than the Scheduled/Estimated Start Time you may have a problem... but to determine where the problems lies you'll need to take a look at the Ready To Start Time. Was the human slow in starting the work, or was there a delay that prevented the human from starting the work?

In all honesty, I've never worked with a client who captured all of these timestamps for every task... and I am certainly not advocating that you should complicate your solutions by capturing this information unless you really need to. Just don't be surprised in those rare instances that you encounter a process analyst who needs this level of detail.

If you've encountered requirements for capturing additional task oriented timestamps (or you have better descriptions/names for these timestamps), I'd love to hear about them.

Task Escalation

2011-05-31T09:28:00.005-06:00

Adam Deane has a nice post on Escalation Management over on his blog which sums up as follows:

Escalations are the bread and butter of every BPM solution....
....I’ve never heard of escalation management being a mandatory component of a BPMS. I’ve never seen an escalation best practice. It seems everyone just takes it for granted.

I have to agree with Adam on this one... escalation of tasks is taken for granted - right up until you have to implement it.

Case in point is a recent discussion with one of my colleagues (paraphrased here):

A client approached us with the following problem:
- The process has a due date.
- Activities have due dates relative to the process' due date (e.g. one activity must be finished 20 days before the due date of the process)
- If the due date for an activity is missed, an event should be raised and acted upon.

After discussing this with colleagues, we came up with two approaches:

BMPN-based solution:

Add a timer to each activity, configure them to trigger after due date.
Create another activity to handle the missed deadline and attach it to the activity.

Programmatic Solution:

Create a Service that is triggered once an hour.
Fetch all instances of the process and for each instance check the active task's Due Date. If it is passed, act on it.

Alternative 1 is a "pure modeling" alternative, that might attract some people. Though you need to do add the timer to each activity which has a deadline.
Alternative 2 means more work initially to implement the timer triggered service, but with careful design I guess it could be used for all activities.

I suppose you could characterize this (with apologies to William Shakespeare) as:

"To Model... or not to Model? That is the question!"

It's a good question:
Is "Escalation of a Task" an aspect of your solution that should be modeled, or is it an aspect of your solution that is better expressed in some other way (perhaps with code)?

Escalation of a task often seems to be better expressed as a policy rather than as a process. In many cases it seems to be more difficult to determine whether or not a task requires escalation (perhaps it is overdue) than it is to carry out the actual escalation logic (send an email to the manager).

Of course there is no "right" or "wrong" answer... It simply depends on the specifics of your problem... but I think there are some guidelines that can be helpful in determining what to do.

First answer these questions:

Are the conditions that determine that a task "needs escalation" common across the process or specific to the task?
Are the actions that must be performed when a task "needs escalation" common across the process or specific to the task?

If the answers to both of these questions are "common across the process", then I don't think it's appropriate to model the escalation behavior on your process diagram. Your escalation logic and behavior is a policy that is applied to the process - more so than an aspect of the specific tasks.

Common logic and behaviors (let's call them policies) that are applied across your process are generally best captured as such... That will make it much easier to review and update them when the need arises.

Digressing slightly - You should also think ahead in terms of how you'd support changing this policy at runtime. A centralized expression of the escalation policy is probably going to be easier to modify than distributed logic... and it's probably a sure bet that the Business Folks are going to want to tweak these policies over time.

If the answers to either of the questions above are "specific to the task", then you need to think about it a bit more. If escalation of a task requires more than notifications and reassignment of the task (if alternate activities must be performed and the flow of the process is altered) then you most likely should model those activities on your process diagram (perhaps hidden in a nested process to keep your diagram clean ).

I'm not sure if the advice in this posting will meet Adam's desire for "Escalation Best Practices"... but hopefully it will keep the conversation going and help us (BPM Practitioners) reach consensus.

Detect, Decide, Process

2011-05-17T16:39:00.002-06:00

There is a lot to be said for breaking up a hard problem into specific aspects of the problem, developing a solution for each aspect, and then merging the results back together for a complete solution... but this approach can lead to peril if those who are working on the individual aspects forget (or are ignorant about) what the "holistic" problem is that they're working to solve.

Unfortunately the tools that we use sometimes distract us from the "holistic" problems that we're trying to solve. We've got great tools for detecting and reacting to business events, great tools for defining and executing business rules, and great tools for defining and managing business processes... but when dealing with problems that involve events, rules, and processes we often find ourselves confused by the overlapping features of our tools. In a pinch, we can build a Process with our Rules tool, or a Rule with our Process tool... and either tool can consume and generate Events. Knowing what to build with which tool can be quite a challenge.

Detect, Decide, Process...

Most business problems begin with an event of some sort. Something happens. Something changes. The business needs to respond. Rules govern the businesses response to the event... Processes guide the response when it's non-trivial. Everything's connected.

Events may occur "out of the blue", or they may be generated by a running Process, or they may be generated in response to evaluating Rules.

Rules may be evaluated "on demand", in response to an "out of the blue" Event, or they may be evaluated as a step within a Process.

Processes may be launched in response to an Event, or as the outcome of a Rule. Process flow may wait for or be altered by Events. Rules may determine Process flow or they may "kick off" a Process.

Development methodologies also come into play... I am a Process Bigot, so I employ a Process Driven methodology to arrive at a solution. Many of my colleagues are Rules Bigots and attack every problem using a Rules Driven methodology. The Business Event folks just laugh at us and follow their own methodologies.
Not a topic for the faint of heart ;-)

Those of us who build business solutions for a living eventually make sense out of all of this overlap in our tools... but I suspect that our business clients just shake their heads and trust us to use the right tools for the right jobs. Explaining our rationale for implementing some Rules in our BPM suite and some Process in our BRM suite leaves them with a queasy feeling in their stomachs and insures that they'll never ever try to build a non-trivial solution on their own.

Fear to "build it themselves" may be a good thing for short term consulting revenue, but it's very bad for everyone in the long run. We've got to make things simpler (at least conceptually) or we'll never make a real dent in solving all of the business problems out there that need solving.

Thought Harvesting

2011-05-17T11:00:00.003-06:00

I've just transitioned to a new role at IBM - from the BPM Services organization to the BPM Product Management organization. This is a position that I have wanted for a long time - Truth be told my original application to Lombardi Software in 2006 was for a position in their product management group, and the slot in their service group was just meant to "get my foot in the door".

Serendipity is an amazing thing, and much to my surprise I really loved my service job. I was able to work with really smart folks all over the world on a wide variety of process projects, and I learned a great deal about what BPM can really be and about what BPM is definitely not. Hopefully the things that I learned will contribute to the creation of better products for all of my past and future process colleagues.

I've received many congratulations on my new role, and they're all very appreciated... but there's one compliment I've received that stands out - recognition by my peers that I am a "Thought Leader" in BPM.

That's a wonderful compliment... but it's not really true. I'm not a "Thought Leader"... I am a "Thought Harvester".

I may have had an original thought or two of my own, but the reality is that the vast majority of my posts on BPM (and programming in general) are borrowed thoughts. The community of BPM practitioners is amazingly generous with their thoughts, and it's through connections with you that I get all of "my" good ideas. Thanks to all of you who've provided the inspiration and insights for my ramblings.

Going forward, I think we all have a great future as Process, Rules, Cases etc. begin to merge into comprehensive solutions. As more and more of our technical infrastructure components disappear within the boundaries of our "business software appliances" we'll be able to empower non-programmers to build more of their own solutions - sort of putting ourselves out of a job, but not really. There are always new challenges... and plenty of old problems to solve.

A Programming Language For Business

2011-04-28T21:22:00.005-06:00

Back in my java.net blogging days, I wrote a post that lost me a lot of love by asking the question:

Is Java the wrong language for business programming?

My thinly disguised answer was no. Java is not a suitable language for business programming... It's great for building the integrations and middle-ware that business relies on, but it's a lousy tool for transforming business requirements into code.

Having alienated all of my Java friends long ago, I guess my next step is to alienate my JavaScript programming friends too... Here's my rule:

Programming Languages that use == are not suitable for Business Programming

I am a realist. JavaScript is pervasive on the Web and will never die no matter what nasty things I say about it... but I truly believe we need a better choice for Business Programmers to thrive. Google, with their GWT has already shown us the way - Translate the Programming Language that meets your needs into the Programming Language that the Web supports (In the case of GWT from Java to JavaScript). Define a Business Suitable Programming Language that knows about things like dollars and cents and business days and work schedules and then translate the code that you write with this language into JavaScript. Problem solved.

Unfortunately, I don't think that Google has any interest in making the world better for Business Programmers - I hope that I am wrong, but I fear that "Business Programming" just isn't sexy enough for the wonder-kids at Google to care about.

If we ever do see a more Business Friendly Programming Language it will probably come from some stodgy old company that cares more about helping businesses run better than about seducing users into clicking on ads and sharing their marketable personal data.

It's a long shot, but maybe, just maybe, I won't be too old to program before Business Programmers finally get a language to call their own.

Government Process Management

2011-04-23T05:46:00.000-06:00

There's an article in the New York Times today about a new computerized system that should help prevent NYC police from "fixing" tickets. While this may be bad news for a few well connected individuals, for the masses this is a very good thing - The powers that be have instituted a process that (if followed) should detect (and deter) public employees from engaging in fraud.

What's not clear is the public's visibility into this process. If the tracking information for each ticket isn't publicly available, then how will we know if the process is being followed or if it's being faked? Monitoring a process is a great thing - only if those who are supposed to be protected by the process have the proper view of the process.

For those of us who are maddened by government waste and fraud, this is cause for hope. Personal privacy seems to be a thing of the past - but perhaps Government privacy is too.

Phil Glibert video

2011-04-22T14:11:00.000-06:00

Yes it's a marketing blurb, but this video from Mr. Phil is a pretty good sum up of what IBM Business Process Manager is all about.