03.23.10
Posted in Cloud, Java, Middleware, OS/Platforms, Technology Market Trends, Virtualization at 7:28 pm by Tony Baer
With the coming of Spring (framework, season, take your choice), but more to the point, concurrent announcements of the OSGi Enterprise Edition 4.2 and the Eclipse Gemini and Virgo projects, debate over OSGi has renewed. OSGi has seen great success where it is not seen – as the framework for dispensing Eclipse plug-ins, and as the invisible engine by which most of the household name Java EE servers are now factored.
We’ve always been pretty bullish on what OSGi could do. It allows your server footprint to be truly dynamic – you can deploy and kill runtime components at will without taking the whole mess offline. There’s a potential sustainability appeal to any technology that helps reduce footprint – as less apps mean less server, less power, and less space.
Interestingly, OSGi could provide a lot of the elasticity at the appserver level that virtualization promises for OS images and cloud promises for application deployment. And there’s the rub – OSGi is hardly the only path to keeping your webfarm footprint contained. Significantly, while the goal is the same for each strategy – you only want as much resource as you need – they all take different ways of getting there. OSGi is a developer decision that addresses which application or middleware modules (or functionality) do you actually want running at any time, while virtualization and cloud are largely IT operations decisions pinpointing images and choice of what and how much infrastructure to provision.
Although the goal is common, the choice of strategy differs based on where elasticity is needed; furthermore, these are not all or nothing decisions. Conceivably, if you have a highly variable application that requires, not only different amounts of processing capacity, but different functionality at different times, then OSGi could complement your virtualization and/or cloud strategies. Let’s say you process market feeds, the composition and mix of which changes by time of day and which trading centers are active around the globe. Or your organization is number crunching end of period reports. Those are a couple possibilities.
The problem is in knowledge and awareness. For most IT customers, OSGi is a black box. It’s the way that WebSphere and WebLogic are architected. But that makes a difference to the vendors, not the customers because they don’t know how to provision OSGi bundles and there are no best practices for bundling bundles into bigger pieces that can be identified as tangible modules. There is still a lot of OSGi misinformation and still a lot of debate out there. Of course, while virtualization and cloud are much better known, there’s plenty of hype and debate about cloud, and concerns about unchecked use of virtualization.
So a couple years after OSGi gained critical mass vendor acceptance, there remains a lack of tooling for configuring OSGi servers, not to mention best practices for deploying them. SpringSource, one of the first to develop an OSGi server, has now donated the technology to Eclipse as reference implementation in Gemini, with Virgo becoming the technology development project. SpringSource’s commercial direction is tc Server, which commercializes the tiny Tomcat servlet container; as of March 8, VMware is pushing tc Server through its channels and for the next couple months, is giving away two production CPU licenses and 60 days evaluation support to VMware customers.
SpringSource’s fork in the road symbolizes the existential dilemma facing OSGi: if your goal is to simply reduce your web container footprint, 10-MByte Tomcat containers should do just fine. It scales out quite nicely as well, with LinkedIn serving 40 million web pages daily on Tomcat. So again, we ask, why do we need OSGi?
Give us your answers.
Permalink
03.16.10
Posted in BPM, Enterprise Applications, Java, Middleware at 12:45 am by Tony Baer
We’d be the first to admit our surprise that Pegasystems has thrived as well as it has. Our initial impression of the company about 4 – 5 years ago was of an interesting, rather eccentric bunch whose absent minded professors had great ideas but little business savvy. At the time, roughly four or five years ago, the company was marginally profitable.
Maybe their professors weren’t that absent minded and their approach not so pedantic after all, as the company has been on a winning streak for the past ten quarters, scoring 25% growth last year as the rest of the economy (and software industry) tanked. Tilting against windmills, the company scored big gains among established clients across financial services industries, who used Pega’s process “solution frameworks” covering areas such as loan origination and underwriting; wholesale banking, and retail bank account opening.
Pegasystems is on the right side of history, having embraced vertical frameworks. That’s an approach that you also find IBM taking. In business for roughly 25 years, Pega’s sales didn’t take off until it began rolling out a series of templates or frameworks that provided a 60% solution, eliminating the need to model commodity processes from scratch.
Either way, Pega’s success belies our observation that vertical templates are the future of enterprise applications — using the framework as a raw template, they will be composed from existing applicaitons and data sources rather than written or implemented as a packaged applicaiton from scratch.
Growth last year added $35 million to the company’s cash cushion, leaving it with a nice healthy $200 million in the bank. But cash in a consolidating industry is trash when your rivals are either acquiring or getting acquired left and right. As so the question was what would Pega do with its cash.
We now have the answer: Pega announced yesterday its intent to acquire Chordiant, whose specialty is dissecting, analyzing, and optimizing a company’s experiences with its customers. The deal, at $167 million in cash, actually nets out to about $116 million when you factor Cordiant’s $51 million cash position. Pega’s solicited offer trumped an abortive unsolicited $105 million offer back in January from CDC, an aspiring Hong Kong-based enterprise applications provider. Chordiant has come down a few notches over time, with business flattening to $75 million last year, down from $115 million a couple years ago. Pega’s $5/share bid about 10% of the company’s 2000 dot com peak, but a 30% premium over its current valuation.
Pega got a good deal, and Wall St. agreed, as shares of both companies rose on the heels of the announcement. It reflects the fact that Chordiant provides Pega two opportunities: (1) Deepen its presence in financial services accounts by going into the front office, and (2) gain a new beachhead in telecom where it currently has bit a single critical mass client. Although telco could broaden Pega’s addressable market the deal wouldn’t work if the solutions weren’t complementary.
Pegasystems offers a highly sophisticated, rules-driven approach to defining, modeling, and executing business processes. It offers roughly 30 industry specific templates, and well over a dozen cross-industry frameworks such as customer process management, control and compliance, procurement and so on.
By contrast Chordiant covers what it calls “customer experience management,” which tracks customer interactions and offers predictive analytics for optimizing cross-selling, upselling, or customer retention strategies, or for predicting risk or churn. It also offers vertical templates for financial services, healthcare, and telecom. Chordiant’s predictive analytics have adaptive capabilities where the rules can change based on trends in customer response; if a promotion offer proves not as attractive as initially forecast, the rules can adjust the algorithm to reflect reality.
The potential synergy is where Chordiant optimizes customer-facing front office processes while Pega’s BPM frameworks optimize the corresponding back office processes such as loan origination. On paper, it looks like yin and yan. But there are basic architectural differences between the products, as decision management consultant and author James Taylor has pointed out. Keep in mind that Taylor has traditionally been skeptical of Pega’s approach to embedding rules inside its process engine, rather than loosely coupling the two. But he makes valid points that Chordiant handles rules differently from Pega, that the potential synergy between the two is great, but that the company need to take care that technical differences do not “derail the technical integration or cause the merged company to merge its operations without merging its products.”
So on paper, Pega has made a sound deal. As the company is not yet experienced in digesting acquisitions of this size, its success in consummating the Chordiant acquisition will become a predictive indicator of the company’s ability to survive and grow in a consolidating market where it will be expected to make more such deals.
Permalink
03.10.10
Posted in Application Development, Application Lifecycle Management (ALM), Business Intelligence, Cloud, Data Management, IT Infrastructure, IT Services & Systems Integration, Legacy Systems, Networks, Outsourcing, Systems Management at 12:34 am by Tony Baer
Over the past few years, HP under Mark Hurd has steadily gotten its act together in refocusing on the company’s core strengths with an unforgiving eye on the bottom line. Sitting at HP’s annual analyst meeting in Boston this week, we found ourselves comparing notes with our impressions from last year. Last year, our attention was focused on Cloud Assure; this year, it’s the integraiton of EDS into the core businesss.
HP now bills itself as the world’s largest purely IT company and ninth in the Fortune 500. Of course, there’s the consumer side of HP that the world knows. But with the addition of EDS, HP finally has a credible enterprise computing story (as opposed to an enterprise server company). Now we’ll get plenty of flack from our friends at HP for that one – as HP has historically had the largest market share for SAP servers. But let’s face it; prior to EDS, the enterprise side of HP was primarily a distributed (read: Windows or UNIX) server business. Professional services was pretty shallow, with scant knowledge of the mainframes that remain the mainstay of corporate computing. Aside from communications and media, HP’s vertical industry practices were sparse, few, and far between. HP still lacks the vertical breadth of IBM, but with EDS has gained critical mass in sectors ranging from federal to manufacturing, transport, financial services, and retail, among others.
Having EDS also makes credible initiatives such as Application Transformation, a practice that helps enterprises prune, modernize, and rationalize their legacy application portfolios. Clearly, Application transformation is not a purely EDS offering; it was originated by Ann Livermore’s Enterprise Business group, draws upon HP Software assets such as discovery and dependency mapping, Universal CMDB, PPM, and the recently introduced IT Financial Management (ITFM) service. But to deliver, you need bodies and people that know the mainframe – where most of the apps being harvested or thinned out are. And that’s where EDS helps HP flesh this out to a real service.
But EDS is so 2009; the big news on the horizon is 3Com, a company that Cisco left in the dust before it rethought its product line and eked out a highly noticeable 30% market share for network devices in China. Once the deal is closed, 3Com will be front and center in HP’s converged computing initiative which until now primarily consisted of blades and Procurve VoIP devices. It gains a much wider range of network devices to compete head-on as Cisco itself goes up the stack to a unified server business. Once the 3com deal is closed, HP will have to invest significant time, energy, and resources to deliver on the converged computing vision with an integrated product line, rather than a bunch of offerings that fill the squares of a PowerPoint matrix chart.
According to Livermore, the company’s portfolio is “well balanced.” We’d beg to differ where it comes to software, which accounts for a paltry 3% of revenues (a figure that our friends at HP reiterated underestimated the real contribution of software to the business).
It’s the side of the business that suffered from (choose one) benign or malign neglect prior to the Mark Hurd era. HP originated network node management software for distributed networks, an offering that eventually morphed into the former OpenView product line. Yet HP was so oblivious to its own software products that at one point its server folks promoted bundling of rival product from CA. Nonetheless, somehow the old HP managed not to kill off Openview or Opencall (the product now at the heart of HP’s communications and media solutions) – although we suspect that was probably more out of neglect than intent.
Under Hurd, software became strategic, a development that lead to the transformational acquisition of Mercury, followed by Opsware. HP had the foresight to place the Mercury, Opsware, and Openview products within the same business unit as – in our view – the application lifecycle should encompass managing the runtime (although to this day HP has not really integrated Openview with Mercury Business Availability Center; the products still appeal to different IT audiences). But there are still holes – modest ones on the ALM side, but major ones elsewhere, like in business intelligence where Neoview sits alone. Or in the converged computing stack and cloud in a box offerings, which could use strong identity management.
Yet if HP is to become a more well-rounded enterprise computing company, it needs more infrastructural software building blocks. To our mind, Informatica would make a great addition that would point more attention to Neoview as a credible BI business, not to mention that Informatica’s data transformation capabilities could play key roles with its Application Transformation service.
We’re concerned that, as integration of 3Com is going to consume considerable energy in the coming year, that the software group may not have the resources to conduct the transformational acquisitions that are needed to more firmly entrench HP as an enterprise computing player. We hope that we’re proven wrong.
Permalink