Fun with the Rocket Equation

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

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

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

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?

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...

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

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".