Jamcracker unlocks a Web 3.0 role for the channel

Jamcracker unlocks a Web 3.0 role for the channel

Summary: Is there a role for traditional systems integrators and other IT solution providers in the delivery of on-demand applications? Jamcracker believes there is, and wants to help make it happen.

TOPICS: Tech Industry

Is there a role for traditional systems integrators and other IT solution providers in the delivery of on-demand applications? So far, they haven't had much of a look-in. In part, that's because the Web allows providers to bypass the channel and go direct to buyers. But even where providers have tried to work with channel partners, they've found it difficult to interest them in a business model that pays on a monthly schedule over the life of the contract rather than a single upfront licence fee.

There's been another factor too: the IT channel are a conservative bunch.JSDN will help kickstart channel involvement in the on-demand space They won't go out and sell something until they're convinced that a market already exists for it. Now that on-demand is firmly on the map, their interest levels are rising. At the same time, there are signs that a role is starting to emerge for them, not least because on-demand vendors have realized that customers in many industries prefer to deal with their existing IT suppliers.

The nature of this emerging role has been articulated recently by Jamcracker, KB Chandrasekhara company that's a veteran of the on-demand space, having launched in February 2000. Jamcracker's founders, led by Exodus co-founder KB Chandrasekhar (pictured), made an early bet that the on-demand sector would create a big opportunity for channel players. It's been a long wait, but finally the on-demand sector is getting big enough for their vision to pay off — and in the meantime the company has had ample opportunity to refine its products and expertise.

Its announcement in November of the Jamcracker Services Delivery Network proposes two main functions for the channel. One of them is the traditional role of customizing on-demand solutions to meet the specific needs of their clients. The other role is new, and consists of aggregating bundles of services to create those solutions. The channel partner becomes a services integrator, assembling on-demand services from various sources to build a solution instead of sourcing a selection of products.

Jamcracker believes that the JSDN will help kickstart channel involvement in the on-demand space because it brings together a pre-certified catalog of on-demand applications and hosting providers that channel partners can draw on, relieving them of the burden of researching and testing a range of suitable services for themselves. "Our aim is to alleviate the inhibitors," VP of marketing Brent Arslaner told me.

Naturally it also makes available as part of the mix its own infrastructure software and expertise in building and delivering aggregated services offerings. ISVs must develop an adapter than connects to JSDN, and hosting providers must licence the infrastructure software. Jamcracker is staying flexible about the deals it will strike, however. "Every vertical has different metrics that drive the consumption of these services," Arslaner told me, "so we have to be flexible in how we build their business models."

In the first phase of the project, partners are striking individual relationships with on-demand vendors or hosting providers. The next stage, which is due to happen this year, will be to build out a live network of shared services. At that point, the JSDN will become a living example of the aggregation layer I described in my posting last month about What to expect from Web 3.0, while channel partners will draw on the aggregated services to create and deliver finished applications to end customers.

If the Jamcracker network takes off it will be an interesting demonstration of the market fragmentation I was describing in my post on Wednesday about Who will own Web 3.0? Although Jamcracker is providing elements of the software, it will be the participating providers who collectively 'own' the network, in the same way that participating ISPs and enterprises 'own' the Internet. I'm sure they will make a decent living from this, but I would suggest that it's the channel players, assembling the applications for customers and thus owning the customer relationship, who will be in the most lucrative position.

Topic: Tech Industry

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I now understand what I don't understand

    Phil - the other day one of your readers made the comment "Huh?" after reading one of your Web 3.0 posts. I have to concur to a degree. After reading your post today about Jamcracker I visited their site and the more that I read the more confused I became. I will contact them with some questions, and I know that it is not your responsibility that I understand the web of activity that is currently happening around new software services, but is there someplace a person can go to try to understand some of this?
    • The path to enlightenment

      > is there someplace a person can go to try to understand some of this?

      No, there is no single place, I'm afraid. One of the reasons I started doing this blog was because not enough was being written about the on-demand and software services space. And one thing I was very aware of was that it would take a while to cover the basics, because so many of the concepts are unfamiliar -- which is why vendors like Jamcracker sometimes leave casual visitors none the wiser (as do some of my own writings -- that "Huh?" comment was a timely wake-up call that I won't be ignoring).
      Having said that, there are some useful white papers and overviews scattered around and I will try and pull some links together for a blog posting early next week. HTH.
      phil wainewright
      • It's all marketese

        Mr. Wainewright, as well as the previous commenter, hit upon one of the primary shortcomings of the SaaS "industry": it is mostly marketing buzz, with little substance. The reason why it is so difficult to understand it without a disctionary, a thesaurus, and a Magic Eight Ball, is being by and large, SaaS, "Web 2.0/3.0", SOA, etc. are the same tired ideas that the industry have been shoveling up, just giving a new paint job. To cover up this fact, they add a bunch of acronyms and fancy words to disguise the fact that the emperor has no clothes. Web 2.0 is a great example. At the end of the day, web APIs don't do anything that a traditional linked library don't do, they just communicate over a network protocol. There is nothing new to this. It's called RPC. But they pretend it is some new innovation, and make up a bunch of words to talk about it, because if ordinary people could understand it, they would see it for what it really is, and not be willing to form over big bucks for someone else to implement it (because it's pretty useless) or to explain it to them (because it is actually quite simple).

        Justin James
  • Cost will become the inhibitor

    I for one do believe that an integrated newtork like JSDN would be great, but the catch will be the TCO - total cost of ownership.

    With so many layers, everyone involved will want a piece of the action. Look at how current retail operations are being upended by Wal-Mart and Amazon. They are removing the middleman quite efficiently.

    But SaaS is currently evolving to match that dying retail network. Companies are integrating and coagulating all types of services into "super-services". Then, you just pick, choose and pay.

    But the cost will get to be too much. Everyone involved, the creator of the widget, the aggregator and the network provider will want a cut. Penny after penny, the cost will get to be too high for that widget service on your Web site.

    What will happen? Folks like us at South49 who are building complete solutions in one package - no middleman to pay - will provide effective tools at a much more efficient price.

    We get to use APIs that make sense both technically and financially. And when the cost of using an API (like phone, fax, etc.) gets to be higher than building it yourself, you pull it in-house, develope a better solution that even leap-frogs your current provider, and reduce the TCO.

    People creating the SaaS APIs will find it difficult to get their widget used unless they sell directly to groups. When you add a network, everyone adds their cost and profit margin into the mix.

    So, I really don't see SaaS (a.k.a. - Web 2.0) being the killer solution that it's being hyped to be. It will get crushed by it's own TCO.

    Does anyone agree?
    Paul C.
    • I agree, and have one more thing to add

      Not only do I agree, that with everyone taking a slice the cost becomes too great, I would also like to point out something else. As these providers, aggregators, etc. more and more resemble the retail channel, they also approach commoditization which further drives down their revenues. Once all APIs are the same, and all backends have roughly the same content, and pricing is easy to compare, you get a market that looks like long distance phone service, where no one can make a profit that justifies staying in business.

      Justin James
    • I disagree

      The beauty of networks like JSDN is that there aren't too many layers in the distribution channel. Only the service provider (hosting company) and the service creator (ISV)are involved beyond the consumer. Jamcracker makes money by providing the infrastructure allowing for the delivery and management of the on-demand services by the service provider. That's an efficient distribution channel!

      Single companies like you will never be able to compete with a service provider who can bundle any combination of services from many independent software vendors and deliver them to their customers. That is a best of breed solution delivered through a single provider.

      This is just like what the phone carriers have been going through and the companies that win are those who provide new innovative services the quickest and bundle them together with the commoditized services that are required.
      • Jamcracker is not needed....

        In your scenario, there are 3 layers before getting to the consumer, which is one layer too many. Jamcracker's layer is not necessary and does add to the total cost.

        We aggregate other service providers' functionality (phone IVR, faxing, etc.) into our solution, but we don't need a Jamcracker to do that for us. Only companies who cannot pull the technical pieces together would use Jamcracker, which means that they will become uncompetitive to us because they add the cost of Jamcracker into the mix.

        Read jmjames's comment about the commoditzation of these APIs and how that will obsolete a Jamcracker.

        Yes, there will still be people who want to pull the pieces together themselves, but even they will find Jamcracker restricting.

        Think of home audio: you can put all of the pieces together for a home theater system yourself, or buy a one-box solution.

        Similarly, Company X that uses Jamcracker to build a one-stop solution will compete with South49, who builds a one-stop solution. But Company X has 3 extra worries:

        1. relying on all of those network layers to be functioning all of the time. Company X's customers won't care that Jamcracker's network is hosed, they just see that Company X's service is not running.

        2. What happens when the API hosting provider and Jamcracker part ways? Now Company X has to think about where to get that service from, since their customers rely on it.

        3. Cost: Jamcracker is an extra cost.

        I still think that it sounds good in practice, but in reality, these types of networks will only be like AOL was 10 years ago: training wheels to get the newbee intiated into the game. But after a while, they will find that they don't need that extra layer.

        I'd be interested in discussing it more, if you are. As we all know, no one has the right answers, only thoughts and ideas on where this is heading.....
        Paul C.
  • The Realities of Profitably Delivering On Demand

    Every significant technology company is or will become a service provider. Google, Amazon, Ebay, and IBM are already service providers. MSFT is slowly morphing into one and Oracle is undoubtedly trying to figure it out after they booted Netsuite out. Existing service providers including tier 1 telcos, outsourcers, managed service providers and systems integrators are building businesses around delivering on demand services.

    The reality is that the efficient delivery of On Demand Services is a highly complex challenge that led to the demise of most first generation Application Service Providers.

    The oversimplification of the backend technical and operational problems that have been mentioned within this string are misleading. Including comments such as,
    "Only companies who cannot pull the technical pieces together would use Jamcracker, which means that they will become uncompetitive to us because they add the cost of Jamcracker into the mix."

    Rectifying the api issues is only the beginning of the challenge. In order for a service provider to build a profitable on demand service business they must have a multi-tenant architecture that leverages shared processes to automate the operational and administrative aspects of on demand delivery from on-boarding users, providing secure access and provisioning, change management, billing, auditing and customer support across a set of heterogeneous services. Throwing bodies into a data center has been the most common method that many of these processes have been handled in the past.

    It just doesn't scale so the fundamental question any service provider must ask themselves is whether they want to build these capabilities internally or leverage a proven leader like Jamcracker.

    Regarding the prior comments regarding a solution like Jamcracker's. As was stated, yes Jamcracker will undoubtedly create new competition for service providers.

    Jamcracker has spent the last 7 years hardening there infrastructure to assure there system will not as stated "get hosed."

    If the SaaS provider left the network they could just get the service directly from the SaaS provider.

    Finally if value recieved exceeds costs the marketplace will be efficient.

    Another common theme in this thread is that JSDN will potentially commoditize service offerings. The reality is that the core competency of the service provider should be figuring out how to bundle and package a set of services that meet the needs of the end customer. Individual services will be commoditized and that is not a bad thing for the industry.
    • Jamcracker is Training Wheels for the Beginner

      Yes, every significant company will become a provider of services. But if you know what you are doing, and have pulled together the disparate pieces, you can quite quickly, efficiently and cost-effectively do all that Jamcracker is offering without them. I know - we have (and are still) doing it.

      We pull phone, fax, Web and database services together to handle a large set of modules for distributed (remote) work forces. This includes intelligent forms with barcodes that are scanned/faxed into our system and immediately placed in the proper project.

      Our phone system's IVR (interactive voice reponse) surveys collect data and place it directly into databases which are accsessible from any device (browser, IM queries, etc.).

      We have done this with minimal staff, some decent capital and have used superiour service providers where needed, such as dedicated server hosting providers. We are living proof that you can build a scalable, on-demamd application without Jamcracker if you simply know enough about how to do it. And we are nowhere near the smartest kids on the block!

      Individual services will become commodites. JSDN is simply trying to be a coagulator of these services for those who cannot do it on their own, hence the need for the training wheels. There's nothing wrong with it - you gotta start somewhere!

      But I haven't seen a training-wheeled bike win any bike races lately. So as long as JSDN likes the turnover as folks find better (and cheaper) solutions that are better integrated and not just a hodge-podge network, more power to them.
      Paul C.
      • Not Training Wheels... Wheels

        You are correct, successfully companies that have participated in the race and "won" do not use training wheels. These companies have realized two things: timing and their competition. You can win the race by using technology that enables your product to be better then your competition but you have to launch your product before your competition does. Yes you could save money with cheaper solutions. Do successful companies want to save a few dollars or do they want win the race and beat their competition.

        Jamcracker is more like the wheels on the bike... not the training wheels. Without the wheels you will never win the race.