Data Models that Mom Can Use?

Back when I was working on Tandy's DeskMate we were trying to build a personal computer "that Mom could use".  I think we came pretty close to that goal... Mom could use it.  Unfortunately Mom didn't want to use it :-(

Fast forward to today, and I am firmly entrenched in the wonderful world of Business Software Development Tools.  I'm not so much interested in building software for businesses as I am in enabling businesses to build their own software - or at least play a much larger role in building that software.

One aspect of enabling business dudes is BPMN - Business Analysts  and Programmers using this shared notation to carry on discussions.  BPMN is pretty good, and reasonably easy to learn - When used properly it does embower business dudes without pissing off the programmers (too much).

Unfortunately, a Process Definition just isn't enough.  It's important, but at best it's only half of the solution - You've got to define the Data too.

BPMN evangelist Bruce Silver is quite frank about this:

"Let's face it, without referencing data you can’t do a whole lot in BPM."

If you follow this link you'll see more from Bruce:

"Data modeling is a thorny issue in BPM because developers assume, often correctly, that business people do not understand all the technical details of data elements needed for optimum executable implementation." 

Guilty as charged... I clearly remember getting a "D" in Information Structures at UTA on my first attempt- perhaps I was preoccupied chasing girls at the time, but data modelling is hard and I don't expect business folks to "get it".

Still... we do need a Business/Programmer shared language for Data Modelling.  The business dudes need to be able to specify the information that they need to do all the things they do, while the programmers need to be able to augment and enhance (scrap and replace) those definitions to make the software actually work.

In all honesty I don't know what this should look like... but I do know from first hand experience that some very smart business people don't have a clue what a Boolean is (until I explain it to them).

What do you think?  Can we come up with a Data Modelling Notation that Mom can use? 

Just Enough to Not Be Dangerous

My blog entry on User Manual Driven Development prompted Chris Adamson to share some thoughts of his own as For Reasons Unknown over at java.net.  My blog entry relates my early experience of developing an application from a pre-written user's guide.   Since then I came across a very similar approach that's used by Daniel Brolund that he calls User Guide Driven Development... obviously great minds think alike ;-)

Chris's thoughts helped me boil down my premise to a single statement:

Programmers should understand the applications that they are writing.

You might think everyone would agree with that statement... but you'd be wrong.  Go look at the comments on Chris's blog.  My favorite is the following from James Browning:

"It's a lot easier for a typical developer to know if their IDE is useful than if they're building an accounting package"

Which is s good reason why the proposed methodology has limited use. I am currently on a contract in an insurance underwriters. I am working on their accounting package and for me to understand everything about how the software is to be used and why I would basically need a degree in accountancy.

That's why we have business analysts ;-)

James has a point, of course.  Most programmers will never understand everything about how a particular application will be used... But surely they should understand something about how the software is used.  If not, then programmers really are interchangeable cogs and we all deserve to have our jobs outsourced.

So what's the minimum?  When do you know "just enough (about the business) to not be dangerous"?

The same is true for Business people.  It's very important for the Business Analysts (that specify software) to know "just enough (about software) to not be dangerous".

Those of you who are sick of my blogs on Process Driven Design should stop reading now... I'm about to make my same old pitch...

Business analysts and programmers need a common language.  Programmers need "something to read" that tells them how the business works.  Business analysts (who specify software) need "something to read" that tells them how the software works.

Business Natural Languages are a big step in this direction.  Business Rules Engines are a big step in this direction.  BPMN Environments are a big step in this direction.

Business analysts don't need to know all of the aspects of the software, and programmers don't need to know all of the aspects of business... but both sides need to understand the common middle ground.

If you  follow my blogging it will come as no surprise that I think that BPMN is a great way of describing that common ground.  The business analysts draw the boxes and connect the lines - the programmers implement all the little details that make those boxes actually work.

BPMN is evolving, and there's a raging debate on just how expressive BPMN should become. Should BPMN just describe the highest level details of a process, or should you be able to precisely express a lot of details?  I tend to agree with Tom Baeyens's views... BPMN should stick to modelling and steer clear of execution sematics.

Regardless... I know from experience that (some) business analysts can learn to "think" in BPMN.  I know from experience that (some) programmers can learn to "think" in BPMN.  I know from experience that if you combine a BPMN literate business analyst with a BPMN literate programmer you will probably end up with a kick-ass managed business process.

User Manual Driven Development

One of the best jobs that I ever had was back in the mid-80's working for Scott Cutler at Tandy Electronics Research and Development.  I worked on the team that built the DeskMate II GUI shell and its associated applications.  This was back in the glory days when many vendors were still pushing their own graphical environments - Apple clearly in the lead - Windows not yet quite measuring up - Atari and Digital Research's GEM still viable contenders.

We wrote everything in C and 8086 assembler... Life before objects: Smalltalk was around but too much of a resource hog  for the Tandy 1000  (256K of RAM and a 5 1/4" floppy).  C++ was just a rumor as far as we were concerned... Structured programming was king.

Our development methodology was simple but effective... the marketing group wrote the deskmate user manual and we built the applications to match the manual.  To be more precise, the marketing group would write a proposed manual, we'd negotiate with them over what could and what couldn't be done, and then we'd build to the manual.

I guess you could call this User Manual Driven Development, and I think that it still can be a very valid approach.  In most respects User Manual Driven Development is very close in spirit to Test Driven Development - The function of the software is clearly defined, so it's very clear if the software doesn't do what it is supposed to.

Some time between the 80's and now we mostly abandoned the idea of User Manuals.  Let's face it... few users ever bothered to read the manual (Leading to the ever present RTFM reply on many support forums).  Few companies even bother much with online help... Users are mostly encouraged to just play with the software and learn by doing.

I'm not advocating a return to User Manuals... but I do advocate tailoring our development methodologies to return the programmer's focus back to the users.  The prime objective is always to satisfy the needs of the users... The users really don't care about object hierarchies, they don't care about Java vs. Ruby.  They care about being able to do what they need to do.

I think most of you will agree that some of the best software that you can find is software that is primarily used by programmers.  Eclipse, NetBeans, Visual Studio...  This comes as no surprise:  Programmers understand the needs of other programmers.  Since I understand the purpose of the software, and I know how I would like it to work, then I am extremely qualified and motivated to develop the application.

It always stuns me when I encounter an engineering manager who believes that his staff doesn't need to know how to use the product that they are developing.  I've heard people say "Just give us the requirements an we'll build it".  I simply cannot agree with this philosophy... Requirements are never enough.  Ever.

To write great software, you have to put yourself in the shoes of the user and walk a few miles.  Perhaps it's a bit like method acting... Unless you "become" the user you're just going through the motions.

Portable BPM?

One of the developers that I recently worked with asked me if the "stuff" that he was developing using Lombardi Teamworks could be exported to any other BPM development or deployment environments...  The answer is pretty simple: Nope.

The wider question is whether or not this will ever be possible... What would have to happen for a BPM solution to be truly portable?

BPMN 2.0 is working towards "Enabling the exchange of business process models and their diagram layouts among process modeling tools to preserve semantic integrity". Is that portable BPM?  Maybe... but maybe not. 

There are several elements that would have to come together to make BPM solutions portable.  The first (and probably the easiest) step towards "portable BPM" is to adopt a standardized representation for the Process Flow.  BPEL somewhat accomplishes this... You can create a BPEL process definition with a number of tools, and import that definition into several of the existing BPM development suites (Teamworks included).

The main shortcoming with BPEL used to be its lack of explicit support for Human Centric Services (as far as BPM is concerned) .  BPEL4People seeks to address this shortcoming... and there are a couple of implementations available (from Intalio and Active Endpoints).  

Adding people to BPEL shouldn't be that hard (conceptually).  To a good Process Engine a Human Powered Service looks pretty much like any other Asynchronous Web Service.  Send Data to a Service, Retrieve Data from the Service.  If my Process Engine can orchestrate asynchronous Services then Human Powered Services should be a snap.

Note to those who are actually using BPEL4People... I haven't had time to play with it yet.  Please share any insights that you have on how well it meets its goals.

One nasty little detail that often crops up when dealing with people (in a business process) concerns  determining which people should be able to perform the Service.  I've worked on quite a few managed business processes where the logic for getting tasks to the right participants was far from trivial.  It would be nice if every task could be assigned to the members of a group or to people who have been assigned a specific role... but sometimes you have to figure out "who should get what" based on very dynamic criteria.  Portable BPM will have to address this - perhaps by incorporating external Routing Services (return a list of users).

So... If we can define the Process Flow in a portable format, and we come up with a portable format for specifying routing logic, then we are still left with those darn Activities.  How can you make Activities portable? 

BPEL is Activity agnostic... BPEL choreographs Services.  Implementing those Services is somebody else's problem.  BPM suites, on the other hand, pretty much have to implement Activities or nobody will use them.

Some BPM suites leverage XForms to implement Activities... That's a good approach, but I just don't think that you'll ever convince everyone to use XForms.  Some folks demand Filthy Rich Interfaces for their Activities that are beyond what XForms can support.  For those of you who are using XForms, please tell me if I've underestimated XForms' abilities.

I think the answer here (to reach the Portable BPM goal) would be to package Activities as separately deployable entities.  If you could export a single Activity as a deployable entity, then you could theoretically use that Activity in another BPM suite... You probably couldn't change the Activity, but you "could" use it.

So... If we have portable Process Definitions, and if we sort-of-have portable Activities... have we reached our goal of Portable BPM? Well... maybe.

There's a awful lot of stuff in a BPM solution that's beyound the process flow and the participant activities.  Increased Process Visibility is a big driver for most BPM projects (UPS Envy).  Process owners (managers, etc) want "Dashboard" access to a variety of reports - both real time and historical.  Generating those reports requires accessing a lot of business data, some of which is available to the process engine...and some of which belongs to a system of record.  It's not immediately clear to me how this aspect of a BPM solution could be made portable.

I don't think I will hold my breath waiting for truly portable BPM.

Fortunately for developers... the lion's share of the skills that you'll need to be successful with any BPM suite are portable.  Process patterns are process patterns.  Service interfaces are services interfaces.  A good Task-Oriented User Interface is a good Task-Oriented User Interface.  It's just all of those nasty little implementation details that you'll have to worry about ;-)