For the enterprise, the challenge with project spending has been identifying projects that provided a net benefit. Over the last 10 years, the focus of enterprise projects has shifted from providing some enhancement to the top line to one of defending the bottom line. That means shifting from a productivity-driven thesis for projects to a cost-management thesis. The problem is that cost management vanishes to a point; you can’t continually build IT spending on a static set of benefits and at the same time demand “improvements” in ROI unless you take spending levels toward zero. There is still a credible “cost” on the table, associated with the management of application performance, but it hasn’t been addressed in an organized way by the vendor community in general and by networking vendors in particular. Neither group has been able to come up with productivity-based benefits to drive spending up either. This fall we’ll see if it changes.

For network operators, monetization is obviously the big problem. Right now I’m seeing operators pretty pessimistic about wireline investment except in emerging economies. The Internet is the only wireline driver for traffic growth, and it’s a driver whose growth is currently non-monetizable under neutrality rules and the unlimited-usage paradigm. Operators have identified three priority areas(content, mobile/behavioral, and cloud) but only the latter is getting much near-term capital support because the former two rely almost totally on the emergence of a service-layer paradigm—an NGN Advanced Intelligent Network architecture. That’s not been happening, at least not in an open sense, and so I’m seeing an accelerating shift of capex to mobile networking, where dollars buy cell sites and backhaul and switches and not routers. That shift works against the network vendors overall, but in particular against those who don’t have much of an RF/cellular stance. Which is why Cisco did their agreement with NEC, of course, for monetization.

Operators haven’t abandoned monetization of content or mobile services; Telefonica just restructured to create a division that’s explicitly charged with that task, for example, and our survey in May showed that most operators had board-level projects underway to identify a variety of monetization goals. The current problem is that about half these projects have near-term milestones the operators say they can’t meet for lack of conformant implementation tools. I’m always amazed at these complaints because they show that even when vendors are confronted by buyers with well-articulated requirements, they’re finding it impossible to simply address them. Instead they want to talk about taking a “first step” that, absent any credible longer-term vision for the project, might be the only step they can support. That’s what’s stalling progress.

One vendor that has recently taken some of this to heart is Alcatel-Lucent. ALU has quietly beefed up its Application Enablement story with some real insight into how services are created. For example, it says that the service layer develops “Platform APIs” that can then be exposed to developers, and an example of such an API is multi-screen video. I just finished an open-source app note on this same service opportunity, and I’d love to be able to compare it to the details of the Alcatel-Lucent approach, but so far the inner workings of these Platform APIs and the way they get developed (including by whom) isn’t on the website. I’ve also noticed some recent positioning by NSN in this space, and even by Ericsson (which has been gaining some traction in the multi-screen video space over the summer). An interesting contrast to Cisco, which despite having what might be the clearest technical picture of a service layer, seems to be stalled by reorganizations in the exploitation of their assets.

Apple, already facing an anti-trust review or two, is now getting growing push-back from app providers over the subscription-sharing rule. Apple wants a cut of every subscription, meaning that it want apps that sell something to sell only through Apple’s store and not directly to the consumer. If dissent spreads here, it could be a worse problem for Apple than government scrutiny.

From the very first days, Apple has fostered a closed ecosystem model to the greatest extent it could, bucking a general industry trend toward opening software and systems to third-party exploitation. Google announced its own program for an Android store that’s considerably more financially friendly to publishers and streaming audio/video apps, which only puts more pressure on Apple.

The rumors of a lower-priced iPhone and even iPad are further indications that Apple is worried about competition from Android. Just as the PC-compatibles shunted Apple aside in the desktop wars of the 1980s, Android-based devices are threatening to diminish Apple’s market share and marginalize it with developers—those who aren’t already upset by Apple’s store policies. But Apple loses in any price war even if it wins, because Apple is always seen as a player that sustains higher margins. With Jobs’ health now clearly a problem, the difficulties could be harder for Apple to work through. ]]> http://itknowledgeexchange.techtarget.com/telecom/apple-gets-push-back-from-app-providers-over-revenue/feed/ 0 http://itknowledgeexchange.techtarget.com/telecom/how-quickly-can-alcatel-lucents-open-api-program-adapt-to-the-market/ http://itknowledgeexchange.techtarget.com/telecom/how-quickly-can-alcatel-lucents-open-api-program-adapt-to-the-market/#comments Tue, 21 Dec 2010 18:14:04 +0000 Tom Nolle http://itknowledgeexchange.techtarget.com/telecom/?p=2116 Alcatel-Lucent continues to showcase the developer side of its Application Enablement approach, including its Open API program, which federates application services across multiple developers. There is no question that the company has started to gain some traction in the market with this, but there is still a question in our mind regarding how quickly the program can adapt to market conditions.

The thing that has made over-the-top players successful in the service layer is that they’ve dodged inertia. Because they don’t worry about standards beyond blowing a casual kiss here and there, they can expose features via APIs very quickly. If you wait for industry consensus on APIs, you’re putting yourself at the tail end of a multi-year process and then saying you’re running at market speed. I’d like to see Alcatel-Lucent open up more regarding how it will create features in Application Enablement and how quickly it can expose them using RESTful APIs.

The iPhone launched the smartphone revolution, which in turn launched the applet/widget revolution, which in turn is opening the question of whether device-resident intelligence will play a commanding role in the development of what the buyer/user perceives as “services.” The iPad has had a similarly transforming effect in the tablet PC space, and competitors have already established themselves with smartphones — primarily via Android-based phones in the broad market and on RIM’s building on its enterprise incumbency. Competition is also increasing from both sources in the tablet space, with pretty much the same cast of competitive characters.

What creates Apple’s platform dilemma is that broader installed bases begat greater support for developer opportunity, and thus a larger application community. As I’ve noted before, this was one of the factors behind Apple’s loss of its early lead in the PC market to the IBM-compatibles. An open framework attracts support because it is open, but it also reduces the originator’s ability to control and monetize its own marketing, which is why Apple has traditionally rejected such an open approach. But a marriage of its Mac operating system and the OS used for appliances, plus the harmonizing of a development environment across both, would increase Apple’s developer mass.

The challenge is that it will also almost certainly cause Google to prioritize Android as a tablet OS, thus exacerbating the competition between these two industry giants. The further the Android OS goes in terms of supported hardware, the harder it will be for Apple to sustain itself as an appliance walled garden. Some gestures of openness exist through the developer program, but Apple’s long-standing feud with Adobe over Flash illustrates where walled-garden thinking can take you and how it can create a lot of gratuitous enemies.

On the service provider side, the competition between Apple and Google (through its Android proxies) creates yet another path to disintermediation.  Ceding service-creation innovation to over-the-top (OTT) players was a problem in wireline, and ceding it to smart device vendors and developers in the wireless space only makes things worse. The so-far-ill-fated Microsoft phone strategy has been toying with hosted services, but probably more as a means of getting Microsoft into the OTT feature business than as a means of empowering operators. Can operators respond with an approach of their own? Can they respond in time? Their service-layer revenue future may depend on it.

Microsoft seems to be aiming Phone 7 at businesses as much as (if not more than) consumers, with a strong tie-in to Office likely and linkage to Windows Live services as well. The developer tools are well-structured — better, we’d say, than those available from Apple or Google — and Microsoft is hot to earn developer respect and support with the product.

The question of just what the much-advertised “different kind of phone” means hasn’t yet been answered explicitly, but we think that the Windows Phone 7 approach will be much more application-driven, with applications playing a role more PC-like than phone-like. However, there’s no question that it has a very strong cloud computing focus, which may mean it’s going to pick up the standard dropped by Kin as a client-to-the-cloud phone.

In fact, we think this may be the start of a wave that could be destructive for apps in general — a wave of trivial applications that eventually swamp app stores and bore consumers. In a growing population of apps, it’s hard to stand out. Apple developers already know that, and this trend could make the problem worse. However, if a tool were used to create a development framework that could then be customized using conventional developer tools, it might ease drudgery in app development.

We think this is a very good idea, in no small part because ProgrammableWeb will help Alcatel-Lucent create an API picture that can advance further and faster than operators or standards bodies would be likely to advance. We noted when Open API first came out that the key requirement for it would be to build some feature mass and credibility without being stuck in the slow cycle of standardization that characterizes most carrier efforts. Now we hope that Alcatel-Lucent will move some highly useful and still-not-standard things forward. Alcatel-Lucent will keep the company operating independently.

The goal, in a business sense, is to build what’s equivalent to an over-the-top (OTT) framework that lets applications and developers span the crazy quilt of mobile operators and roaming agreements that form the current global mobile network.

Absent so far from the play are any of the network equipment vendors, and we’re not able at this point to get any information on just why that’s the case. It’s possible that there will be announcements at Mobile World Congress to position the network vendors. We believe that Alcatel-Lucent is already committed to embracing the GSMA APIs in its Open API program. The really interesting question will be what players like Oracle and Microsoft decide to do. Handset players are doing more to avoid fragmenting developer programs; Intel and Nokia have just announced they’ve merged their Linux mobile platforms.

It makes little sense for AT&T to push an app store for iPhone when Apple has its own and when AT&T’s exclusivity with Apple may be short-lived. The new plan is to create an AT&T applet/widget set that would work on a variety of platforms and to induce developers to support that model to increase AT&T’s differentiation and flexibility at the same time.

It’s a smart move, particularly if AT&T can then link the Plusmo framework back to AT&T-hosted service features and development kits—the kind of stuff BT already provides and that the GSMA OneAPI addresses. We’re hearing they are very interested in that.