On Demand B2B with John Radko

Is Growing Cloud Adoption affecting Server Sales?

John Radko — Tue, 09 Jun 2009 11:03:03 -0400

As interesting a question as this is, I need to admit upfront that I do not have the answer, but as I was catching up on a couple days of reading, I found two articles that have me wondering if that is net exactly what is going on. When scalable, efficient business models start to come together, you usually see customers dramatically increasing usage while spending less, and vendors under price pressure -- which appears to be the story in server sales (this story from channelinsider is notable for another reason, it seems to indicate everyone is increasing market share, which I'm pretty sure is impossible...).

The decline in server sales that the article talks about is hardly a small one, it represents over $2 billion in revenues to top technology providers who are competing fiercely for market share in a recession. Given technological change and economic reality, all of the major vendors listed (including IBM, HP, Dell, Sun, Fujitsu) are touting virtualization and cloud infrastructures. But according to this article in Network World (thanks to Rob LaPorta for sharing this on LinkedIn's EDI Group), cloud based data centers are on a tear, growing very rapidly and facing sufficient demand to avoid the kind of brutal competition that their server vendors are experiencing.

So my question is, is this a temporary phenomenon, or are we seeing a "transfer of value" in the marketplace. Server vendors and data center providers are in "coopetition" on providing computing power through cloud infrastructures (specifically IaaS, or Infrastructure as a Service), but the server providers are in the more traditional competion with the same data centers for providing computing power generally. If cloud data center operators can squeeze more power out of servers than individual customers, than they can provide lower cost computing power and enjoy better margins -- but only at the expense of the server companies.

This has been predicted by many people, including Nicholas Carr in his book "The Big Switch", but these two trends may be an early indicator that in some markets (particularly hosting of websites) it is starting to happen.

Blogged with the Flock Browser

Optimism and Pessimism in the land of the underused ERP

John Radko — Fri, 05 Jun 2009 13:27:01 -0400

I came across a nice report of an Accenture Study over at CIO Insight. It is one of those "slideshow" style articles, and had some good statistics about ERP usage, customer integration, etc. But the more I thought about the content, the more I realized two things:

We're all crazy when it comes to our expectations of technology
Very few people understand what "competitive advantage" (as defined by Michael Porter) is all about

Let me start with the second. In the Accenture survey, 76% of respondents believe that enterprise systems (this was about ERP) provide a competitive advantage to their organizations. I'll leave a detailed explanation of competitive advantage to others (see the wikipedia link above), but in short, it's some key difference between you and your competition. To be more specific, it's usually a cost advantage (driven by scale or technology, meaning YOUR own), a capabilities difference (I can do more, or do it in more places) or a focus difference (I'm more dedicated to this region, industry, whatever).

Buying a particular piece of enterprise software cannot deliver you sustainable competitive advantage because your competitors may well run the exact same system (in fact, that may be what led you to choose that software!). So does that mean ERP and other enterprise software erodes competitiveness? Absolutely not.

Integrated software within the enterprise, be it ERP or applications wired together with middleware (or a combination), are the foundation for using technology to support business strategy. If you pursue low cost advantage, you need visibility into costs and supply chain activities, for instance. But just as Nike cannot make you a track star without your help, ERP systems cannot make a business a cost leader on their own. This is where additional figures from the Accenture survey are very telling:

64% of the respondents use only core capabilities
31% use ERP in less than half their company
19% integrate enterprise systems with customers (no number for suppliers, but I would assume it is similar)

Assuming I am reading this correctly, less than half the respondents are using more than basic capabilities, probably with less than half the enterprise, and only 20% are integrating outside.

That is why I say we are crazy when it comes to expectations of technology, as we expect strategic value from systems we are only partially using, with part of our company, and a fraction of our customers. Amazingly, more than half of the respondents expect the current crop of enterprise applications to be replaced by new technologies, and fully 87% expect to increase spending on them. I feel like we have a beautiful Corvette in the garage that we have no time to drive, but we are looking at an even more expensive sports car to replace it.

The optimism in this survey is well-justified however. An enterprise's ability to manage and act on information is an excellent basis for driving competitive advantage -- but we need to look beyond acquiring and implementing technology to actually using it. In particular, wiring existing systems into supply chains, and in particular into demand chains (i.e. customers), needs to be a bigger priority. Using SOA (service oriented architecture) and BPM (business process management) tools -- which are probably already in the inventory -- in concert with deeply integrated ERP or enterprise apps is one of the strongest approaches to enabling speed and agility, but it requires going beyond just "core functions".

I don't believe most organizations are getting all that they could out of their enterprise systems or their supply and demand chains, but if they would get them together they could change that...

Blogged with the Flock Browser

Models for integrating B2B with an ESB

John Radko — Tue, 02 Jun 2009 13:41:10 -0400

I was recently visiting a client to discuss possibly augmenting the work we were doing for them from straight messaging to Managed Services, when a question came up about whether we could connect our services to their ESB. This is not the first time I've been asked about this, and while the answer is always "YES", the form this takes varies with the client's circumstances and goals. There are many variations, but I like to "bucketize" them where possible into three models:

B2B Broker on the ESB: This is basically NOT connecting directly to the ESB, but connecting to an existing or new B2B or comms gateway that is connected to the ESB. This is a typical method where the B2B team and strategy are external to the ESB from a design and architecture perspective, and trading partner configuration is encapsulated within the B2B broker/gateway. This model is usually easy to configure, but can result in latency between the managed services and the ESB, and the potential for confusion if there is a lack of synchronization between the B2B software and whatever data is driving the ESB routing logic. The advantage to this approach (aside from the ease), is that the security and any data transformation can be handled prior to the ESB. This is the most common scenario today, usually leveraging some secure variant of FTP from the B2B Broker to managed services.

Custom integration to the ESB: Rather than a commercial gateway that is integrated to an ESB, this is more of an exposed "endpoint" (usually, though not always web services -- SOAP or REST). The service provides "mapping" logic, sometimes of data, but usually of envelope, to augment the inbound transaction so that it can be properly handled by the ESB. An advantage to this approach is that Web Services management and government can layer security on without burdening the ESB with providing this for external entities. This is particularly important when the transactions or documents coming in are not self-contained (meaning that they contain sufficient information to be routed and handled without augmentaion). This is typically the model in use when a customer asks us to integrate with them via web services.

Direct to ESB integration: In this model, the transaction is entered -- more or less directly -- into the ESB. I tend to see this most with XML traffic, although an EDI enabled ESB could certainly accept X12 or EDIFACT. An example of this model would be JMS over HTTP (currently supported to a customer's TIBCO system, for instance), where the network layer is used for securing the connection, but the routing and processing logic is directly on the ESB. This is the "purest" model, but requires the ESB implementation to have been designed with external transactions in mind. Paradoxically, where this works it is likely to be the model the customer insists upon. The advantage to this approach is flexibility, and the elimination of a number of way stations inbound. As attractive as this approach is, most organizations still shy away from directly connecting their ESBs to the outside world.

I expect that more and more organizations will start to consider approaches 2&3 going forward, but it will take time. Direct to ESB integration is a strong step to efficiently connecting external partners to an organizations Service Oriented Architecture (SOA), but that's a topic for another blog entry.

Blogged with the Flock Browser

Is Your Service Evolved?

John Radko — Fri, 13 Mar 2009 22:02:59 -0400

Although it may not seem like it, the majority of software maintenance is not maintenance at all – it is enhancement. Enhancements are wonderful, marvelous things, magically bestowing additional capabilities to users, like the granted wishes of a Fairy Godmother from Cinderella – except that the midnight deadline is a “scheduled maintenance window”, and that scurrying you hear is not mice turned into horse, but DBAs frantically trying to migrate data within the “window”.

This can be acceptable for some systems and applications, but the growing world of software as a service and cloud computing will see larger and larger service infrastructures that will be under simultaneous pressure to add features (grant wishes) and have continuous availability (stay the twelth ring of the clock tower at midnight). Recently at an all-hands engineering meeting, our vice-president for Managed Services engineering described this as continuous service evolution.

Continuous Service Evolution is the ability to add capabilities to a system running in a grid configuration without requiring a service outage, and it is an absolute requirement for SaaS platforms (as well as major cloud computing infrastructures like Microsoft Azure or Google AppEngine). The idea is simple enough, but the method is a bit different from other high availability approaches.

Grid configurations are typically composed of “stateless workers”, with a “persistence store” shared amongst them. An easy way to grasp this is to think of several tellers in a bank (those of you wondering what bank tellers are should just cruise on back to Facebook…) either depositing or withdrawing money from the same vault. The tellers are the stateless workers and the vault is the persistent store. As long as I have more than one teller and the vault is there, I can always pull a teller out and teach them a new skill (enhancement), and then put them back in to provide the enhanced services.

The worker is stateless because the money is (had better be!) in the vault, not with the teller – so they are interchangeable. What makes all of this work is the fact that banking customers have a small number of kinds of interactions with the tellers, and any teller can support it. In a CSE-type service, that is the interface. Enhancement can add to the interface, but never take away (or at least not without advertising that something is going away, which is referred to as deprecation). The price of continuous evolution is that “old” features must be maintained for a long time, which is backward compatibility.

Another requirement is that the vault is permanent, it must be available all the time. In the services world, this means that the store (a database usually) must also be capable of evolving without requiring a service outage.

This style of service architecture is not likely to be achieved by accident, and will require sacrificing absolute performance in favor of flexibility and redundancy, but the lessons of evolution are that it is not the best performing solution that survives the longest, but the most flexible.

Cloud computing may change outsourcing/BPO

John Radko — Wed, 28 Jan 2009 14:53:55 -0500

Recent events (economic, technological, business) maybe driving the convergence of two traditionally separate sources of value in the managed services or outsourcing world, specialized knowledge, and scale. Although some organizations have traditionally applied both specialized knowledge and scale, it was far more common for smaller service providers to compete on specialized knowledge -- with higher infrastructure costs, and larger firms to compete mostly on scale, with less specialized knowledge and focus than their smaller rivals. But recent research and trends, including some highlighted here , show that the advent of cloud computing, and large commodity cloud service providers, may allow specialized managed services providers to focus and still provide compelling scale in the infrastructure. Referred to as "ADAMs" by Gartner (Alternative Delivery Models), these providers leverage not just Cloud architectures, but also Software as a Service (SaaS) platforms.

And there is no reason why this has to be only a two-tier model! I recently posted a link via Twitter, Facebook, etc regarding a beta-service called CloudMQ . This service -- though not commercial yet -- may be a leading indicator. It aims to offer standards based (JMS, or Java Messaging Service), business grade messaging (guaranteed delivery, etc) "in the cloud" (offered to customers via the internet). So far, this sounds normal enough, until you realize the entire service is hosted on Amazon's EC2 and S3 services, which are themselves infrastructure services! And we are only at the start of this. Commercial services like Amazon change the economics, and when the economics change, the models quickly follow...

Blogged with the Flock Browser

Mining past SOA projects for fun and profit

John Radko — Fri, 23 Jan 2009 13:15:57 -0500

One of the best parts of my job at GXS is my involvement with our early stage R&D efforts, affectionately (I hope) called "science projects". Although the projects vary wildly, there are always a few common attributes:

we are trying something new
potential customers are working with us
we need to learn more to have comprehensive requirements
the work is basically unfunded

That last attribute is the most fun to deal with; in fact, a really successful science project (like Order Lifecycle Visibility a few years ago, or B2B Scorecarding more recently) will prove its worth, become a "roadmap" project, get funded, and now it's not a science project anymore (sort of like a child going off to college, but cheaper and they don't come back to live rent free when its over).

Our latest science projects have been really interesting though, because in spite of the economic challenges, they are proving a bit easier to implement because of the latent value in previous SOA (service oriented architecture) projects completed in the GXS Trading Grid. I don't want to debate whether SOA is dead or not, but I can say with great confidence that mining previous SOA projects for "recyclable" components is alive and well.

As an example, many of our customers use the Intelligent Web Forms Service (IWFS) on the GXS Trading Grid for doing EDI with larger partners. This has all the benefits of a cutting edge web-forms based client, but also happens to be built on a service oriented architecture. In developing this system, our teams implemented general services to handle document arrivals, routing documents to other services, converting X12 (and other) formats to XML for rendering in web forms, and managing the documents and meta-data for all of that. Critically though, the teams did a good job keeping these services unaware of each other, as good SOA design dictates. Also, with the GXS Trading Grid acting as an enterprise service bus, there was the potential to access all of this latent value.

When, working with Microsoft, we set out to build direct integration between Microsoft Excel and the GXS Trading Grid, we were able to leverage many of these services to link the Excel users to their Trading Partners without change. Especially gratifying was the reuse of event-driven services, which in many cases worked without change (except to configuration).

I'm not sharing this to show how eerily we can predict our future needs, we can't. I share this because it was wonderful to mine previous SOA efforts and find that efforts around decoupling and encapsulation had paid off! I'd encourage every technology leader to hunt for the latent value in those recent SOA projects, and use it to drive innovation when organizations need it most.

Oracle enters the Amazon Cloud!

Dave Tollefsen — Tue, 23 Sep 2008 09:58:47 -0400

I am a big fan of Amazon's web services / cloud platform strategy -- if for no other reason then it demonstrates their continuing ability to go places in the market before others even realize they exist. In terms of the horizontal cloud computing services providers, they are the innovation leader right now in my opinion (with some serious competitors at their heels, including Microsoft and Google).

I expect Amazon to routinely shake things up, but was still surprised at their latest announcement, about a new arrangement to run Oracle's software in their cloud.

When I talk about cloud computing, and how it relates to our world of B2B in the GXS Trading Grid, I usually break it into a short term and a long term. In the short term, I see GXS continuing the transformation of our data centers and software infrastructure from traditional multi-legged systems to a true "cloud-style" architecture.

My simple formula for cloud style computing is kind of like Jeff Foxworthy's "You might be a redneck" jokes:

If you don't know how many computers are running your solution, you might be doing cloud computing
If you don't know the brand/size/speed of your storage devices, you might be doing cloud computing
If the only servers you encounter personally are at restaurants, you might be doing cloud computing
If you don't understand why anyone would care about their operating system, or how you could "run out of capacity" -- you are definitely doing cloud computing!

(for a more serious definition, that I mostly agree with it, check out what wikipedia has to say...)

Note that when I joke about not caring about your "operating system", I mean the one the individual servers are running. As cloud infrastructures expand, they tend to create what you might call a "cloud operating system". The easiest examples of this are Google AppEngine and Salesforce.com's AppExchange, but I think as the number of services Amazon offers grows (S3, EC2, SMS, etc), they too become more important than the underlying OS (usually linux variants for Amazon). It is the capabilities of these cloud operating systems that differentiate the providers, from one another, and from previous eras of computing (no, this is not just going back to the mainframe).

All kidding aside -- the other thing I think about is the long term. Will even large service providers operate their own data centers, running specific servers and operating systems, or become residents of another company's "cloud". Note that this is way bigger than owning assets. ASPs, co-location, etc is really more financial engineering, as evidenced by the fact that you can easily (well, somewhat easily) switch providers.

It may be a stretch, but I liken this to leasing space and hiring contract employees to do build things for you. Another example is leasing a truck from Ryder and paying a contracting firm to provide a driver.

Using another company's cloud (similar to what Nicholas Carr wrote about in The Big Switch, is more like partnering with a Flextronics or Celestica (contract manufacturers with substantial capabilities), or working with a DHL, UPS or FedEx for logistics. Beyond outsourcing the work, you also gain access to a collection of systems that are differentiated. Switching is still possible, but it is not "plug and play", and you are probably getting far more value than just an asset play.

So what does any of this have to do with Oracle and Amazon? Well I have been thinking the "long term", when cloud infrastructures operated by the big guys (whoever those turn out to be . . .), actually replace the primary data centers for larger companies, is 10-15 years out -- but now I wonder. The ability to run traditional enterprise software -- like Oracle -- with a rational licensing model and support, was a major stumbling block, but may not be for much longer (if other companies follow Oracle's lead).

I am reminded that the future typically arrives ahead of schedule...

Tags: cloudcomputing, Oracle, Amazon, business

Interesting thinking from AMR

Dave Tollefsen — Wed, 06 Aug 2008 17:41:59 -0400

Tony Friscia, of AMR, raises some interesting points in his latest "Above the Noise". I am especially interested in his first point where he differentiates people that sell technology from people that use technology (the other trends are well worth a read as well).

Tony quotes author Carlota Perez, who believes that the users of technology (including notable tech heavyweights like Amazon and Google, or large cellular and telco providers like Verizon) will drive, with the "traditional" technology companies becoming OEMs. I find this interesting because it tracks to a trend I see in our industry, as well as in adjacent industries like ERP.

The E-Commerce Services business was originally built around the notion of operating a network (when I joined GXS, there were still people earning their living with soldering irons building custom communications gear), but today almost no major player owns and operates their own network, yet our global reach and operational capability is greater than ever. We do still develop a great deal of software, but our focus is increasingly on using what we develop to provide services to our customers, rather than simply dropping CDs on our customers accompanied by an annual visit to collect maintenance payments. In the modern world of E-Commerce, production go-live for a new project is really just the beginning. The real work is using the technology to onboard, transact and collaborate -- in other words, not the technology, but the ability to use it.

In a perfect world…

Dave Tollefsen — Tue, 05 Aug 2008 16:57:24 -0400

Yesterday we had a team-building event that culminated with a visit to a local winery in Virginia, Chrysalis Vineyards. After the tasting, we were led by the enthusiastic winemaker Curtis into the area where the wine is actually "made", and he spoke to us at some length about the process (August is apparently an ideal time to visit, as the winery is cleaning and getting ready, so he had the time -- come the fall they would be going all out to transform the first harvest into wine).

Chrysalis is an interesting vineyard, as 40 of their 50 acres are planted with a native North American grape called the Norton (most famous varietals are European). Beyond that though, I was fascinated by Curtis' offhand remark that given the right conditions, wine would practically make itself. "Throw some grapes in a bucket, stomp the juice out, and kick the bucket to the curb for a week and you'll get wine . . . IF, you have perfect fruit, temperature, humidity, ... Winemaking is the art and science of closing the distance between the real world and that perfect world -- which means Curtis and his colleagues have a lot to do. Within the areas where the wine is made and stored, advanced technology is used to control temperature and humidity. In addition to the amount of science and planning, it was interesting that the entire process was constantly "managed". When asked when the wine is tasted to see how it is doing, the response was "constantly" (this got a pretty good laugh, followed by several applications for employment -- but winemaking requires advanced training . . . ).

The parallels to the E-Commerce Services world were not lost on me, and given the head start that winemaking has, I guess it is going to be a long time before we will be on auto-pilot. In a perfect world, data would stream from business to business over the internet, and everyone would structure data the same way, eliminating the need for translation. There would be a single communications protocol that used unbreakable encryption whose certificates never expired. But that is not the world of E-Commerce today, and is not likely to ever be -- so, like the winemaker, our job is to close the gaps.

But the most striking similarity between winemaking and E-Commerce has to be the requirement for constant management. As I think about it, an increasing percentage of our internal technology investments go to helping our global team manage the many programs we operate for customers, and the timeframes for dealing with issues keep shrinking. Like the vineyard that has only a very limited time to turn the grape harvest into grapes, our customers have only minutes to get their data to their partners. Unlike the vintner however, our time is growing shorter (I am surmising harvested grapes today rot at the same speed they rotted for the Romans), as the pace of business picks up. This demands constanct management, so through our ever advancing visibility and alert services, we too "taste constantly" -- but I think maybe Curtis enjoys his tasting more than we do...

Advantage SaaS: Faster Go-live!

Dave Tollefsen — Thu, 31 Jul 2008 10:14:56 -0400

I am increasingly convinced that a number of big changes are happening that are likely to reshape the way businesses use technology, including cloud computing, SaaS, and the increasing ability to really compose solutions from services (think SOA that works across technologies). I believe dollars and hours are going to be the drivers of these changes, rather than pure technical considerations, and want to do a few posts to share some of the reasons. I'll start with a key SaaS virtue, which I actually believe if more a factor of the "service model" than SaaS -- rapid implementation.

Phil Wainewright's recent post over at ZDNet talks about how a SaaS provider of project management and collaboration (Daptiv), has recently released numbers on starting subscription to live usage -- and the average is less than 30 days, even for a rollout larger than 1000 users! Beyond the positive metric, I found two details about this interesting:

SaaS and service providers tend to measure the cycle from start to usage, as opposed to the somewhat misleading "production deployment" in the software world.

The metrics around cycle are automatically collected by the SaaS system

I contend that "production deployment" is misleading because in a traditional software model that is not necessarily the point where returns begin -- in fact, it is the usually the point of maximum expense! At the moment of production deployment, you typically have multiple dev and test environments licensed, lots of gear tied up, and -- most signifigantly -- lots of people consumed (developers, integrators, deployment and operations, trainers, etc). As soon as the deployment is successfully completed (assuming it is...), you then begin ramping users -- and that is where value shows up.

In an (much) earlier post, I shared GXS's own experience of doing a service based (SaaS) project in parallel to our CRM project, and how different it was -- so we have experienced this first hand.

But the fact that Daptiv has collected the metrics for its project interested me, because I think it showcases a certain mindset found in service providers -- the drive to get clients using the system. As one of the largest and most experienced B2B E-Commerce service providers, we can understand this motivation! It actually stems from the business model of "SaaS'y services" (as opposed to Professional Services...).

In a traditional software model, the vendor of the software makes the bulk of their revenue from a license -- which is usually purchased before any usage occurs. While software vendors are certainly eager to see customers succeed in the use of the software (GXS has several wonderful software partners), most large deals -- known as EAs, or Enterprise Agreements -- actually make the vendor "economically indifferent" to usage (meaning they don't get more money because it is a "site license").

Professional services often has an even stranger model -- in that the flow of money actually decreases or stops when the project is over! This is kind of like a recent driving vacation I took, where during the long drives to Boston and then Maine my boys were allowed to play as many video games (in the car) as they liked. It put them in the strange position of being sad that a 10-hour drive had to end! This is not meant to suggest PS firms don't work diligently to complete work in a fast manner -- most do. We also offer PS, and we like to see projects finish quickly, as it helps win future business (and taking too long has the opposite effect). But in the services world it is different...

When you sell SaaS-like services (and most of GXS's ECommerce services meet this description), you make your money as clients use your system. We have the ultimate incentive to get clients up and running quickly, that is when we get paid. Even better, unlike a model where the bulk of the expense occurs before any return, using services allows you to align expense and return so that large projects are more "even", rather than front-loaded. If you plan to have a community of 100 business partners, for instance, you pay for 100 only when the 100th partner joins and starts participating -- rather than the traditional "build it and they will come" approach.

This fact is obviously not lost on the service provider, which is why I believe we will always drive for shorter implementations and faster go-lives. When it comes to vacations, service providers are driving the car, and cannot wait to get there!