X
Business

Analysts point to Java EE complexity drag for SOA, but SOA ain't so easy either

If Java remains on a complexity-laden trajectory for applications development and deployment, and SOA benefits of reuse, agility, and consolidation can be attained without necessarily having to follow that trajectory, then the path of least resistance to SOA could and should well be paved by non-Java approaches.
Written by Dana Gardner, Contributor

I caught some grief when I came out quite a while back with an "Enterprise Java is becoming legacy" observation. Now analysis firms Burton Group and ZapThink are building more momentum to the thinking. Gartner said as much recently with its "development is dead" declaration.

Much of their disdain for Java EE 5 comes from burgeoning complexity, especially if SOA is prepared as a martini cocktail with Java as the vodka. But SOA, and some of the models and approaches being constructed for advancing SOA adoption, is itself in a head-long rush to complexity. I still re-read Adam Bosworth's trenchant observations from back in 2004 when I want to reset my reality gauge on effective application development. Ray Ozzie's wake-up note to Microsoft is also a worthy thought alignment exercise.

Curiously, SOA is often seen as both an agent of simplification and of another layer of IT complexity, depending on who you ask and when. This became clear at the recent Integration Consortium's Global Integration Summit in Boston. I asked a panel whether SOA was just another brick in the data center complexity wall, or an entirely new approach that will render past layering of complexity less, well ... complex. Agreement came down that it was both, mostly, sort of. At least for now.

Seen through the eyes of a systems integrator or IT consulting firm, SOA is complex to implement and operate, so they advise their clients on the tough, long haul and offer encompassing methodologies and approaches. To outsourcing organizations, however, SOA can make their ability to operate other people's businesses as sets of processes and related organizational boundaries much easier, with significantly reduced costs. Ditto for service delivery platform users, co-location shops, and SaaS purveyors. SOA is also a blessing if an M&A comes along and both firms are SOA devotees. There are some amazing SOA ROI stories: Ask HP about its internal experiences so far.

My recommendation is that almost any large organization should face the cresting path to SOA as complex and highly germane to each and every company. But that by making that journey they become masterful at SOA generally, and more importantly, expert at SOA within their own vertical industry and/or business ecology.

If you're going to go through the pain of attaining a SOA-engendered agility benefit, why on Earth would you not also want to then capture and hoard that agility internally, with a very firm hand on the tiller? Outsource the path, if you must, but own the destination.

If Java remains on a complexity-laden trajectory for applications development and deployment, and SOA benefits of reuse, agility, and consolidation can be attained without necessarily having to follow that trajectory, then the path of least resistance to SOA could and should well be paved by non-Java approaches. Open source frameworks such as Eclipse, and burgeoning SOA stacks such as JBoss JEMS begin to point the way.

So the balance to the acceptable level of SOA complexity should be whatever a critical mass of large enterprises can manage, not the cutting-edge adopters alone. This has hardy been determined. It would also be good if most corporations could get to SOA without a great deal of hand-holding. The rate of adoption of successful SOA overall should be directly related to the lessening of the complexity burden for SOA.

There's also the need to make SOA less complex or more appealing, or both, to the .NET alternative approaches, so that Java is not, in fact, an Achilles heel that pushes more companies into the open and waiting arms of Microsoft and psuedo SOA.

That clearly puts the impetus to a simplified set of SOA options on many software vendors, open source communities, and integration/support companies. So expect Enterprise Java to continue to de deployed widely to clean up and modernize older and existing applications and infrastructure, but it's the new applications build of, by and for services where Java's future is indeed iffy.

This is and has been, incidentally, my chief rationale for a fast-track to open source Java, if it's not too late already. A widely accepted level of open sourcing Java allows more of those in pursuit of simplified SOA to seek, build, and retain more hooks and levers to and from Java components and tiers, to give it a longer lease on life as an essential under-the-hood ingredient for SOA, even if it is not the primary engine for SOA.

Full disclosure: HP and Eclipse Foundation are sponsors of my BriefingsDirect B2B informational podcasts.

Editorial standards