John Reynolds's Blog

October 2007 Archives

Monolingual web toolkits: Phobos vs. GWT

The JVM is well on its way to becoming a multi-lingual environment with support for Java, Javascript, JRuby, Groovy, etc. but I have to admit harboring concerns about polyglot programming within a single project. If at all possible, I prefer to use one language per project, but with browser-based applications that's been very tough to do. I've usually ended up with Java on the server side and Javascript on the client.

Fortunately, I can now dump either one language or the other... If I want to ditch Java I can pledge my allegiance to the GlassFish Project Phobos. If I want to ditch Javascript I can pledge my allegiance to the Google Web Toolkit (GWT).

Phobos looks really, really neat... you should really check out their screencast... but I have not had the bandwidth to even play with it. GWT also looks really neat... some of my colleagues at work have published their favorable experiences with GWT versus Dojo, and it certainly looks compelling... but once again I haven't even played with it yet.

Is it really worthwhile to use a monolingual tool? I think it is, particularly when you are trying to learn how to program. Once you've mastered one programming language it's fairly easy to pick up another, but mastering two (or more) at once seems to me like a bad idea.

As I might have mentioned before, I'm interested in teaching "normal" people how to program. Back in the good old days before that darn-old Internet things were pretty simple... I remember teaching a neighbor "enough" Visual Basic to "get by" in a few evenings. Learning "enough" to build a browser based application is dreadful by comparison...

I am thinking that Phobos might change that... Javascript seems simple enough for anyone to grok... but maybe I am kidding myself. Even Javascript has a lot of cruft.

On the other hand, GWT does liberate Java programmers from all of those nasty browser inconsistencies. For those who've mastered Java it seems like a natural... but Java seems like a poor choice for a first language to teach someone.

What do you think? Teach them Java or teach them Javascript?

"We don't see the need for BPM"

Several folks said "We don't see the need for BPM tools"... and I would like to address that in this blog entry.

I'm really not surprised that the average Java developer doesn't see a need for BPM... In fact I'm not surprised that the average worker in any industry doesn't see the need for BPM.

All of us who work for a living participate in business processes. All of us who interact with businesses participate in business processes.

Almost of us participate in business processes. We don't think about it much because we generally don't care what the full process is... We generally only care about the tasks that we have to perform within any process.

For example: When you apply for a loan you are a participant in a "Loan Origination Process". In general you really don't care about all of the steps of the process. You don't care about all of the tasks that the lender has to perform. You only care about the process step where you fill out the loan application and the process step where you respond to the lender's decision.

When you develop software you are a participant in a "Software Development Process". Speaking for myself, when I am working in "programmer mode" I usually don't care about all of the steps of the process. I only care about understanding the requirements, writing the code, and fixing any bugs that QA finds.

My Project Manger (PM) cares about many more steps of the software development process than I do. Project Managers have to coordinate the programmer tasks and those of everyone else on the project. Most of the PMs that I've met don't think of their projects as instances of the software development process... They tend to view their projects as schedules, which explains why those lovely Gant charts in Microsoft Project are pretty much all that they need in terms of tool support.

It's only when you get to a much higher level in your organization, perhaps to the VP of Development, that you find someone who might really worry about the whole Software Development Process. If your organization is large enough, the VP might be responsible for several projects that are running at the same time, with each project at a different point in the process.

As long as all of your company's projects are completed on time and under budget, your VP is probably going to leave your Software Development Process (SDP) alone. For some strange reason, all of the VPs that I have worked for kept tweaking their SDPs.

Development VPs mess with their SDPs to try to lower costs, to have more predictable schedules, and to just generally drive their employees crazy. They want to make more money. Meddlesome Development VPs like to find problems in the process, "improve" the process, and then do it all over again.

Your company has lots and lots of business processes besides your Software Development Process. Some are really mundane, some our critical to your company's bottom line.

All of your Corporate Officers are really interested in managing all of those business processes. Inefficient processes cost more, both in terms of expense and in terms of lost revenue, than efficient processes.

Managing a process...

The first step in managing a process is to know what the process actually is. This includes the steps that are done by people and the steps that are done by machines. I once found it necessary to gather a dozen people in a room to find out what everyone thought the process was, and then later discovered the process wasn't at all what they thought it was. Big companies like to spend lots of money to diagram their processes... which they then file away for five years until they do it again.

The second step in managing a process is to gather metrics... How long (on average) does it take for each step of the process to take? How often are steps repeated (presumably due to errors)?

The third step and fourth steps in managing a process are to analyze and actively manage the process. Use the metrics that you've gathered to analyze process performance, develop a better process, try it out and start all over again. That's Continuous Process Improvement.

All good BPM suites provide infrastructure support for all the steps needed to manage processes...

First: Know the process

At the heart of all BPM suites is a process engine that executes process definitions. These definitions are usually represented graphically using BPMN notation. Process diagrams are usually generated in conjunction with the business people who own the process... Please note that it's much more important that the business folks understand how to "read" the process diagram than it is for them to be able to draw the diagram... The process engine is going to execute the diagram, so if it's wrong the process will be wrong.

I like to say that processes are composed of Human Powered Services and Autonomous Services... Most BPM suites provide tools that help you build the Human Powered Services. These tools are basically form designers, and they're good for doing many business-task-oriented user interfaces, but they aren't meant to be used for designing "filthy rich" client interfaces... All of the good BPM suites provide interfaces that allow you to hook in virtually any client that you wish to construct. If you want a Swing application to perform a task, then you can write a Swing application and hook it in. If you want to use Netbeans or Eclipse to perform a task, you can do that too.

BPM is not about replacing all of the applications that you use. It's about coordinating the use of those applications to perform a process.

But back to knowing what the process is.... You know what the process is because you can always see it. The process definition is not scattered across multiple applications and background tasks. It's contained in one precise definition.

Second: Gather metrics

Since the process engine is managing the process, the process engine knows when each task is started and ended. The process engine knows who performs each task. This makes it incredibly easy to instrument a process.

Third: Analyze the process

All good BPM suites provide tools for analyzing all of those nifty metrics that you've gathered. The really good suites even let you use your historical data to simulate how a proposed process change would have performed in the past.

Fourth: Modify the process

With that analysis in hand, you can now go back and modify your process... This is really easy because, as you may remember, the process definition is in a single place.

I cannot emphasize how useful it is to have that process definition driving everything else. In essence, you have a process-centric view of your code base. In my pre-BPM days I would join a project and have to spend weeks to track down the code that was responsible for some specific process behavior. With a BPM tool, you can always start at the process diagram and "drill down" to the code you need to change.

But can't I just put all these features together myself?

Of course you could. What do you think all the BPM vendors did?

Wrong question... Will a client pay you to put all of these features together AND pay you to develop a process on top of that?

The optimist in me says: "Why of course they will!"

The realist in me says: "Why would they?"

Sounds boring... Why shouldn't I just ignore BPM?

There's no reason to pay any attention to BPM as long as you don't make your living building process-centric applications.

If the applications that you write only involve one participant, you'll never need BPM... but I encourage you take a good hard look at those applications because they may actually function better if they are process-aware.

For example... Every issue-tracking system implements multi-participant processes. Sadly the processes are usually hard-coded in these tools, but more and more you'll find that issue tracking tools (like Jira ) are providing web-service interfaces to interact better with the other tools that are used in a wider process.

Another example... Your favorite IDE. More and more we are seeing process oriented functionality creeping into these tools. Why not leverage an existing process engine (like Apache ODE ) and make those processes more flexible?

Parting thought...

From the very beginning, the core of most programming has been Process Definitions and Data Structures. BPM is our latest reminder of that.

Why do Java developers hate BPM?

Java developers hate BPM.

The preceding sentence is (of course) intentionally tailored to be controversial. People tend to read controversial blogs, and I'd like you to read this one. Now that I have hopefully grabbed your attention I'll tone it down a bit...

A lot of Java developers hate having to use BPM tools instead of the object oriented tools that they are comfortable with.
I work on a lot of BPM projects, and I work with a lot of other folks who work on a lot of BPM projects, and we have all encountered resistance from traditional Java developers. Java developers (in general) would rather use frameworks like Struts and Spring than be saddled with the constraints of a BPM suite.

Java frameworks like Struts and Spring are in the background... they provide just enough support to "set your creativity free" so that you can be a real programmer. You can build almost anything with Spring or Struts (if you've already mastered the intricacies of Java). They are light-weight, they're agile, and they look sexy on your resume.

BPM suites are in-your-face. They rob you of your creativity. They dictate to you how you will develop your application.

BPM suites make programming boring. They force you to use point-and-click and drag-and-drop tools to design your process diagrams, data models and forms. What's worse, they actually encourage Business People to model processes and design forms on their own... Fortunately most Business People are too intimidated to use these tools, but it does open the door for them to look over our shoulders and meddle in our affairs.

That certainly doesn't sound like something that real programmers would like, does it?

I'm not being subtle, am I?

BPM suites are a threat to traditional Java programmers. These suites are far from perfect, but even in their current state we can see where things are heading. The days of the Java Guru as indispensable are fading... We've used Java to build tools that make knowing Java itself less important, and that's opened up competition for us from folks who didn't spend years learning Java.

We're victims of our own success... and that's going to cost us.

That's why Java developers hate BPM.

This work is licensed under a Creative Commons License.