09.26.05
Posted in Enterprise Integration, Networks, SOA & Web Services at 2:39 am by Tony Baer
Who cares about the next big thing? The answer’s obvious, the IT infrastructure we have today will remain in place for a good long while. Paradoxically, that’s why a new technology, Services-Oriented Architectures (SOAs), is advancing past pilot stage across many organizations.
Services don’t replace legacy applications, they expose them and add value in new ways. Log onto FatLens, a concert tickets site, click on Coldplay, and you can find tickets available for the next concert in your area. Beneath the hood, FatLens is making a web services call to eBay for listings and buyer authentication. By contrast, traditional web applications would have forced you to manually navigate hit or miss through portals or search engines.
Services are evolving, just as web applications did a generation earlier.
Back then, Web apps moved from static to interactive. In the process, vendors had to make tough choices. IBM ditched the San Francisco framework once Sun’s J2EE gathered steam. Today IBM sells more J2EE than Sun.
Fast forward. Like FatLens, most services today are manual, where the end user is a human. On the horizon, organizations will find it profitable to daisy chain multiple processes into dynamic workflows where services consume each other. For instance, you might design an app that automatically requests a credit history service as a cost-cutting strategy. But if you’d like to make this a moneymaker, you might refine it to a process designed to stimulate business from your best customers. You would then orchestrate credit checks with policy-driven services also retrieving buying history and generating promotions.
But as you automate, familiar issues arise. Like whether the requestor is entitled to that service, their identity isn’t faked, and that their credit request message hasn’t been corrupted or falsely generated. And as you get serious, you will inevitably deal with quality of service issues, worrying about availability and reliability so your customers do not suffer service interruptions or broken transactions.
Web apps dealt with parallel issues. For them the answer was the appserver, which focused housekeeping in a central middleware stack. But is that the right solution for services which are more self-contained than web requests, where all the logic was deployed back on the server?
That’s where the debate over Enterprise Services Busses (ESBs) arises, because they provide a flatter, more distributed pipeline that can mediate, route, and transform messages – and depending on your viewpoint — orchestrate more complex workflows on demand. In other words, delivering many of the functions of appservers in an environment where services make logic portable and dynamic.
No, you probably won’t rip out your J2EE appservers for ESBs, but as you add services going forward, will you buy appservers or ESBs in the future?
Obviously, ESB pure plays have little to lose by promoting maximum functionality. Regarding incumbents, IBM is playing it both ways. Finally admitting that ESB’s are product (after several years of denial), they will let you buy simple or complex buses. By contrast, BEA is simply selling a simple ESB on the rationale that complex orchestrated actions are best handled by appservers. Our take? BEA is trying to protect its WebLogic business.
Yet, the march of technology could throw many of BEA’s rivals in the same position.
A few months back, Cisco unveiled “application-oriented routing,” moving functions like content routing and message or requestor authentication onto smart routers. It makes sense. As tasks get commoditized, commodity technologies emerge. There’s plenty of precedent: routers replacing custom gateways piles of simple Intel blades supplanting multi-processor servers, and the list goes on.
By that logic, ESBs could find themselves waystops as well, with network devices absorbing repetitive content routing, XML processing, authentication, authorization, and load balancing tasks, while higher-level process design and management devolve to application level. At that point, would the ESB folks be willing to eat their young?
Permalink
09.13.05
Posted in Enterprise Applications, SOA & Web Services, Technology Market Trends at 2:38 am by Tony Baer
Well it finally happened. Confirming the rumors, Oracle announced it’s swallowing Siebel, the last pure play enterprise CRM. If you listen to Salesforce.com’s Mark Benioff, it was a case of Oracle finally putting Siebel out of its misery. Looking at Siebel’s recent numbers, it would be hard to argue with him.
Oracle has surprised us recently with the sensitivity by which they are digesting the PeopleSoft/JD Edwards acquisitions. Maybe a better word is realism, since Oracle realized that forced migrations serve nobody’s interests including their own. And given that Oracle has been playing catch-up in CRM functionality, their embrace of Siebel shouldn’t be earth-shattering either.
We have a couple thoughts on the deal. First, this isn’t a zero-sum win for Salesforce. The hosted, “no software” CRM firm has done a land office job with the largely untapped small-midsize business market (which includes department level of Global 2000). But it’s hiccupping with enterprise engagements that require more customization, as recent Computerworld reports reveal at Cisco. Like ERP, Enterprise CRM is no slam-dunk market. Siebel’s future under Oracle isn’t endangered.
Secondly, Oracle says it doesn’t plan any more large acquisitions in the future, a strategy backed by most Wall St. analysts. Its plate is pretty full, digesting PeopleSoft/JD Edwards, Retek, ProfitLogix, and I-Flex. For that reason alone, BEA is probably not on Oracle’s radar.
But even if Oracle weren’t so preoccupied, we don’t think that a BEA acquisition would make any sense. The company is playing in a market where it’s squeezed by JBoss on one end and IBM at the other. That’s not so bad because BEA’s core market is changing, and if it had a sound strategy, we’d feel a lot differently.
Services-oriented architectures are transforming the middleware market, with busses and, in the longer run network devices, supplanting much of the functionality associated with appservers and hubs. The problem is that’s BEA’s playing defense here, separating much of its SOA products from existing offerings in a misguided attempt to protect the WebLogic base.
It’s a flawed strategy that Oracle would only waste time trying to correct.
Permalink
09.12.05
Posted in Linux, OS/Platforms, Technology Market Trends at 2:37 am by Tony Baer
Just over a couple years back, we remarked about Sun’s fortunes at the bottom of the bell curve. At the nadir of the dot com, post-9/11 bust, few organizations had the appetite for buying premium hardware, with Sun among the hardest hit. Since then, we’ve been waiting for Sun to make the definitive right turn.
Rewind the tape. Post 2000, Linux has been quietly cannibalizing the UNIX market with technology that was “good enough.” At the time, we saw alarming similarities between Sun and Digital, each of which had their own “perfect” platforms for their time that ceased being perfect once the lion’s share of those benefits became commodities.
Obviously, we weren’t alone in critiquing for Sun for failing to embrace the new challenge to its franchise, not to mention its stumbles monetizing Java. At that time, we gamely suggested that Sun eat its young, embracing 64-bit Linux to carve its line in the sand.
Today, Sun is returning to its roots. The company, whose original claim to fame was popularizing an “open” OS on an industry standard platform, is traveling full circle.
Yesterday, the definition of open was UNIX on Motorola processors, Sun and others in the UNIX community moved to proprietary processors that forked UNIX. Today, Sun is once again embracing an industry standard processor and industry standard OS. But now it’s called Linux on AMD Opteron.
That’s not to say that the Solaris or SPARC are obsolete. Solaris still contains many bulletproofing capabilities that raise the bar vs. Linux. SPARC provides vertical scalability that is better suited for transaction processing.
But at least Sun is now laying the groundwork for the day when Linux gets “good enough.” Sun’s crack engineering team is developing real intellectual property advancing the state of the art on AMD Opteron. Among the innovations, a better power/performance ratio, which grows significant as processor architectures add power in tinier footprints.
More importantly, Sun customers now have a roadmap and a reason to stay with Sun, regardless of OS or CPU. OK, Sun hasn’t solved the Java problem yet, but if it masters transformation to a higher volume, lower margin business, it will escape the fate of Digital.
Permalink
09.07.05
Posted in Application Development, Linux, Open Source, SOA & Web Services, Standards Development, Technology Market Trends at 2:34 am by Tony Baer
In an industry that devours buzzwords for breakfast, it’s amazing that we still use the term “open.” Writing about the myth of open systems a couple years back, we found interoperability, rather than open, was the more attainable goal.
Maybe that’s why today, when people say “open,” they usually mean “open source.”
Credit Linux, with a rags-to-riches story that’s proven almost too good to be true. A frustrated 20-something programmer in Scandinavia starts a clean room UNIX project, embeds it with Woodstock-like communal ideals. And suddenly it’s the emerging corporate standard thanks to bear hugs from incumbents like IBM. Hey, maybe we should get the Farrelly Brothers to pen the screenplay, “There’s Something About Linux.”
While startups once dreamed of becoming the next Microsoft, today many are hoping to become the next Linux or Eclipse. Not surprisingly, open source has become the favorite strategy for vendors seeking (choose one):
(1) Escape from obscurity
(2) Exit strategies for orphaned or end of life products
(3) Market dominance of a platform strategy
(4) Any or all of the above
So what makes an open source strategy successful? We’ve been wondering that as, over the past couple months, three (count ‘em) open source projects for developing Enterprise Services Busses (ESBs) have emerged, adding to others already scattered across the landscape.
To date, the most successful open source projects are Linux and the Eclipse Java tools framework, while the most successful open source products are Red Hat (Linux), JBoss (Java appserver), and, with a slightly different development model, MySQL (database).
The common thread? These are technologies that almost every software organization needs, but doesn’t want to spend much time or money worrying about. So you need a large enough potential market and a product or technology you can understand. Maybe Linux was obscure early on, but everybody knew what an OS was and all computers need OSs.
While Linux and Eclipse had good potential numbers, both traveled opposite paths to success: Linux as bottom-up, and Eclipse top-down. Below the radar for so long, Linux encountered little competition. Conversely, Eclipse’s visibility ensured competition, but IBM’s huge presence generated the bounce necessary for building the third party ecosystem that dwarfed Sun’s rival NetBeans.
Which brings us back to the question of whether ESB open source projects are viable. Potentially, the numbers are there, because when services-oriented architectures mature, most organizations will probably need an ESB. But these projects face a huge hurdle: no two vendors yet agree on exactly what an ESB does (we’ll get into that in an upcoming piece).
Maybe one or two ESB open source projects might eventually thrive. At least one will probably be a major platform vendor play like IBM’s Eclipse. The other could prosper from the ground up, but only if the skunkworks efforts now emerging find common ground within the next 12 months. That’s why we’re glad that at least a couple of them – Apache Synapse and ObjectWeb Celtix – are extending peace feelers after early wars of words.
Permalink