07.31.08
Posted in Enterprise Integration, Middleware, SOA & Web Services at 10:27 pm by Tony Baer
Oh it’s great to be back from vacation.
It must be quite a hot summer when you come back to a flame war on, of all things, ESBs. It kicked off with an article by TechTarget’s Rich Seeley, which consisted of an interview with John Michelsen, chief architect at SOA testing vendor iTKO, who spoke of the problem of ESB proliferation. Dave Linthicum jumped into the fray by calling the idea the inevitable result of bad or non-existent enterprise architecture. While some such as ZDNet’s Joe McKendrick characterized Linthicum’s rant as a hatred of ESBs, in fact, Linthicum’s message was that “SOA will fail if you focus on just layering in more technology, versus normalizing the existing technology.”
Lorraine Lawson, who does a great job making sense out of noise, likened the problem to the spread of high tech kudzu throughout the enterprise. The plot got thicker as Linthicum asserted that he doesn’t hate ESBs and self-righteously reiterates why “I am still right on this issue” is that “the lack of centralized control and architecture, in many instances, is the cause of the problem.” He then dared readers to say why there is a use for multiple ESBs. Neil Ward-Dutton counters that Linthicum should get real, stating that “even where EA is highly effective (and in many places it isn’t), it can at best only be one of many forces shaping the way that IT evolves,” to which Linthicum added that he was misunderstood. “I think I agree with most of this,” adding that the problem of ESB proliferation and the bad architecture that precedes it is a consequence of a failure of leadership — that EA must have buy-in and involvement.
All this is classic of what Gartner Group has termed the hype cycle. The build-up that ESBs are inevitable and the fallout when you find yourself with a giant middleware hairball.
Somehow belief emerged that to do effective SOA, you needed an ESB because how else could you deliver on the promise of integration that SOA was supposed to fulfill. ESBs, SOA, and web services got mashed together in the same sentence so often that many thought they were synonymous, or at least, prerequisites for each other. Ron Schmelzer and Jason Bloomberg at ZapThink have long railed against bus-oriented architecture. “Purchasing an Enterprise Service Bus (ESB) is starting at the wrong end of the initiative,” they say, adding, “The vision of relying upon one piece of middleware to solve all integration problems is an unrealistic fantasy.” As Todd Biske maintains, ESBs are great for mediation, but arguably, adding more baggage is a recipe for failure.
Let’s face it, it’s nice when an EA group has real influence. Realistically, the best we can do is make some wicked lemonade out of all those lemons. Consolidate if you can, but if not, keep those pipes as simple as possible. Use ESBs strictly for what they’re best at — mediation. And as we’re entering the dog days of summer, I’d like to invite everybody to come join me for a good dip in the pool.
Permalink
07.28.08
Posted in .NET, Application Development, BPM, Enterprise Applications, Java, Middleware, SOA & Web Services, Supply Chain Management, Technology Market Trends at 6:53 pm by Tony Baer
In the aftermath of IBM’s announcement of intent to buy Ilog, it would be all too easy for us to reflect back on a conversation with Ilog’s CEO Pierre Haren last winter at its annual user conference covering survival in the software industry. Haren’s description of the typical life of a software vendor is that first you get a handful of successful references, then replicate to at least 20 – 30 successful accounts, then you start thinking about what your company wants to do when it grows up. Start specializing your solution for vertical sectors or other specialized sectors of the market, or you must change your role and move on. Haren’s implicit message: eat or be eaten.
We won’t take the cheap shot about IBM swallowing up Ilog because this deal makes too much sense.
Both companies know each other quite well, having been partners in one way or another for about a dozen odd years, that Ilog’s business rules engine fills a key gap in the WebSphere Process server BPM line, and most notably, that we saw IBM’s SOA strategy VP Sandy Carter keynote Ilog’s conference. IBM’s not going to haul out the big guns for any sub-$200 million software company.
Ilog has had a case of multiple attention disorder for a number of years. Otherwise, how could you explain that company of Ilog’s size would have not one or two, but three separate product families that targeted almost completely different markets? Or that a $180 million company could support 500 partners? Ilog was best known to us and the enterprise software world as one of a handful of providers of industrial-strength business rules management systems. That is, when your rules for conducting business are so conditional and intertwined, you need a separate system to keep them from gumming up into a hairball. That condition tends to typify the world’s largest financial institutions. That’s enough for one business.
But Ilog had two other product lines, one of them being an optimization engine that was OEM’ed to virtually every major supply chain management vendor, from SAP and Oracle to i2, Manugistics, Manhattan Associates and others. And by the way, it also had a cottage industry business selling visualization tools to ISVs.
So how do all these pieces fit together? Just about the only common thread we could think of was the case of a supply chain customer that not only uses the optimization engine, but has such a complex supply chain that it needs to manage all the rules and policy permutations separately. And not to leave loose ends untied, it needed a vivid graphics engine so it could visualize supply chain analyses so it could conduct better exception management.
Suffice it to say, that is not why Ilog had three separate business units. The company happened to grow satisfactorily, showing profits for seven straight years, so that it never had to face the uncomfortable question of refocusing. Had it stayed independent, it might have had to do so; while revenues grew roughly $20 million this year to $180 million, profits sank from $4.9 million last year to a paltry $500k this year. Blame it on currency fluctuations (based in France, Ilog would have had to discount in the US to keep customers happy), not to mention the mortgage crisis that has cratered the financial sector.
The good news is that Ilog is a great fit for IBM. Its rules engine adds a piece missing from WebSphere Process Server, and in fact has excellent synergy with a raft of IBM products that start with Business Events (apply sophisticated rules to piecing together subtle patterns emerging from torrents of data), FileNet content server, WebSphere Business Fabric (the old Webify acquisition, providing frameworks for building vertical industry SOA templates), and the list goes on. And that’s only the BRMS part. IBM Global Business Services and its Fishkill fab are customers of Ilog’s optimization engine, while Tivoli’s Netcool node manager uses Ilog’s visualization.
The sad part of the deal is that the acquisition will likely abort Ilog’s interesting foray into Microsoft’s Oslo vision, where it provides the business rules underpinning. Even if IBM wants to maintain the business, we’d be surprised if Microsoft followed suit. Ilog went to the effort, not simply to port Java-based JRules, but write a fully .NET native product. That’s analogous to what happened with Rational, whose Microsoft Visual Studio partnership originally dwarfed its ties with IBM.
Colleague James Taylor says that the acquisition portends the end of the rules management market as it will likely set off a wave of consolidation by major application/middle tier vendors. CIO UK’s Martin Veitch adds that “IBM is continuing to dance around the margins of enterprise applications” with the Ilog deal. We’d agree, just as with the previous acquisition of Webify and the bulking up of WebSphere Process Server, that it’s getting harder to see where tools leave off and applications pick up. In an era where all these pieces become service-oriented and theoretically composable, maybe that’s irrelevant.
Veitch takes issue with the broader implications for IBM and Oracle – that “These companies have become planets to be explored rather than recognisable fiefdoms of even 10 years ago,” and that “a lot of people are unimpressed by the levels of integration and R&D that follow the incessant deal-making.” Well, part of that may be to satisfy Wall Street, but the march toward agglomeration has become something of a self-fulfilling prophesy. That is, a $500 million software company is no longer considered large enough to be viable, and so if customers are afraid for vendor survival, that reinforces the trend for IBM, Oracle, SAP, and Microsoft to gobble up what’s left. That’s a larger issue that gets beyond the pay grade of this post, but ironically provides subtle reinforcement of what Haren told us roughly six months ago: that once a market gets to the billion dollar or so level, that it becomes prey for “bottom fishers” that push niche providers back into their niche.
Permalink
07.23.08
Posted in Application Development, Business Intelligence, Cloud, Data Management, Database, SOA & Web Services, SaaS (Software as a Service), Web 2.0 Apps at 12:36 am by Tony Baer
Data is one of those things that tends to get hidden behind black boxes. Before data becomes accessible, somebody must jump through the hoops to either access the data, or make access intuitive for the rest of us. There’s been no shortage of tools over the years to do things like hiding the SQL, or making non-SQL data sources look like SQL, and so on. Data transformation and integration used to be an exceptionally thorny problem until, just over a decade ago, the emergence of data warehousing demanded a better solution, and Informatica invented it.
Informatica’s innovation was borrowing visual development techniques from 4GL RAD tools and backing it with a metadata engine to make data transformations visual and reusable. For his latest act, Informatica founder Gaurav Dhillon has returned to his roots, pushing ETL into the Web 2.0p world. His new venture, SnapLogic, exploits emergence of RESTful web services, a.k.a., Web-Oriented Architecture (WOA), which represents data, not as columns or rows in a relational table, but as web links that are searchable by Google. It combines that with a Microsoft Excel-like front end recognizable to power users, rather than the 4GL metaphors used by developers, and places the technology atop a commodity open source Apache Tomcat Java server. Using these technologies, you can connect to a growing array of data services, such as those provided by commercial providers like StrikeIron, or those that are already in the public or open source domain.
SnapLogic’s latest deals reveal its goals to make ETL available to SMB that previously judged the technology too expensive and complex. It has inked deals with SugarCRM to provide a high level front end that hides the complexity of its web services, and it has signed a deal to host its ETL services in Amazon’s EC2 compute cloud. The goal is to make the process as low-touch as possible.
Significantly, none of what SnapLogic is doing is totally new; providers like CastIron commoditize in an appliance the most popular data transformations that Informatica and others already perform; while Salesforce simplifies access to its web services with features such as Microsoft Outlook plug-ins. The difference is SnapLogic’s go-to-m,arket strategy and its leveraging of REST and open source, which makes the technology more platform-independent and more affordable than even Salesforce’s low prices (compared to Siebel et al).
It’s an auspicious start, but there’s no free lunch. RESTful services are certainly less complex and lighter weight than web services, as you don’t have complex headers and a bewildering array of standards to contend with. REST is simply about data access, retrieval, and updating – which is its greatest strength and weakness. If all you weant is data services, REST does the job far more efficiently than SOAP calls to WSDL services. However, REST is not extensible like web services, meaning you cannot make any of the safeguards, like authentication, authorization, or access intrinsic. In a risk-averse, increasingly compliance driven business world, where leaks of consumer credit card numbers have grown all too routine, you need to incorporate safeguards. Add the dangers of the unprotected cloud, as Computerworld’s Ephraim Schwartz reported in detail.
The good news is that the problem is so general and widespread as to lend itself to the same kind of open source commoditization that could spawn a new generation of partners with which the SnapLogics of the world could round out their vision.
Permalink
07.01.08
Posted in Uncategorized at 1:30 pm by Tony Baer
Oracle finally placed its cards down on the table regarding its roadmap for BEA products, and for the most part there’s little surprise. As Gavin Clarke reported several weeks ago, Oracle will be deconstructing AquaLogic. But taking a cue from its Applications Unlimited Strategy, Oracle is telling BEA customers that it will support all existing BEA products, regardless of whether they wind up on maintenance.
Cut to the chase, Oracle’s choices for strategic products going forward are not exactly a shock. WebLogic Server, until a few years ago the leader in the space, is going to be Oracle’s Java middle tier going forward. It wasn’t until Oracle 11g that, in Larry Ellison’s words, it finally got the appserver right. So it’s obviously going with the more established offering. Tools are another story: Oracle claims to be the second largest contributor to Eclipse, yet it continues to spurn the IDE on which the Eclipse Foundation was founded. Instead Oracle focused its efforts on EclipseLink, the implementation of JPA that it donated to Eclipse.
While Oracle has been schizoid in its Eclipse strategy, BEA was schizoid on tools in general. Originally embracing a VB-like approach with the original WebLogic Workshop, BEA later forsook the technology following acquisition of an Eclipse-based successor, throwing its installed base into a confusing migration strategy. No question here as to which way Oracle is going.
In other areas, Oracle’s roadmap is a case of seasoning its Fusion portfolio with BEA pieces where they fill gaps. That includes AquaLogic Service Bus, which now gets fortified with Oracle’s service composition fabric that comprises its implementation of the proposed SCA standard. Ditto for SOA governance, where AquaLogic Repository fills a gap, and where both relied on OEM bundles with Systinet for the UDDI service registry. And the same goes for entitlements, a BEA technology that will be added to Oracle’s Access Management suite. As for BPM, BEA’s AquaLogic offering –the former Fuego product – provides the middle ground for business unit level implementation that complements the top-down of its existing bundled offering from IDS Scheer. While BEA/Fuego customers liked the degree of control that their tool provided, under Oracle they are going to have to give up the run time to Oracle’s BPEL Process manager. Call that a case of realpolitik.
In a deal this size, there are always going to be a myriad of details as to which product features make the cut and which don’t. With Oracle’s previous large acquisitions (read: PeopleSoft, Siebel), there has been little question about which application is the strategic one going forward. In spite of Larry Ellison’s early posturing, it was never about sunsetting a particular ERP or CRM package because customers are not going to make forklift migrations. Middleware is another story because of the predominance of standards; migrations are painful, but nothing compared to dumping your ERP system. And thanks to de facto standards, and more importantly, open source, tooling is fungible.
Unless the viability of a company is in question, most customers don’t like to see their vendors get acquired as they often fear getting lost in a larger fishbowl. It’s even more the case with Oracle, whose past bravado, aggressive sales force, and high pricing have turned customers off. SearchSOA’s Michael Meehan cites results of a BEA customer poll that his group conducted last week, and the results aren’t exactly shocking: most BEA customers were happy with the way things were and aren’t looking forward to life with Oracle. So it’s not surprising that one of the points that Oracle emphasized in its presentation is that BEA pricing would remain grandfathered in for existing customers. The die was cast back in 2003 when Charles Phillips backtracked from Larry Ellison;s posturing about wiping PeopleSoft apps off the planet with what eventually became the Applications Unlimited policy. No matter, Oracle still faces living down its reputation as it cries all the way to the bank.
But back to product roadmaps, Oracle’s strategy for BEA products is a conservative one – not simply from the decision to continue supporting even obsolete products, but rather, that it has not been as fast on the draw with new technologies as was BEA. That explains BEA’s earlier embrace of OSGi, but the flip side of bear hugging the new and trendy explains why it has never had a consistent tooling story while Oracle’s, love it or hate it, has.
Permalink