Stevey's position is that Object Only Languages are silly... at least that's how I sum up his blog.
I couldn't agree more, and I couldn't have said it better... I've tried several times:
My first attempt to express my concerns about "Objects Only" was back in in November of 2003: UML and Process Definition for Java - JSR 207. Looking back, I realize that I should have just said "Object Only Modelling is a dumb idea".
For the record... "Process Only Modelling" is also a dumb idea. To borrow Stevey's metaphor, a Kingdom of Verbs is just as silly as a Kingdom of Nouns. Let's all move to the Kingdom of Sentences :-)
When you know these answers, then start your development efforts with the process diagram and use that to drive your development path in this order:
It's absolutely critical that you do these steps in this order at the outset of your project... and once you are done you've got to do the following:
Drive through ALL of the process paths with your Business Sponsors.
If you follow these steps, then you will expose the flaws in the process flow long before you've wasted any time coding up a fancy UI that is WRONG.
The process should drive the UI, but often our haste to show a sexy screen to our Business Sponsors the UI ends up locking us into a bad process model. We've all made this mistake, and we know from experience that it screws things up for the rest of the project's life.
Everyone focuses on UI. It's the most visible aspect of a project and the easiest to have an opionion about... But in truth the best UI in the world won't make the wrong process right.
Yes indeed... the UI development tools in some BPM suites often require super-human efforts to build the sexy AJAX powered screens that are all the rage, and often you'll end up developing your fanciest UIs with supplemental tools. But that's not why some BPM projects fail...
BPM project's fail when the project team doesn't follow the steps of Process Driven Design that I've laid out in this blog entry. If you've had problems with BPM... try it my way next time. I think you'll be pleasantly surprised if you do.
The One Laptop Per Child initiative may not be perfect, but why not support them anyway?
I ordered mine today:
Confirmation
Thank you for participating in Give One Get One. Your donation will bring education and enlightenment to children of the developing world, and, in recognition of your gift, you will be receiving an XO laptop for the child in your life as well. If you have any questions or problems, please contact One Laptop Per Child at service@laptopgiving.org. Should your employer wish to match your donation, we are a 501(c)(3) organization and our EIN# is 20-5471780. Thanks again, and welcome to the One Laptop Per Child community!
Merci de votre participation au programme Offrez-en un, recevez-en un ! Votre don servira à l'instruction d'un enfant d'un pays en voie de développement ainsi qu’à son enrichissement personnel. En remerciement, vous recevrez un portable XO pour votre enfant. Pour toute question ou problème, veuillez contacter Un portable par enfant (OLPC) à service@laptopgiving.org. Si votre employeur souhaite compenser votre don, sachez que nous sommes une organisation 501(c)(3) et que notre numéro d’identification d’employeur (EIN) est le 20-5471780. Merci encore et bienvenue dans la communauté OLPC !
Gracias por participar en Dé uno, reciba uno. Su donación ofrecerá un acceso a la educación y al conocimiento a niños del mundo en desarrollo, y, en reconocimiento a su regalo, Ud. recibirá otro portátil XO a cambio para el niño en su vida. Para cualquier pregunta o inquietud, favor de comunicarse con Un portátil para cada niño (One Laptop Per Child) a service@laptopgiving.org. En el caso de que su empleador deseara igualar su donación, somos una organización 501(c)(3) y nuestro número de EIN es 20-5471780. Gracias nuevamente, y ¡bienvenido a la comunidad Un portátil para cada niño!
That's already too much material to cover on one elevator ride... I'd better give it a rest for now or you're likely to take the stairs the next time you see me on an elevator :-)
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?
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.
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...
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.
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.
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.
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.
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?"
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?
From the very beginning, the core of most programming has been Process Definitions and Data Structures. BPM is our latest reminder of that.
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.
Continue reading at my other blog...
]]>