Highly Adaptable Business Solutions

Picking up from my posting From Scratch vs. Required, while Business SME's might not always be truly interested in crafting entirely new business solutions, they're almost always interested in improving existing business solutions and in evolving them to satisfy changing requirements.

The basic premise is that Business SMEs know what needs to be "changed", so if they can learn how to "change it themselves" (or at least change most of it themselves) then businesses will be better able to adapt and improve their operations.  In the pre-computer age this was pretty much the norm, but the complexity of software development lessened the role of SMEs in implementing change.  My hope is that we can transform enough SMEs into Subject Matter Programmers to reverse that impediment to business agility.

The key to enabling business folks to make their own changes, in my very biased opinion, is to greatly constrain  the traditional IT programmer's freedom to implement business requirements as they choose.  Modern programming languages and frameworks give traditional programmers unprecedented power and flexibility to build whatever business dreams up - but that power and flexibility is a double-edged sword - often cutting deeply into the Business SMEs ability to make changes on their own.

So what constraints would I place on IT programmers?  Here's my reasoning...

Based on my experiences, I'd assert that Business SMEs usually see applications from two perspectives:

• Screens the user sees
• Business Rules and Policies that govern the application

These two perspectives are usually very closely related... Screens (generally) are used to display and manipulate Business Data, and Business Rules and Policies are used to govern the data that's displayed and how that data can be manipulated (by the user).

Assuming that I'm right in my Business SME observations, then we've got to constrain our IT programmers to architect their solutions to support the way Business SMEs "see" them.  The "code" that implements the UIs has to be "linked" to the "code" that implements the Business Rules, and to the "code" that retrieves and manipulates the Business Data.  If we do that, then my Subject Matter Experts have a much better chance of finding the "code" that needs to change.

One would think that I'm advocating generating Screens from Rules, and in a way I am, but not really - Most of the Business SMEs that I've worked with approach the Visual Aspects of a Screen first.  What a Screen looks like is inextricably tied (in their minds) to what a Screen does.

The SME's thought process is something like this:

1. By adding a "widget" to a Screen, the Business SME is defining the Business Data that will be present on the Screen.
2. Picking the type of the "widget" determines whether or not the end-user can manipulate the Business Data.
3. Refining how (to what extent) the end-user can manipulate the Business Data on the Screen is set by a Business Rule (or policy) that applies to the "widget" (or a collection of "widgets")

Experienced SMEs will grasp the likelihood that the Business Rules that apply to the Business Data are used on many Screens.  As they become adept at working with Screens, they'll gradually become more "Rules aware" in their thinking... and at that point they'll become more comfortable with the idea that Screens can be (partially) generated from Rules.  That said, I think it's still more likely that they will start with the Screen rather than start with the Rules when it's time to make a change..

It's not going to be easy to build tools to support the way Business SMEs approach "making changes", but I'm pretty sure it will be worth it in the long run.

From Scratch vs. Required Changes

I had a conversation with a colleague (my friend Fahad Osmani) today about what role Business folks "really" play in creating software solutions... and found that his insights "just feel right" to me.

Here - in paraphrased form - is what he said:

1. Business folks (SMEs) really want to be involved in the creation of business solutions, but they are quickly overwhelmed by all the details and they quickly lose interest.
2. Business Analysts stick with the project from beginning to end to extract requirements and clarifications from the Business SMEs.

That matches my experience pretty closely - and although I think about Business SMEs when designing tools, it's actually a different type of person (more like a Business Analyst) who has assumed the Business Subject Matter Programmer role in the projects that I've worked on in the past.

Not exactly the world I would like to see, but the conversation continued:

1. Business folks (SME) really want to be involved when business solutions need to change.
2. Business SMEs are generally passionate enough to stay fully engaged through the implementation of the change.

Bingo... Now we've got clarity about what it is that Subject Matter Programmers are really likely to do.  

"From Scratch" business solutions are beyond most SMEs - but not just because of the technical complexity.  The business complexity of a "from scratch" solution is daunting. Many, many details. Many, many decisions to make. Many, many inconsistencies to resolve. Dealing with all of these types of complexity isn't what most SMEs are good at. Their skills lie in other areas...

"Required Changes" to a business solution are exactly the sort of things that SMEs should be able to tackle.  Business SMEs understand the need to change way better than any IT Programmer, or even most Business Analysts can...  So empowering them to make those changes - safely - is a worthwhile goal.  I'd go so far as to say that it might be the most significant improvement to Business Agility that we can envision (much more so than participation in creating solutions from scratch).

So how does that relate to the design of our business solutions, and to the design of tools for creating those business solutions?

Here's what I know (from painful experience) - If you don't keep in mind the likelihood that your solution will have to change in the future, you are likely to implement it in a manner that will make it very hard to change in the future.

Imagine how unlikely it will be for a Subject Matter Programmer to make "a trivial change" to your solution if you didn't "design for change" in the first place?

Clearly our "Build It From Scratch" tools need to help us build "changeable" solutions if we ever want Subject Matter Programmers (SMPs) to take ownership after the initial deployment. Of course that begs the question of what we expect the SMPs to be able to change, but we'll leave that discussion for a future  post.

Tasks for Knowledge Workers

Software Industry Analysts love to argue about things (my suspicion is that they do this because they get bored) and one of the things they have been arguing about of late relates to Knowledge Workers and Business Processes.

First the good news...
BPM (Business Process Management) tools have (in general) succeeded in making it easy for Business Subject Matter Experts (SMEs) to define (and often implement) their organization's Process Logic (I call these folks Subject Matter Programmers).

By empowering Business SMEs to essentially 'program' the Process Logic, we've increased the organization's agility - The organization can implement process changes more quickly because their limited IT resources have less to worry about.

Now the not so good news...
BPM tools work well for Structured Processes - where Task C follows Task B follows Task A - but they don't work so well if there's no set order for A, B and C - and any or all of those Tasks might be optional or might cause additional Tasks to be spawned.  It's possible for a Business SME to design these scenarios (with BPMN), but not easy.

This is why Knowledge Workers are the focus of the controversy...  the Tasks that Knowledge Workers perform often resemble those which give "Structured BPM" tools problems.  If you're building a Process primarily with Tasks for "Scripted Workers" your BPMN diagrams are nice and clean, but once you start adding in Tasks for Knowledge Workers the BPMN diagrams start looking like a plate of spaghetti.

I've encountered spaghetti process diagrams many times, and I find myself vehemently agreeing with the Analysts and Pundits - Processes which rely heavily on Knowledge Workers are not served well by Structured BPM tools.  We really do need to rethink how best to deal with Tasks for Knowledge Workers.

Tasks for Knowledge Workers:

Perhaps the most common Knowledge Worker Task (that I've encountered) can be described as Review And Decide.  Some sort of Request comes to the Knowledge Worker and they Review the Request and make a Decision.

At first glance Review And Decide doesn't seem complex, but let's take a closer look...

While Reviewing a Request, a Knowledge Worker will often raise questions.  The information that has been provided (as part of the Request) may be confusing or incomplete, and the Knowledge Worker's questions must be answered before the Decision can be made.

If you model this with BPMN, you might exit the Review And Decide Task and Return to a previous Task (to clarify the Request's information), or you might go to a Clarify Request Task.  I've seen it both ways - but in both cases it doesn't seem quite right... In the real world the Knowledge Worker's Task (Review And Decide) hasn't completed - It's "partially paused" until questions have been answered.

In the real world Knowledge Workers generally ask questions as soon as they see a problem.  As they Review a Request, they discover a problem and they ask a question - and then they often continue their Review.  They can't complete their Decision until the questions are answered, but they don't have to stop each time a question comes up.

That's probably the root issue we need to solve... Knowledge Worker Tasks almost always have the potential to become "Collaboration Tasks".  Performing the Task raises questions which "other people" have to answer.  Someone else has to supply information before the Task can be completed, but work on other aspects of the Task doesn't need to pause.

Said another way, Knowledge Worker Tasks often spawn additional "Sub-Tasks" as they are being performed.  These Sub-Tasks are generally assigned to someone else, and they must be completed or canceled before the Parent Task can really be completed.

The Knowledge Worker needs to track the progress of these sub-tasks - and in many cases each of the sub-tasks may turn into a conversation.  At the highest level Structure remains, but at the worker's level it's highly collaborative.

We've got to make Knowledge Worker Tasks like this easier for Business SMEs to "Program".  Business SMEs understand these types of Tasks very well, and they can describe these Tasks very clearly - What's missing are tools to capture their descriptions and implement these Knowledge Worker Tasks as easily as BPMN can capture and implement Structured Process Logic.

Tools for Subject Matter Programmers - Learning from Turbo Tax

It's Tax Time again, and once again I'm reminded how lucky I am to have been born in the age of Turbo Tax.  Memories of my father cursing and swearing and sweating as he combed through boxes of receipts and scribbled notes while filling out his Tax Forms (and of the late night journeys to the Post Office to beat the filing deadline) are still clear and somewhat painful.  My father was a great guy, but you wouldn't think so if you saw him during Tax Season.

Tax Preparation Software fixed all that - especially when the solutions went online.  I won't say that preparing my Taxes is fun, but it's not hard any more...

Which brings me to my subject for this post - Tools for Subject Matter Programmers.

Subject Matter Programmers are Subject Matter Experts who know just enough about Programming to craft their own solutions.  Think of the folks in your office who are Excel Gurus... Those folks who are able to take their knowledge of your business and use that to create indispensable spreadsheets and workbooks (even Fortune 100 companies still depend on these).  Those folks are the Subject Matter Programmers I'm talking about.

I'd like to see a world where Subject Matter Programmers can tackle building something like Turbo Tax.  They'll always need help from System Programmers to build enterprise class solutions, but on their own they should be able to implement most of the Business Requirements.

Turbo Tax is mostly about filling in forms.  Tax forms are defined externally, in this case by Federal and State Governments, so the Subject Matter Programmer's job is simplified - but in general Subject Matter Programmers need good tools for defining forms.  Forms define a bunch of data fields that should be gathered, and a bunch of rules that govern the "valid" values for the data that is entered.  In some cases (like Turbo Tax), formulas are also associated with fields to compute additional values.

One nice thing about Turbo Tax is that it will prepopulate many of the forms by retrieving data from external sources (like getting your payroll data from your employer).  Under the covers, I'm sure these are Web Service calls to partners web sites.

Turbo Tax is also full of Wizards to guide you through filling out the underlying tax forms. Love them or hate them, wizards are sometimes useful... especially when the end-user only performs the tasks once a year.  When there's a great deal of information to gather, and when the specific information that needs to be gathered "depends" on previously gathered information, then a wizard is often called for.

Turbo Tax combines wizards with forms.  If you have no idea what you are doing, the wizards can guide you through all the steps.  If you have a bit more confidence, you can switch over to a specific form and "fill it out".  The beauty of Turbo Tax is that you can switch from one approach to the other.  You can start with a wizard, then fill out part of a form, then go back to the wizard.

This all works because Turbo Tax forms and wizards share an underlying data model, and underlying rules that govern the data model.  The forms and the wizards are "just" user interfaces on top of the underlying model.  Any number of tailored user interfaces can be built without having to duplicate the underlying data and rules.  The functionality that must be provided (tools to help me prepare my taxes) can be provided in many different ways (because they're build on a common model).

Finally, there's another factor of Turbo Tax that most Subject Matter Programmers will have to deal with: Forms and Rules Change Every Year.

Every year the tax forms change, and the rules that govern the tax forms change - so every year Turbo Tax must change their solution.  I'm not privy to the Turbo Tax code base, but I'll bet a lot of the application is generated from declarative statements that describe the data and the rules.

I'm sure I've missed something, but those features of Turbo Tax are the ones we want Subject Matter Programmers to be able to implement on their own:

1. Tools to define Data and the Rules that they operate on
2. Tools to generate Forms for gathering the Data (while honoring the Rules)
3. Tools for generating Wizards (as alternatives for the Forms)
4. Tools for connecting to Web Services to gather preexisting data (and to submit completed forms)
5. Tools for reviewing and modifying all of the above to deal with the inevitable changes that will occur over time

The devil's always in the details - but most of the tools listed above are available today (and most are getting better any day).  Maybe the day when Subject Matter Programmers build things like Turbo Tax is sooner than I thought?

Tools for the Task Masters

Nobody really likes being called a Task Master.  The phrase brings to mind a heartless overseer cracking his whip as a team of laborers drag endless blocks of granite up steep ramps to the top of the pyramid...

But the truth is that many businesses need Task Masters to keep things running smoothly.

Task Masters are the people who make sure the work gets done - by somebody else. They know what work needs to be done, when it should be started and when it must be completed, and they know the people who are available to do the work. They match the skills and availability of the workers to the work that needs to be done - hopefully resulting in smooth execution and happy workers.

Perhaps there are ethical considerations in the danger of empowering cruel and heartless Task Masters with batteries of tools to aid them in their diabolical profession... but let's for the moment assume that there are some Task Masters who are benevolent and wise.  Let's assume that they have the best interests of the workers and the business at heart, and help them do their jobs.

So what Tools does a Task Master Need?

To begin... the Task Master needs a Tool to help him know what Work needs to be done today.  What are all the Tasks that need to be accomplished by the workers that Task Master controls?  Hmm... we've already spotted another Tool, one that helps him know who all of the available the Workers are.

What does the Task Master need to know about the Work, and what does the Task Master need to know about the Workers?  The plot begins to thicken...

Each Work item is going to require specific skills to perform, and it's going to require time to perform.  If the Tool Master doesn't know both he can't make a logical assignment.  There may also be additional considerations for each Work item... Perhaps a special authorization is required to perform the work, and perhaps the work has a higher priority than other work.

Each Worker has specific skills, and specific authorizations.  Each worker has specific availability to perform work, and each worker most likely already has other assignments at various stages of completion.

The Task Master needs to know all these things about the Work items and the Workers in order to make logical assignments.

Even with all this information, the Task Master's probably still not adequately armed to do battle with matching Workers to Work Items.  In most businesses, dealing with Now isn't enough.  Today quickly becomes Tomorrow, and our Task Master has to worry about Tomorrow.

Tomorrow's Work Items are inexorably coming... and many of them can be anticipated today.  Good Task Managers take Tomorrow (and the next day and the next) into account when making assignments Today.  To arm them for battle, they need a Tool that shows them the Projected Work Items of the future.

Good Task Masters also learn from Yesterday. Were their efforts to match Work Items to Workers successful Yesterday (and the day before and the day before)? If not, then why not? How could they have done it better? Task Masters need a Tool to open a window into the past to help them do better today.

It should come as no surprise that the tools that Task Masters need start with those that enhance Visibility.

Heightened awareness of the Work:

• What it takes to complete the Work
• How long it takes to perform the Work
• The Priority of the Work
• How much Work we've done in the past and will likely do in the future

Heightened  awareness of the Worker:

• What skills and authorizations the Worker has
• How long it's taken the Worker to complete similar work in the past
• The Worker's current assignments
• The Worker's current and planned availability

So far so good... But now consider that the Task Master must match hundreds or perhaps thousands of Work items to Workers  each day - and that Workers can become unavailable and that Work can be blocked... Now our Task Master needs tools to filter out the overwhelming "unimportant" details of each day, to help him focus on those that really matter.  Our Task Master needs tools to block the mundane, but spot the crucial.

So there's our challenge as Tool builders - Task Masters need tools to increase their Visibility into Things That Matter Now.  It's fairly easy to figure out all the information that might matter, but it's not so easy to figure what matters now.

Figure that out, and your Task Master's Tools are going to be awesome.

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