01.18.07
Posted in .NET, Application Development, Java, Rich Internet Apps., Web 2.0 Apps at 12:05 am by Tony Baer
History doesn’t repeat itself, except when it does. With Web 2.0 renewing focus on bulked up clients, many of the more advanced Ajax tools are starting to resemble the client/server 4 GLs of a couple generations back. OK, today you’ve got some added tiers between client and back end database. But when we look, not only at the cool new things sported by various Ajax tools, but the dynamics of the market, somehow we can’t help but think that we’ve time traveled back to 1994.
OK, there are some architectural differences this time round. The logic is spawned on the back end, not the client. And so we’ve seen a raft of new features over the past year simplifying the task of simplifying the plumbing on the back end, so you won’t have to drop out of Java or some .NET language to handle interplay with Ajax-style rich clients.
But it’s on the client side where the 1994 resemblance comes in, and it’s not just because of the renewed focus on screen painting. While the heyday of client/server was driven by a formal standard (SQL) and a de facto standard (Windows), for the most part, each tool carried its own unique framework for painting widgets and connecting to back end databases (with some going the whole nine yards in bundling databases as well).
The end result was a competitive marketplace: Borland, which invented the integrated development environment (IDE), competed on the strength of its compilers; PowerBuilder, whose Data Window automated the generation of SQL to simplify connection back to the database. And of course, Microsoft, whose Visual Basic was so simple that it enabled a whole new generation of English, philosophy, and music majors to start second careers as programmers, transformed development tools into a mass market.
It was an interesting market, with each tool having sufficient market penetration and technology differentiation that there was real competition. By contrast, the next generation saw these differences largely flattened out, thanks to thorough standards from the JCP and Microsoft specifying every aspect of Java and .NET-compliant languages, respectively. And you had guidelines from Eclipse and NetBeans governing how tools interoperated.
Consequently, tools became commodities. Today, IDEs are practically give-away items that vendors use as loss leaders to get developers to buy the rest of their product line.
Fast forward to today, and you have rich Internet application development tools that compete based on their own unique frameworks and widget libraries that have so far evaded industry standards – unless you count the killer app Google Maps as enforcing its own de facto standard for interoperability. That’s akin to the old 4GL days, except for the fact that 4GLs didn’t have to collide with each other on the same screen because in 1994, there was no such thing as a mashup.
So it’s interesting that the OpenAjax Alliance, the group formed to control the chaos, is taking a much lighter weight approach to standards. Instead of standardizing widgets or legislating how Java or .NET objects handle XML dialogues spawning Ajax displays, they are attempting a more federated approach, like defining what comprises an event that prompts partial incremental page refreshes, or how to regulate traffic when several elements of a mashed up web page are communicating back to one or more webservers.
Why the lighter weight approach? You could explain it several ways. First, if the standards are peripheral, and therefore don’t touch the vendor’s core technology, there’s less chance you’ll need the attorneys around. Or maybe the toothpaste has already spilled out of the tube: with JavaScript having been around so long and the scripting language so loosely structured, you’d never be able to exert the same degree of rigorous control of strongly typed frameworks like Java or .NET.
Or maybe there’s another explanation: that the market has standards fatigue. It’s tired of long, drawn-out processes that legislate just about everything except the kitchen sink, stamping out innovation in the process. Maybe some of us pine for the diversity of the 4GL market after all.
Permalink
01.16.07
Posted in Application Development, Java at 12:05 am by Tony Baer
There’s been much speculation over the decision by the Eclipse Foundation’s decision to join the Java Community Process. In actuality, Eclipse decided to join three groups last week, including the Object Management Group (OMG), which is guardian of UML and other model-driven development initiatives; and OSGi, which is developing a services gateway for mobile devices.
Specifically, some are likening Eclipse’s JCP move to the US Table Tennis team’s setting the stage for Nixon’s subsequent visit to China back in the early 1970s, breaking 20 years of estrangement between the two nations. That’s because the Eclipse project has been associated with IBM, the JCP with Sun, which in this context, has been considered a surrogate for the rival NetBeans project.
Sun has previously accused IBM, which founded Eclipse, of forking Java. Meanwhile IBM chafed under Sun’s more equal-than-equal role at both the JCP, which governs Java standards, and NetBeans, an open source project for building a Java tooling framework. Given Eclipse’s success in transcending its IBM ancestry and drawing majority vendor support from the rest of the Java community, Sun mused publicly about joining Eclipse before ultimately declining to give up its lonely battle.
Astute observers, such as eWeek/Linux Watch’s Steven J. Vaughan-Nichols, have speculated that this might be an historic opportunity for both sides to extend olive branches given the fact that everything in contention – including Java technology itself – is now in the open source domain. The conventional wisdom has always argued, if Microsoft can present a united front with the .NET framework, why can’t Java get its act together in like fashion.
When we put the question as to whether Eclipse and NetBeans are now discussing interoperability, Mike Milinkovich, who heads Eclipse, gave us a terse one-word response: “None.”
But what if love were in the air?
Well, sorry. That boat’s already sailed. The power centers of the Java world dispersed beyond IBM and Sun to the point where the love’s now all around you.
Instead, you’ve got the “Rebel Frameworks,” the ones identified several years back by Burton Group analyst Richard Monson-Haefel. Providing kinder, gentler open source “Plain Old Java Object” (POJO) alternatives to J2EE, they include simpler servlet containers like Struts and Tomcat, EJB alternatives like Hibernate, and more approachable frameworks like Spring. More importantly, with it you have a dispersal of power centers, with these various efforts controlled through the likes of Apache (an independent body), Interface21 (a consulting firm), JBoss (now a division of Red Hat) and others.
Significantly, Java EE 5 was a response to the rebel frameworks, with its simplification of EJBs plus the introduction of Java Server Faces and Java Annotations that drastically reduced coding requirements.
While the frameworks have grown simpler, the world hasn’t. We’re tempted to say that Java development has adopted the fragmentation of Linux, except that in Linux, at least you’ve got one guy who still plays god.
Permalink
01.04.07
Posted in Outsourcing, Technology Market Trends at 12:05 am by Tony Baer
Is the inevitable always inevitable?
That popped into our mind as we read headlines last week of Ford seeking a partnership with Toyota to learn the famed Toyota Production System – just as GM sought 20 years ago when it set up the NUMMI auto plant joint venture with Toyota in Freemont, Calif.
Back in the 80s, the Japanese lean production machine (as epitomized by Toyota) was considered unbeatable, and the conventional wisdom was that it was only a matter of time before it sucked away the last vestiges of manufacturing from the western world.
Today, the conventional wisdom is that you can’t underprice Chinese manufacturers or match the productivity of India’s programmers, and that it’s certain that they too will become impossible to compete against. Over the past couple years, Tom Friedman’s book, The World is Flat, has become the newest business bible based on its premise that an interconnected world inevitably levels playing fields.
There’s little question that the Japanese lean production machine sparked a remarkable transfer of wealth to Japan in 1980s, and that China and India are effectively shifting the center of gravity in manufacturing, software, and back office processing. And there’s little question that the flat world is enabling emerging regions to join the world economy.
But there are invariably bumps on the road to inevitability.
Back in the 80s, we recalled articles posing the half-seriousl question on what Japan Inc would do after it bought California. Heck, it already snapped up Rockefeller Center. And inside executive suites, bootlegged translations of The Japan That Can Say No were must-reads.
Problem was, Japan’s success was built, not only on the dominance of its lean production machine. It was also built on a system of highly rigged trading rules demanding unfettered access to export markets, but severely restricting imports or the ability of offshore companies to set up shop in Japan.
Nobody realized what havoc that would eventually wreak. The huge entrapment of wealth brought by Japan’s unbalanced export machine begat a real estate bubble that practically bankrupted the nation’s financial system. Meanwhile, the arrogance of market leadership spawned delusions that Japan could extend dominance to the computing industry as well. Japan’s Fifth Generation Computing Project aimed to reinvent software through artificial intelligence. It foundered because Japanese culture lacked the necessary individualism and creativity.
Similar cultural issues, institutional hurdles, and overconfidence will trip up any aspiring economy fixated by the dream of inevitability.
India has competed on a huge, educated, and highly motivated workforce, backed by training in newer practices, while China has traded on basement wages, an absence or regulation, and the ability to ramrod infrastructure.
But the downside is that India has a highly bureaucratic culture that has infected some, although not all companies. Meanwhile, China lacks the rule of law and stifles civil liberties, placing at risk the kind of creativity necessary to allow it to advance higher up the value chain. And it’s kept its currency at unrealistically low exchange rates (sound familiar?).
In a recent panel, Tom Friedman recalled a comment from his grandmother, that any country that censors Google would only get so far.
Of course, it could be argued that obstacles and adversity can spur excellence, witness Russia’s technological and political backwardness that forced programmers to be more clever as they worked with primitive equipment. But keep in mind, they’re from a country that practically owns the game of chess.
As for the inevitability that the rise of offshore regions is a zero sum game, in actuality, it has changed the nature of manufacturing, back office processing, and software development. Rather than a sucking sound, the flat world stretches the value chain as design, customization, configuration, and final assembly are performed closer and closer to the customer. And once more, you’re hearing about a shortage of qualified software engineers, not just in India, but the developed world as well.
Unlike conventional wisdom, our manufacturing and software sectors are hardly dead in the water. What was supposed to be inevitable wasn’t.
Permalink