When someone in a corporate boardroom decides what their IT strategy is going to be, it isn't based on what language or software architecture they will use, but on how a system can provide value to their business. Very few organizations buy their hardware and OS first, and then tool up to write a bespoke solution that meets their business needs. In my first job I worked for a software house that built specialized insurance applications. Companies put out tenders for business that we responded to, and whether our products or a competitors' were chosen was based on the value proposition in the boardroom. The hardware, platform, and application server were dragged into the sale because they were required by the solution, but the app was always the endpoint that drove the purchase. As a software house we provided different configurations of the app that ran on different platforms and middleware. This was done for several reasons: to ensure we didn't have a dependency on a vendor lower down the stack and get maximum leverage by playing them off each other and also because some companies would standardize on a particular platform due to existing applications or an IT infrastructure that needed to be adhered to.

What has occurred over time is that companies have a myriad of applications sold to them by different vendors, perhaps one for HR, another for supply chain, some customer relationship management, accounting apps, and so forth. The stack of middleware, operating systems, and hardware that runs beneath the apps is often a mixed bag whose entropy increases as corporations merge or acquire one another. The IT check that gets written each year gets shared across everyone involved in the pie and the total cost of ownership grows as everyone takes their slice. The mismatch of heterogeneous applications and corporate data makes the overall business picture chaotic and sometimes anarchic.

One solution to the problem of heterogeneous and disparate systems is to migrate and consolidate on a single architecture. The problem with this pangaea is that it's very costly and difficult to achieve and adds very little core value to the business. Whenever I attend an event where customers and IT companies mix together, I'm always puzzled by the dichotomy: on the one hand the latest technology and software releases are being peddled by the vendors, while the IT departments are often several releases behind and are perfectly happy to remain on the existing infrastructure. What usually forces them to migrate is when a particular feature is only available in a newer release; in reality they'd be happy to just get the value the feature gave them in their existing version. A bad migration experience that cost someone a few weekends might be at the root of their reluctance to move, coupled with the adage "don't fix what ain't broke." A bank I talked to recently admitted to having three 40-year old Dec PDP 11 machines that they need to move to a new data center, but are reluctant to touch because they haven't powered down since 1995. They're not alone in being a highly successful business that, given the choice, would rather allow the status quo of systems to remain. They're happy to add value by growing the communication and sharing each application's individual value. In a nutshell I think this is basically what service-oriented architecture is all about - by recognizing this need and providing an architecture where, instead of having a big central application onto which everyone migrates to, the end-points publish their functionality and communicate directly with each other.

There was a time when Java tended to position itself as being the answer to the given problem, whatever the question was. Conference presentation foils peddled architectures with a J2EE application server in the middle, while other systems took part by using JCA and JMS. This Java-centric view, however, doesn't necessarily work well in all scenarios such as where a back-end database becomes bottlenecked by unoptimized fine-grained SQL calls thrown at it by the app server's EJBs. When I first heard about Web services, the explanation given was that they were "HTML pages for non carbon-based life forms." The simplicity of usage and large-grained transaction-based nature of the Web could now be enjoyed by programs talking to each other at a functional level. To enjoy this freedom, the existing enterprise applications need only publish their services at a sensible level of abstraction, and no longer have to learn Java protocol to play with the middleware. Java will play in this space, as there is still the need for application middleware to handle the routing, scaling, and management of the service calls. What it means for J2EE is that it will no longer be at the center of a Copernican middleware universe, as data will now flow in all directions and the real value comes from adding new applications, not at the top of the stack, but in the middle to glue, mediate, broker, and analyze. Java must reposition itself to play in this heterogeneous topology, not by asking to run everywhere and have others understand its model of programming, but instead to consume existing technologies and treat them as first class peers. Java can no longer view its being ported to each and every legacy platform as an end-game strategy of engulfing and extinguishing the existing apps. Instead, perhaps JVM architecture needs be extended to natively support other languages so disparate programs can run side-by-side in the same physical application space. Rather than the app server attempting to tackle difficult tasks such as batch or DRDA, perhaps Java needs to be able to speak more tongues, with the end game being to embrace the existing languages, APIs, and protocols already in place.