Java Is A Dead-End For Enterprise App Development

Before Java was invented, one of the key industry trends was to increase the productivity of both developers and end users. For example, fourth-generation programming languages (4GL) such as Powerbuilder, Progress, and Uniface provided professional developers with faster ways to develop business applications than using COBOL, Pascal, C, or C++. For end users, tools such as Dbase, Lotus Notes, and Visicalc provided them with the unprecedented ability to create mini-apps without the need for professional developers. In the early '90s, this productivity trend was thrown into a tizzy by the Internet. Now, software vendors and enterprise application developers had to rush to write a whole new generation of applications for the Web or risk becoming irrelevant. The Internet forced developer productivity and 4GL’s to take the back seat.

Java Was At The Right Place At The Right Time For Web Applications

Java was designed in 1990 as an easier and more portable option than C++ to develop embedded systems.  The invention of the WWW in 1993 started a meteoric change in IT application development. Sun Microsystems moved quickly to take advantage by selling “network” servers like hotcakes and offering Java as the platform for Web development. Most other software vendors were caught off guard and Java became the de facto Internet development standard for enterprise Web application development.

Fast-Forward 20 Years

Forrester data reveals that Java is still firmly planted in enterprise IT shops for custom-developed applications (see figure). But, data always tells us what happened in the past and does not predict the future. Application developers should also not make the mistake that adoption means goodness.

Java is not going away for business applications, just as COBOL is not going away. Java is still a great choice for app dev teams that have developed the architecture and expertise to develop and maintain business applications. It is also an excellent choice (along with C#) for software vendors to develop tools, utilities, and platforms such as BPM, CEP, IaaS, and elastic caching platforms (ECP). Software such as operating systems, databases, and console games  are still mostly developed in C++.

 Java Has Served Its Purpose, But Now It Is Time To Move Forward

Java development is too complex for business application development. Enterprise application development teams should plan their escape from Java because:

  • Business requirements have changed. The pace of change has increased.
  • Development authoring is limited to programming languages. Even though the Java platform supports additional programming languages such as Groovy and  JRuby, the underlying platform limits innovation to the traditional services provided by Java. You can invent as many new programming languages as you want, but they must all be implementable in the underlying platform.
  • Java bungled the presentation layer. Swing is a nightmare and JavaFX is a failure. JSF was designed for pre-Ajax user interfaces even though some implementations such as ICEfaces incorporate Ajax. There is a steady stream of new UI approaches reflecting Java's lack of leadership in the presentation layer.
  • Java frameworks prove complexity. Hibernate, Spring, Struts, and other frameworks reveal Java’s deficiencies rather than its strengths. A future platform shouldn't need a cacophony of frameworks just to do the basics.
  • Java is based on C++. Is this really the best way to develop enterprise business applications?
  • Java’s new boss is the same as the old boss. Oracle’s reign is unlikely to transform Java. Oracle’s recent Java announcements were a disappointment. They are focused on more features, more performance, and more partnerships with other vendors. So far, it appears that Oracle is continuing with Sun’s same failed Java policies.
  •  Java has never been the only game in town. C# is not the alternative. It is little more than Java Microsoft style. But, there are new developer tools such as Microsoft Lightswitch and WaveMaker -- and traditional but updated 4GL tools such as Compuware Uniface and Progress OpenEdge. And don’t forget about business rules platforms, business process management (BPM), and event processing platforms that enable faster change offer by enterprise software vendors such as IBM, Progress, TIBCO, Software AG.

What It Means: Application Development Teams Must Find A Better Way To Develop Apps

Many enterprise application development teams are already using a combination of tools and technologies to overcome the complexity and inflexibility of Java applications. BPM is used to quickly define and change business processes, and collaboration suites like SharePoint and Lotus are used to respond to the increasing demands of long-tail apps. Progress Software’s responsive process management (RPM) combines the best of BPM and business events to help businesses respond to real-time events and change business processes. This is just a small sampling of the next generation of business application development tools

Clear standard alternatives to Java and C# for custom-developed applications do not exist. There are issues with many of the alternatives. For example, BPM tools are great for defining and implementing processes but a poor choice for implementing compelling user experiences. The market for application dev tools is beginning to change though. The next generation of app dev tools will:

  • Dramatically increase developer productivity.
  • Allow developers to delegate change to business end users.

You Must Transform To A Lean, Mean Change Machine

Application development teams should create a three-year application development strategy and road map to include architecture, process, talent, tools, and technology. All options and trends should be put on the table and up for discussion. Development platforms are not the only items to consider. Cloud computing and mobile, to name a few, are other trends that must factor into your new strategy.

Learn how to apply customer-centric practices to develop killer mobile apps with our complimentary report: Design Mobile Apps From The Outside In.

Categories:

Comments

Java's future

I've been looking at functional languages, which seems to be the paradigm moving forward and there a few built on the JVM. Scala and Clojure are both highly integrated into the JVM and are gaining momentum. I don't see the JVM going away and I don't think you will be able to separate Java from the JVM.

Josef, I agree that Java is

Josef, I think it is positive for Java that additional programming languages can be built on the JVM, but I do not think the Scala or Clojure are the way forward to enterprise business applications. The class of enterprise business applications I am talking about have user interfaces, often complex workflows, interaction with data and other systems and change frequently as the business changes. As someone who used LISP (Clojure) in the 1980's to develop applications, I think many would find it a difficult choice to develop a business application. I aknowledge that Java, Clojure, and Scala all have purpose. For example, Clojure could be a good choice for writinga utility that sifts through data to find patterns. It's funny because these "new" languages are a bit of back to the future just like I suggested in my post about 4GL.

Sir what is the meaning of

Sir what is the meaning of "Clojure" & LISP ? what are the languages comes under the 4th generation programmaing languages ? What is JVM & why it is necessary for JAVA?

4GL... Well... Actually new

4GL... Well... Actually new multi-paradigm (mainly functional) languages like Scala, Clojure and F# have declarative programming etc., which are considered to be 5GL.
But, Clojure and Scala are much non-enterprise driven and they have minor problems with JVM. JVM is very much developed for Java. (For example: No tail recursion)

F# looks very good; it is simple as Java, but still powerful as Clojure. C# (having some backward compatibility burden) goes towards F#, let's see how it will manage...

Functionally Motivated

I program exclusively in functional languages. LISP, F#, Scheme and Clojure are my bread and butter. This is because I have no bread or butter in my house. As a matter of fact I don't have a house - I'm living in a van down by the river. While I'm not working on finding a job I moonlight as a motivational speaker and I'd be happy to talk to your development team about how they too can experience the joys of functional programming.

What's that? You encourage the use of functional programming in your organization? Well lateeda... I can't see too good but is that Dick Stallman over there?

I absolutely agree with all

I absolutely agree with all points mentioned above. Java productivity is very limited. Technology and standard cacophony in Java is really amazing, most of the times I ask my self that main motivation behind it is "why simple when we can do it complex?". However I would also see major factors that would keep Java from being "nowadays COBOL" such as:
- Developers. There is a big number of developers who knows Java and it's frameworks. It is significantly harder to find good Ruby or JavaScript developers than Java developers. That is especially problematic for bigger companies with bigger IT departments.
- Scalable infrastructure such as IDEs, Tooling, etc. There is still quite problematic to find scalable IDE for Ruby or Scala. Though for smaller teams it's ok to work with emacs for bigger teams it might became unacceptable.
- Scalable best practices. Maintainability and development scalability for "new" languages is still a big question. It's usual to see 100 people working on one big system written in Java, where 100 people working on Ruby code is rather the exception.

Renat

I could never understand why

I could never understand why people would want to write business apps in what is effectively a systems programming language (same goes for C++). No wonder organisations complain about the lack of agility. Systems and Applications are getting highly complex due to the sprawled evolution of frameworks and scripting languages. A Chernobyl approach to legacy maintenance will eventually be required? There is definitely a gap in the market for a new enterprise 4GL.

A whole generation of app developers forgot

Stephen, Perhaps it is because a whole generation of application developers made their bones Java and don't know any better. Objective C is an equally interesting phenomenon because it is not the easiest to learn. Of course, that hasn't prevent developers from creating hundreds of thousands iPhone apps. I have seen many tweets on this post mention that the high adoption rate of Java proves that it is the best choice. I have personally designed and developed dozens of enterprise business applications using Java because that is what the IT department wanted. Firms love standards and Java became the standard because it was at the right place at the right time.

Java is more than a systems language.

First of all, I think the main reason so many people have such a problem with Java is that it enables a programmer to go as deep in code as he wants. Such power requires more discipline as well as more depth of understanding, and not all programmers can manage these.

For their part, business managers don't want to pay for seasoned programmers, so what they don't outsource, they hire cheaply. They're inclined to believe a scruffy young programmer who tells them their entire accounting system can be built cheaply in PhP. It's what they want to hear. Later, the project collapses, the scruffy young fellow escapes to a different job, and the managers have to justify their failure to their own bosses. You can't build a castle on sand, and you can't build enterprise applications on glorified scripting languages.

This is why Java isn't going anywhere, and currently is the #1 language for enterprise development. It's stable, dependable, and allows you to build maintainable, well structured code (assuming you actually know what you're doing -- it's not a language for dilettantes).

In any case, Java offers excellent tools for business application development. I recommend NetBeans and JDeveloper as good starting points.

I agree with Phil P. In

I agree with Phil P. In addition, if you need productivity and a 4GL like application development tool, check Servoy (http://www.servoy.com/). I recommend reading this article if you want to learn about Servoy and the new 4GL tools which you can use to develop cloud-optimized applications: http://www.ibm.com/developerworks/cloud/library/cl-3gl4glclouddev/index.....

BTW, Servoy is also rapid development tool to build Java (swing) applications, and you don't have to write any Java if you don't want to.

I agree completely with it

I absolutely agree with it

I do not understand why companies would want to implement their business critical application in a low level language/environment like Java or C++. In stead they should i.m.h.o use a 4GL or a very strong frame work to implement their app. This way they can keep the focus on the core business i.s.o the internal IT department which fails to deliver over and over again.

My 2 cents
Jasper de Keijzer

wait..what?

did you just call Java a low level language/environment?

I bet all of companies with

I bet all of companies with those PowerBuilder applications to maintain might have a different opinion.

As for other comments regarding Ruby, the author seems to have debunked jRuby so going with the OP that would not be a viable option as jRuby is a Ruby implementation running on a JVM vs. Ruby VM.

Why not do it in Python -

Why not do it in Python - which is more agile than Java from the language level. i.e. more readable from a developer perspective and also more maintainable (coming from a Java background). Python would likely to integrate the gap between what you call "low level environment" (which Java is clearly not) and high-level business rule development.

Btw, it would also be great to consider BPM and rule engines for Java. This may be the authors anti-thesis argument.

Try scrambling the indents ...

... in a Python script, then repairing the file. Then multiply the effort by a let's say 5% probability of occurence and maybe 1000 source files in a not so big enterprise project. Then you'll understand why Python isn't a good choice for large apps.

Something like python but with braces or some sort of delimiters might work, IMO.

java is low level ? compared with what ?

Seems a lot of people here has no idea what a low level is or a COMPLEX framework Is. Java has been the most popular thing last decade and has it's reasons. Works @ almost any platform and you can do almost everything with it. And also is really easy to implement thru the many frameworks out there.
Big companies will no bet on Ruby or another scripting language because they are not mature and they are limited. Is really not that important for the enterprise that you use 2 lines of ruby against 9393 of java to do the same thing. Java's scope is bigger than ruby, php, python, etc. Doc is better, community support is better, OS projects are better. Yes, some day java will fall for a better tech, but not now.

Abstraction of business apps

Rodrigo, There is no question that you do almost everything in Java. I have! The question is productivity in initial development and then ongoing changes. I do not believe Ruby or other scripting languages are completely the answer though. The scripting languages improve upon some of the mechanics of programming but not enough on the abstraction of ui, data, workflow, logic, integration, ... Sure you can cobble together frameworks just like in Java. But, those frameworks seem to change constantly. There seems to always be a newer better one. So, instead of spending time adding functinality to the apps you spend time tinking with a new framework. We saw this in Java with Struts, Hibernate, Spring, JSF, etc... Just like Hibernate abstracts data access, why can't we abstract the entire mechanics of the proigramming language?

> Just like Hibernate

> Just like Hibernate abstracts data access, why can't we abstract the entire mechanics of the proigramming language?

Yes, let's just abstract away the programming language! Problem solved.

The history of computing indicates that this isn't as easy as you make it sound.

If Java doesn't change, it's

If Java doesn't change, it's dead because it doesn't evolve. If Java changes, it's dead because people can't take the time to learn new things.

Well, it seems that it's dead anyway. As is any past or future technology.

Wow

Oh My God. This epitomizes narrow-mindedness and ignorance.

"Big companies will no bet on Ruby or another scripting language because they are not mature and they are limited."

Mature? Really? Python is over 20 years old...in fact a simple Wikipedia search shows that it is in fact OLDER than Java.

Limited? Limited how? Show me an actual "enterprise" application that CAN NOT be done in Python (or Ruby). I'm sure I'll hear performance as the "CAN NOT". When an application is profiled, how many lines of code are the bottleneck? (if the bottleneck is in the application code at all!) Certainly those bottle necks will likely be number crunching or heavy iteration involving small blocks of code. This can easily be overcome in C, C++ or using any of the excellent tools which make this blindingly simple (Pyrex, etc).

"Is really not that important for the enterprise that you use 2 lines of ruby against 9393 of java to do the same thing."

Yes, because developer productivity means nothing in the enterprise. Officers, board members and managers really hate the thought of less time, less bugs, less developers on staff and less cost overall.

"Java's scope is bigger than ruby, php, python, etc. Doc is better, community support is better, OS projects are better."

Yikes.

This

It really is important ...

"Is really not that important for the enterprise that you use 2 lines of ruby against 9393 of java to do the same thing." Rodrigo, I totally disagree with you on this point. Two lines of code can be error-free; 9393 lines will never be. A business application that has few or no flaws is preferable over a custom made but buggy application.

I'll take the bait

> Business requirements have changed.

They're always changing, why does that mean Java is not useful? A good java programmer can bash out a decent app in a matter of hours if they've got the correct tools for the job.

> Development authoring is limited to programming languages.

I don't even understand this point. A great thing about Java IS that you can run all these other languages on the JVM. Fine the JVM needs a few improvements to make it better for these languages, but the beauty of being able to call cross language makes the JVM an attractive platform. Someone who needs a functional language can still make use of existing well established Java libraries as opposed to having to re-invent the wheel in that language (DB drivers are good example)

> Java bungled the presentation layer.

We write all our code as restful services and write the UI code in the most appropriate language for the job (JS, Flex, C#). Pretty much all these languages allow for client side MVC patterns and typically your UI changes far more often than your server code, especially if you designed it well in the first place.

> Java is a 20 year old language based on C++. Is this really the best way to develop enterprise business applications?

Does it matter how old a language is? Surely it means that in the 20 years it's had it has been road tested, improved, best practices have been produced, quirks are well known, courses produced, books written. If anything I would say age is a good thing. A new language has the benefit of improving upon past mistakes a language may have had in its design, but to build up a wealth of knowledge and a community of such a scale Java has will take... 20 years I'd expect!

I know for sure that where I work Java will live on for a very long time. Teams are productive with it, hiring new people will relevant experience is easy and the wealth of expertise to create fast, stable applications far outweighs the benefits of trying to bring another language into the firm.

Matt

have to agree with Matt. In

have to agree with Matt. In short, this article is thin on specifics and gratuitous. Java has its faults, but they are hardly laid out comprehensively here

+1, sensational headline -

+1, sensational headline - lacking substance

+1 on Matt's comments

+1 on Matt's comments

+1. This article is pretty

+1. This article is pretty bad...

+1. I understand Mike's points, but the problem isn't Java.

Frankly, I'm surprised that people still want to build dialog boxes, connect them with multiple classes that bind the dialog boxes to various other classes, and get data persisted into a database. I think that I can agree with Mike there.

But I think that mentioning Java is a red herring. What does Java have to do with the pedestrian way that people construct their applications? Not much. Change Java's syntax, or replace that VM with something else (.net anyone?) and the same criticisms stand. Thus, none of the things here are specifically problems with Java. They are problems with all large-scale software development endeavors, no matter what the platform, VM, language, or other technology we choose.

People in big companies have some good reasons for using SQL databases. It seems that it took 30 years after the invention of SQL for anybody to be able to say (with pride) that they had found an application niche where SQL-based relational DBMS technology didn't work for them.

Java is one piece in the stack of "SQL server" corporate/enterprise software development. Java, COBOL, Visual Basic, Smalltalk. Choose any one, and exactly none of your problems go away. So what made this article about Java?

Mike obviously believes that by changing languages, the problem will go away. I'm sure he's not alone. But it's a false hope.

Warren

Ah. I see. The invisible silver bullet.

The invisible silver bullet that this article's author would like to propose is that everybody should say, use a 4GL.

A great follow-up article from Mike would be: "Why don't people use 4gl's more, if they're so darn awesome?". They don't even register in the 0.1% importance level in most corporate development, and yet they are (apparently) a kind of silver bullet.

I'll give one reason; Many 4GLs carry a heavy vendor-lockin penalty. Is there one commercially successful one without any lockin? Is there any 4GL that is widely deployed, and has an open source reference implementation available?

No. The 4GL world is closed, proprietary, and their "how much have you got?" pricing systems, makes even other enterprise grade software look cheap.

W

IMO it's not even that

Functional languages, while very nice toys for small projects, require a very bright and not that large team for development. Could you imagine a thousand average programmers working on a codebase consisting of a few million lines of Lisp? Without being able to keep most of the code private for each programmer, and without being able to enforce specific and rigid interfaces via the compiler, I can't see this happen.

Missing the point.....

"The 4GL world is closed, proprietary, and their "how much have you got?" pricing systems"

Last time I looked Oracle owned JAVA and Microsoft owned C#.

With regards to price, if the vendors claims of increased productivity weren't true then they wouldn't still be in business. If you can build business apps 3-4 times quicker and reduce maintenance overhead by 80% with a 4GL, the tooling pays for itself in the first 9 months of the first project. When an application life span is typically 5-10 years, the decision to go down this route commercially stacks up with lower project costs and greater business agility.

Ed

Disclaimer: My employer is LANSA (http://www.lansa.com/)

+1 doesn't go into details on

+1 doesn't go into details on what's lacking with java

1993? WWW == 1990

Worth noting: WWW was "invented" in 1990, not 1993.

Uniface?

If you are saying the Uniface is a better choice than Java, that tells me you have a think or two to learn about the IT industry. Uniface was a dead product years ago. Uniface only has 1 major customer (American Airlines). Every other major customer has jumped ship.

Uniface customers

Wrong...Uniface IS very much alive. We have a huge customerbase that is growing.

Uniface is definitly not

Uniface is definitly not dead!
It is a powerfull 4GL that has been around for over 25 years and has incorporated every major new technology that has been invented since then.
And we are pushing very hard to deliver modern internet application development while retaining the traditional Uniface 4GL values of productivity and platform independence.
And we have many major customers wordwide. Have been working for many multinationals with Uniface.

Agree with analysis, but need better direction

The big issue I have with this blog is that it makes a big, bold statement, but really doesn't give any good alternatives. In fact, it even states, "clear standard alternatives to Java and C# for custom-developed applications do not exist."

Personally, I think the bigger item to discuss is not what programming platform the typical enterprise should be using, but what the changing face of the IT department is. Have we reached the tipping point where there is enough off-the-shelf stuff available for non-technology enterprise so that the development group really becomes the integration and orchestration group? Or will it be something else?

"Standard" alternatives are unclear

Todd, This is a call to action for developers to find a more productive way to develop and maintain business applications. Java and C# are popular because they are the standard. But, there are tools and technologies that I mentioned in my post that begin to show us the way. The problem has been that few enterprises think beyond Java. That is starting to change now. I think off-the-shelf (aka COTS) software is a choice for commoditized business processes. But, I think custom-developed applications are more important now because they can help firms differentiate in those areas where differentiate leads to a cometitive advantage. That often requires faster development of custom-apps and faster change.

One key question is whether a

One key question is whether a company whose business is not technology would ever view its operational technology as a competitive advantage. Walmart is the low cost leader and does so by driving its operational costs to a minimum. Clearly, some of this is due to leveraging technology, but do they need custom software to do it today, or would off the shelf packages plus an orchestration/automation suite do it? I know you mentioned BPM technologies as a Java alternative, but I see that as solving a completely different problem of custom process development versus custom software development, which leads into my comment about the changing face of what the internal "development" team does.

Getting back to Java, if custom development of home grown tools is what is needed, I still see Java as a perfectly viable option. My own opinion is that the bigger problem is still much more with what we build than what tools we use to build it. Yes, we do need to monitor staff productivity (and I understand that's the focus of this article) and available of skilled resources in the market, but in the end, I can build my widget in Java, C#, Ruby, Python, or anything else, but if it's the wrong widget, no one will care what technology was used.

So, for companies that are building the right thing, is there a need for them to change? Possibly. Ultimately, what we build and how we build it are both important. Building the right things but missing the optimal timeline is also potentially damaging and you should be monitoring both. But, I'll stick with my opinion that what we build is far more critical (especially for run-the-business IT of non-tech companies) than how we build it.

Jumping Ship???

I notice that John Smith takes liberties on describing Uniface as a dead product. I would go as far to say he is very ignorant on IT issues in the world today. What I have found is that today there are many Companies searching for a development platform to redevelop aging appplications that have been written in languages such as RPG and others of that era. To say that 4GLs such as Uniface are dead, shows who has a lot to learn about the IT industry. Uniface and Progress are still very much powerful development tools that are growing quite substantially due to the incompetence of the likes of Java and C# being used in the wrong situations. Companies have forked out miillions to develop in Java only to dump it and redevelop in a 4GL. I suggest that John Smith do a bit more research before claiming the likes of Uniface being dead. Next time you get on a plane remember your ticket was probably processed by a Uniface application. Your parcel was probably delivered via a Uniface application, your payroll was probably processed by uniface application or at least in a Bank that uses Uniface..... it is still there just not a smoke and mirror show like Java and C# programmers like to make out....

Follow the comments on this

Follow the comments on this report here too ..

http://www.theserverside.com/news/thread.tss?thread_id=61352

The Tiobe Programming Language Index

Anyone that is seriously interested in the topic of this article (including the author) will likely be interested in reviewing and tracking the Tiobe Programming Language Index:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Don't give up your day job Mike

Oops this is your day job.

Oops its not!!!

Not my day job.....I live the life of 4GL.... have done since being involved with Java and J2EE, J2SE and C# etc etc.....probably before you thought of programming.
People have to realise we can do more with a 4GL than JAVA quickly. JAVA has it's place and I do not deny this, but Uniface and the like can eat this up for dinner when you programme an enterprise system. Why would you bother with building the basics when Uniface does this and lets you deploy over ANY environment..... I ask you?>????

Thanks for your support.

James, I don't plan to give up my day job as an analyst at Forrester. If I do need another job, I can always develop Java applications since that is what I did for 10+ years. :)

Java is the best programming language.

Java is the best programming language.
1) you can write java applications on a OS and run it on an other whith a JVM
2) there are many frameworks for any kind of application, requierements
3) there are many IDE free or commercial for every OS
4) it is opened to every kind of applications

BUT all of this required very good EDUCATION in Computer Science : a there are some problems with that...

Java Bull S###

How can you say that Java is the best programming language?? go back and learn some lessons from the others......
Java has it's place and nobody can deny, but this statement is stupid. A 4GL like Uniface can run under any environment but is not limited to a JVM. Many Java frameworks coming out every week.....ho Hum!!
IDE is the same for all in 4GL
Apps are open to ALL Via Dynamic API's
you know the best thing is 4,000,000 Java guys getting Sh$$$ money or we are seeking 100 Uniface programmers getting $great money......you tell me Java dudes!!!

Any one that wants a real job...contac me....

A hammer is the best tool?

Saying Java is the best programming language is nonsense.
Different applications require different languages.
You write a compiler in C, and an ERP, MES, CRM, banking or insurance applicatio in a good 4GL like Uniface.
The only merit of Java was that it was early in the internet market. But the internet is just a platform. Now other, specialized, languages are getting strong on the web the game for Java will end.

Doh

"BUT all of this required very good EDUCATION in Computer Science : a there are some problems with that..."

This is a compelling argument. I am not a fan of java. Now I realize that this is because I am stupid.

Java is as dead as SOA or XML!

Thanks Mike, for a realistic look at application development. Java won't go away despite its problems, much like SOA, XML or flowcharted BPM.

Everyone who has ever been involved or responsible for a large Java or .NET application project on any other level than writing code will agree with you. Surely, a 'good' programmer can hack an application in a few hours. But there aren't many good programmers and a single cute program doesn't yet make an application.

The main issues are modeling business requirements, framework design, code quality, testing, debugging, interfacing, code maintenance, integration, deployment, portability, and performance tuning in large applications. Additionally the versioning and compatibility of Java frameworks can turn into a nightmare. But each application environment has these problems and that's what has to be compared.

I agree that BPM misses the enduser focus and fails in business empowerment. But this is certainly one direction applications will need to go. It is interesting that you mention Progress RPM which is still very complex to implement and doesn't give much to the business users. I chose a model driven and preserving approach for the Papyrus Platform (http://www.isis-papyrus.com) to substantially simplify all of the above needs, but they still have to be performed. That is one huge problem for most businesses because, the immense cost of Java and .NET projects was a key reason for the IT outsourcing craze to India. I doubt that it was any less costly, but it has left most businesses without much IT skill. It will be difficult to bring those IT management skills back inhouse.

The ONE THING most IT people thinking in code miss is: 'How to empower the business!' Let them chose how to work with data, content, process, rules and presentation without needing a development project for each little change. That has to be and is the target of the Papyrus Platform. After creating a core data model and infrastructure, the business should be in control and not IT.

Isn't it strange? We have seen many new things coming in IT, but very few old ones disappear.

You have the vision

Max, Thanks for your comments. I think many of the readers of this post are missing the point that the future of application development is not yet another programming language like Ruby or Python. Model-driven approaches play a key role to abstracting the plumbing aspects of coding.