IBM's Cell processor looks like a candidate to power numerous infrastructure appliances

News that IBM has announced an upgraded version of its blade server based on the Cell processor this week has me wondering about the versatile and powerful "systems on a chip"'s use in appliances, too.

We're heard some hinting and "that's a logical outcome" statements from IBM officials in the past few months, so the pairing of Cell and appliances would not come as a complete surprise. When the details emerge, the price-performance and ease of deployment benefits of these high-powered, multi-core appliances could be very impressive.

When IBM announced plans to buy Telelogic, the deal made sense to me more when the use of a specialized Cell-fired appliances was made part of a possible future portfolio. When we had Jim Ricotta on a recent BriefingsDirect SOA Insights Edition roundtable podcast, the IBM general manager of appliances indicated more specialized appliance to come from IBM, though he did not finger Cell specifically.

Appliances from IBM should be expected in more componentized infrastructure roles in the coming months, for sure. They make a great deal of sense for data and content optimization and balancing, for SOA-support functions such as ESB, registry/repository, and as discrete services support stacks in a box (a business service appliance).

Those specifying services or functions will not need to consider the underlying platforms or inherent low-level integration issues, just focus on the largely standards-based interoperability characteristics for these functional units. Appliances allow greater exploitation of open source efficiencies by the vendor, with less complexity for the end user, and a better margin for the seller (more than just service and support).

Indeed, we may see some sort of a face-off in terms of total cost and performance between virtualization approaches and appliances approaches. Why not use both? I expect that appliances may very well be filling up larger list of new requirements for enterprise architects over the next two years.

The multi-core attributes of Cell, plus the proprietary 'Synergistic Processing Elements' (SPEs) for the chips provide the means to exploit parallelism and finely tune each box for the specific functionality at hand. The fact that these specialized and closed functional components (hardware, software, integration, optimization) require much less set-up and life-time support, appeals to architects (if not integrators). They may also help on energy use and heat-dispersion issues as well.

The ability to scale by virtue of adding (or subtracting) boxes, plus the ease of swapping and redundancy -- all bode well for more appliances-driven architecture (ADA [... sorry]) for SOA and high-performance yet specialized computing at the best total cost. These attributes will be of interest to hosters, service providers and telecommunications providers.

IBM's Ricotta told our analysts that appliances can cut costs by half, compared to traditional deployment approaches. When you take such economic common sense and toss in the technological secret sauce of optimized and specialized Cell chip-sets ... the balance of Power could well shift toward appliances in the most competitive datacenters.

SaaS now ready to succeed where ASPs failed -- especially for smaller businesses

Listen to the podcast. Read a full transcript.

There is an entire universe of suppliers and vendors that support the delivery of applications as on-demand services. Indeed, the Software as a Service (SaaS) model is attracting more than end users who acquire their IT via user-per-month service subscriptions. Also attracted to the SaaS market are those vendors creating the means to produce and deliver such services well and efficiently.

That's because the timing is now right for small businesses and ISVs to reach each other through SaaS, with the Web as a platform, and with compelling economics. We're also seeing more Services Oriented Architecture (SOA) support vendors focus their sales on SaaS providers and hosts, with the understanding that SOA may well emerge in the SaaS universe first, and then extend to enterprises more generally.

To help understand the SaaS market, what SaaS providers want and what those seeking to support those providers can deliver, I recently spoke with Colleen Smith, managing director of Software as a Service for Progress Software.

The resulting podcast offers some great insights and better appreciation of the swelling ecology of vendors and providers devoted to SaaS delivery.

Here are some excerpts:

Progress Software had started to look at the application service provider (ASP) model back in the early 2000-2001 time frame to figure out whether there was an opportunity for some of the small ISVs who were using the Progress technology to become more of an application service provider. ... I was basically asked to figure out how to build more of a SaaS partner program and look at ways in which we could work with our partners.

[We looked at] the technology enablement and how to build applications to go to market with SaaS. We also added a couple of other things, because we felt that one of the biggest challenges traditional software vendors had was around the business model, the go-to-market strategy, sales enablement, and figuring out ways in which we could actually help them to be more successful in this new business model. We were thinking of it more as a business model and not just as a technology.

Sure, there are the technical components of multi-tenancy, being able to have a Web-based access, and being able to drive policy configuration and personalization. ... On the software side of it, there is much more of a focus on business-process automation, and the people who are building, deploying, and running those applications have a good, solid knowledge of the business itself. The second thing is that the applications are now architected specifically to be able to run for multiple customers, and it’s not a separate implementation for each customer.

The economy of scale is what killed a lot of hosting providers back in the ASP days and ran them out of business. They were just doing an implementation for every customer, as opposed to a single implementation that can now be used by multiple customers -- personalized and managed. The people who use the application run and use it differently, but the implementation is pretty much the same for all customers.

More importantly, we work with a lot with our partners or these ISVs to make sure they realize that this requires different marketing. It requires a different sales and business model, because clearly there are financial implications in terms of cash flows. There are also a lot of things they need to think about in terms of who is the target market.

We've helped them focus on looking at new markets and going down-market. Our partners have always focused very much on the mid-market, but SaaS has enabled them to target some very niche verticals and go down into the "S" of SMB (small and medium business).

I think the timing is right. There are a bunch of reasons why. Number one, the Web is finally viewed as a business platform. Seven or 10 years ago, the Web wasn't viewed as the way in which business applications were going to be run and managed. ... [Before, SMBs] couldn’t afford the dedicated IT staff to manage and maintain the applications. They didn’t necessarily have the infrastructure and the technology to run these business applications. A lot of business applications are much too complex and require too much manpower to manage and maintain the apps.

ISVs [now] realize there’s a whole new market. There’s that long tail, if you will, of the software market that allows them to be able to go after new people. In the past, software just wasn’t accessible to them, and now there’s a whole new market opportunity.

We stress to our ISVs, "You can continue to be in the traditional software business for your core market and the market that you’ve been going after, but there’s a whole new opportunity for you to look at new markets, whether they be the low-end of your current market, adjacent markets, or even new geographic territories."

Throughout South America, Africa, and Asia-Pacific, what we’re finding is tremendous growth opportunity for ISVs to look at these as new markets and to go into those new markets with a new business model. That new business model is SaaS.

On the supply side of how these ISVs can deliver, there’s a new support ecology available to them. They don’t have to create their own data centers themselves. They can find partners. We’ve heard a lot about Amazon, for example, and there are others, of course. These ISVs can focus on what they do well, which is their software, their logic, and then also take advantage of some hosting.

Back in the ASP days, it was all about hosting. I’m not saying that in the SaaS world hosting isn’t important, because it absolutely is. What has changed over the last 7 to 10 years is that now you look at it in terms more of an ecosystem.

You’ve got your infrastructure providers, your application providers, and your hosting and managed-service providers. The biggest change that I have seen now is that each realizes they have a role to play, they have a core expertise, and that through building of this ecosystem and through partnerships you can be much more successful in being able to lower your deployment cost, but still being able to target and go after these new markets.

The SaaS market, in general, is really still in its nascence, and there are a lot of things that have yet to happen. But, the good news is this isn’t just a fad. We see a fundamental change in terms of the business model. ... The only way that the end customer is going to win in this is if we get into a business model where there is that shared risk and shared reward, but the customer pays for only what they need to use.

It's going to come down to pricing models. It still has to come down to some building of ecosystems out there, where everybody knows their role and plays that role, but doesn’t necessarily try to do the other person’s role. There are still a lot of things happening.

I believe it’s going to be vertically focused. I don’t think this is going to be a horizontal play. We’ve seen a lot of success in vertical business expertise. There's going to be content, business applications, data, and services. If all of those can be offered in a single environment through a single service provider, the customer will end up winning.

Listen to the podcast. Read a full transcript. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.

Ruling expressly denies Express Logic its copyrighted API logic

Express Logic cried foul in June 2006 when Green Hills Software appeared to have a competitor in its embedded microkernel RTOS micro-velOSity product that looked a little too much like what Express Logic had already been delivering to the market (and partnering with Green Hills on).

In seeking a remedy, Express Logic called for an injunction on the market delivery of Green Hills' micro-velOSity (which was denied), and also sought arbitration over its position that Green Hills copied the ThreadX API C source code contained in Express Logic’s tx_api.h header file. Express Logic said that Green Hills had tread on its copyrights when Green Hills created micro-velOSity as an alternative to Express Logic's ThreadX.

Well, now the arbitration panel has sided largely against Express Logic. Green Hills feels vindicated. Express Logic would like to differ, if not in the case's outcome, than in the hardships facing the industry.

“We’re shocked that copying of source code and using it to compete with our copyrighted work was not found to be infringement,” said William E. Lamie, author of ThreadX and president of Express Logic, in a release. “We believe that the basis upon which the arbitrators determined that this copying was not infringing would put all software code at risk of being copied without infringement. After all, what software is not made up of ‘words and short phrases?’ As for the ‘functional requirements for compatibility,’ why should anyone be able to copy source code under the guise of compatibility but not use it for that purpose? This ruling seems illogical to us, and would put all software at risk if this reasoning were to be applied in other cases.”

From Green Hills: "We are vindicated by this judgment,” said Dan O’Dowd, CEO of Green Hills Software, in a release. “Express Logic’s campaign to instill fear, uncertainty, and doubt about micro-velOSity has failed. We regret any inconvenience this litigation has
caused our customers. This final arbitration award ensures that embedded developers can continue to use micro-velOSity with confidence.”

The issues around APIs and compatibility and when source code can and can not be copied are still a fuzz ball. The panel that ruled on this case does not set legal precedent, and a similar lawsuit may be filed (although not in this instance) some day.

Indeed, spats between software companies are nothing new, but the concepts around copyright and code (and even patents!) remain treacherous for many companies. You stay in this business for more than a few months and you'll hear of weird lawsuits and claims around patents, copyrights, and licenses. It's a vipers pit out there, for many.

Unfortunately, that may not change much any time soon. Even largely sensible revisions to the patents process that could clarify the role patents play in software are bogged down in bureaucracy and, yes, Virginia ... politics.

Express Logic may not be able to do more than complain in sales meetings that Green Hills has violated its intellectual property. Express Logic also claimed that Green Hills engages in unfair business practices ... well, that too is now more for the court of public opinion to decide. "Unfair" is a tough term to qualify in the world of software. Has anyone claimed that Silicon Valley or Route 128 are the bastions of the fairness and truth? Not since Rogers Rangers tangled with the Abenakis.

Did Express Logic bend, like a pretzel, the concept of APIs in seeking a legal remedy for its alleged victimization? Perhaps. Are the distinctions in code sharing for compatibility testing and for intellectual property protection murky? Probably. Does Green Hills care about its partners much when its own interests are involved? Probably not.

So there are some lessons in here. APIs are not a good way to assert intellectual property claims. Another is be careful who you partner with when murky software definitions are involved.