BusinessScript - COBOL-izing JavaScript?

My friend Scott Francis recently posted some thoughts on Server-Side JavaScript over on his BP3 blog... We're both Lombardi Teamworks affcianados and well aware of the advantages of using the same language on both the Client and the Server.  It's a safe bet that JavaScript is here to stay.

JavaScript was created by Brendan Eich to give Web designers and part time programmers a "glue language" for adding dynamic behavior to HTML coded Web pages.  Brendan succeeded beyond his wildest dreams in making Web pages dynamic... but not so much on his goal of creating a language that was easy to use by amateurs and novices.

My work involves a lot of interaction with business people who aren't frequent programmers... and I often introduce them to JavaScript.  Mostly they "get it"... but usually they get a bit frustrated at the tedium required to do really common things.

Try explaining to a business person turned part-time programmer the JavaScript (and DOM knowledge) needed to add two numbers that were entered on a form and display the result.  It's painful... especially if the business guy already knows how to do the same thing with a spreadsheet.  It only gets worse if they need to deal with currency math and nicely formatted outputs.  Simple things are surprisingly hard to do.

A relatively easy answer to this problem is to guide business folks towards business-focused application development suites - Essentially use a tool to generate forms and spreadsheets and let the tool figure out how to transform the input into a Web-based application.  This is certainly a viable approach - but it's generally a proprietary approach.  Language-based approaches like JavaScript tend to be "open" approaches... the skills that you learn can be applied to products from a number of vendors.  Tool-based approaches tend to be "closed"... the skills that you learn to master one vendor's tool aren't easily transfered if you switch to another vendor's tools.

That's why I'd like to see an Open-Source-Business-Friendly dialect of JavaScript.  Despite the "no coding necessary" promise of many vendor's tools, you almost always have to write a bit of code somewhere... and I'd like to see that code written in a scripting language that is a lot easier for me to teach to business folks who are occasional programmers.

From my own experience, I can state that JavaScript becomes a lot "friendlier" to business folks when you augment it with the "right" function libraries... and there are some tremendously great JavaScript function libraries out there.  I also know that JavaScript becomes a lot "friendlier" to business folks if you don't mention some of its features - If you want to clear the business folks out of a room, just start discussing anonymous functions.  Many of the folks that I teach a bit of JavaScript get off to a pretty good start, but then they start googling for additional answers and get hopelessly lost.

Perhaps we need a brand-new language that is as explicitly focused on developing business applications as COBOL was... Probably something that generates JavaScript (so it will run in every browser) but something that isn't quite JavaScript to keep "occasional programmers" from hanging themselves with some feature or technique (found via Google) that they don't quite understand - let's call it Business Script.

I'm not smart enough to design Business Script - I see people struggle and I can make suggestions, but I don't really know the root causes of confusion.  Professional Programmers are pretty happy with the status quo...  so my bet is that the successful design of Business Script will have a lot more to do with the Psychology of Programming than with Software Engineering.  BusinessScript needs to be more, and less, than JavaScript - but it's not going to be easy to figure out the right mix.

Easy or Hard? - Business Programming and Software Engineering

Business Programming ought to be easier.

There's a perpetual argument in the programming community about whether or not programming has to be hard.  I seem to write a blog entry about this topic every year or so, and I'm a bit overdue... so here goes another stab at it...

Programming is the act of transforming requirements into something that a computer can execute... thus the first step to successful programming is to get your requirements right.  For the sake of this posting, let's call the person responsible for dictating the requirement "the client"...

There are various software development methodologies... but generally requirements are transformed into a functional specification - a very precise written description of what the software should actually do.  As far as "the programmer" is concerned, the functional spec is the bible - if the client doesn't put it in the spec, then it won't get implemented.

Once the functional spec has been agreed to by both the client and the programmer, the programmer usually takes over and starts coding.  From this point on, the client often has no clue what's going on "under the covers" - all they see is the results when they test to see if the software matches the functional spec.

What does this have to do with programming being hard?  Stay with me, I'm getting there...

Sometimes it's really, really hard to implement a requirement.  A simple requirement like "get the customer's credit score" might require a tremendous amount of infrastructure plumbing to actually pull off.  You probably need web service connectors, some sort of federated trust with the credit agency, etc.  You have to deal with service outages, latency due to transaction load at the service provider, etc.  It can make the programmer's hair turn gray.

Building software infrastructure and tuning solutions to provide optimal performance requires Software Engineering skills.  These aren't the sorts of skills that you pick up in your spare time.

When programmers are presented with hard problems they solve them.  That's what programmers do.

Unfortunately, programmers often solve problems in a manner that obscures the functional requirement that caused the problem in the first place.  The business requirement (get the customer's credit score) often gets lost in a forest of code.  The trail of bread crumbs that leads you from  the functional requirement to the code that implements the requirement ends up very hard to follow.  There are twists and turns and ups and downs and before you know it you're getting dizzy.

Some requirements are going to be hard to implement, so some aspects of programming are always going to be hard - but it's this absence of a clear map from requirement to implementation that ends up making most programming harder than in has to be.

If the "requirement to implementation map" was maintained by the programming environment environment itself, then most programming would be easier.

 I've seen the proof of this in my own work with BPM solutions -  In a BPM development suite the process requirements are documented by drawing a process diagram (usually using BPMN symbols).  The diagram is the functional spec for the process.

The task of transforming the functional process requirements to "code" is automated.  The mapping between the process requirement and the implementation is obvious.  What you see is what you get.

With a BPM suite, programming is easy - at least as far as implementing the process requirements goes.  When you get into the non-process related aspects it can still get messy... but I hope you see my point.  Those BPMN "maps" keep things really clear... and "all you have to learn" is how to make those maps.

Software engineering skills will still come into play in most programming projects - there will almost always be problematic aspects that require thoughtful engineering solutions - but to make things easier we have to constrain those solutions to fit within the boundaries of the "requirement to implementation" map.




That's the key to making "business" programming easier... Build more tools that help programmers and their clients "make their maps" and build more software engines that "follow those maps".  This isn't a new idea - software modeling tools have been around for decades, but they've often lost their way and focused on modeling the software engineering aspects rather than the business requirement aspects of the problem.

Focus your development tools on the business functionality of the problem and programming the business functionallity will become easier.  We've done that with the process aspects, so now all we have to do is deal with the data aspects and the business rules - Piece of cake :-)

Departmental BPM joins Enterprise BPM - IBM Acquires Lombardi

I agree with Forrest Gump's assessment:

"I don't know if we each have a destiny or if we're all just floatin' around accidental like on a breeze... but i think, maybe it's both. Maybe both are happening at the same time..."

Whether by destiny or by accident, this week IBM announced that it will acquire Lombardi Software and my professional life got a whole lot more like a box of chocolates.

As a Lombardi employee there's not a lot that I am at liberty to say about this, and I don't really know any of the details anyway, but I wanted to throw in my two cents regarding the mention of "Departmental" versus "Enterprise" BPM in the announcement.

There are many many approaches to BPM adoption in a company, but if you just look at the ends of the spectrum you can categorize the extremes as "Top Down" versus "Bottom Up"endeavors.

"Top Down" BPM is a great idea - That's where your company executives make a firm transformation commitment for the entire enterprise.  Beyond just rolling out a few managed business processes, the entire IT infrastructure of the corporation needs to be analyzed, expanded, and updated.

"Bottom Up" BPM is also a great idea - That's where you have an operational problem that could really benefit from the application of BPM, so you take the bull by the horns, attack the problem, and deploy a managed business process to save the day.

The "Top Down" approach is most likely going to be an SOA based - ESB centric - BPM solution.  A lot of hard-core, high-powered Software Engineering is involved when your entire company depends on the solution - and that sounds a lot like IBM to me.

The "Bottom Up" approach is much more of a "just get it done" approach.  You need to deploy a managed business process as soon as you can.  Stop the bleeding now.  Once you've got the process deployed, you can evolve the solution over time... but time's money and you've got to do something now - that sounds a lot like Lombardi's Teamworks to me.

It's not really a technology issue - Lombardi's solution scales quite nicely.  It's a methodology issue...  Some tools really enhance the "Top Down" (Enterprise) approach, while others really enhance the "Bottom Up" (Departmental) approach.

Offering BPM tools that support both types of projects seems like a pretty good idea when you think about it, because (as Forrest muses) "maybe both are happening at the same time".

Process Debt and the Business Process Developer

My friend Scott Francis has authored an excellent blog posting on "Process Debt and BPM".

Scott's definition of Process Debt focuses on when our organizations fail to adapt to a changing business climate:

"If you rolled out a process two years ago and haven’t made any tweaks in the meantime, I believe you have acquired process debt – a steady, growing gap between what your software and processes are designed to handle, and what the reality of current business conditions requires." 

That steady, growing gap between what your software does and what your business needs is inevitable and inexorable. It's the real demon that business programmers need to slay.

My work is primarily with folks who are embarking on their first BPM project...  I help them implement their first managed business process with as little pain as possible, and I always goad them to "just get it done".  Process Applications aren't supposed to be pretty, and the longer it takes to build and deploy them, the longer it will be before your business realizes a return on their investment.

Despite preaching "just get it done", we mustn't forget that the process application that we are building today won't be what the business needs next year.  The business universe is in constant flux, and our solutions will likely be dated as soon as they are deployed.  We have to build our process apps with an eye to changing them in the future.

As Business Process Developers we really have to exert that extra effort to keep the linkage between each Process Requirement and how we have implemented that Process Requirement as clear as possible.  If you can't pinpoint how a requirement has been implemented then you can't easily adapt your code when that requirement changes.

Even with a great BPM suite, it's really tempting to implement process logic "where ever you need it".  For example, how many times have you embedded client-side JavaScript on a web page to implement a process rule?  I'm certainly guilty of doing this, and I know better.  If you aren't careful, your process logic will end up scattered across web pages, stored procedures, AJAX services, etc.  Your BPMN diagram may be clean, but under the covers it's a mess.

Hidden process logic may be expedient, and it may even be necessary, but it's the single biggest obstacle to continuous improvement of your process applications.  Be sure that you know where your process requirements are implemented, and put it in writing for those folks who will inherit your code down the road.

If we maintain a clear linkage between our process requirements and the "code" that implements those requirements, then the cost of adapting our process applications will be lower - and if the cost of adapting our process applications is lower we should be able to pay off those process debts a whole lot sooner.

Process debt will happen... it's up to us as developers to reduce the cost of addressing those debts.