Big Shift: NetSuite Moving to Oracle Cloud Infrastructure

In recent years, Oracle has been intensely focused on its cloud strategy as the key to its growth. At Oracle Open World 2016, with the announcement of Oracle’s second-generation cloud infrastructure, Larry Ellison said, “Amazon’s lead is over.” It was an ambitious goal: At the time, Oracle’s cloud infrastructure (OCI) business was bringing in less than $200M per quarter.

Uptake of Oracle’s cloud applications is great, but when it comes to Oracle really competing with Amazon or Microsoft as a platform for independent software vendors (ISVs), the story is different.

The absence of multitenant ISVs on OCI is not because of a lack of capabilities. Oracle’s flagship database, since v12c was released in 2013, has built-in multitenancy in the form of database containers, which allow multiple tenants to share a single Oracle database, with individual containers assigned to each tenant. This approach puts the multitenancy into the infrastructure layer, allowing developers to focus their efforts on application development, not on the mechanics of multitenancy.

Oracle’s lack of commercial SaaS providers building on OCI is about to change.

Read the rest of this post on the Strativa blog:
NetSuite on Oracle Cloud Infrastructure: What It Means for Customers

Open Source Not a Panacea for Cloud Infrastructure Decisions

When it comes to cloud computing, do open systems win out over proprietary standards? My view is, perhaps in theory, but cloud computing--specifically public cloud infrastructure--has bigger problems right now than whether it's built on open source. Furthermore, open source cloud infrastructure providers have obstacles to overcome. 

I'm participating in an online video debate on October 29, hosted by IBM's Smarter Computing program, on "the pros and cons of open computing when it comes to cloud, big data, and software defined environments." This post outlines part of my viewpoint on this subject.

What's Not to Like about Open Source?

One of the problem in debating "open source" is that it is difficult to argue against the word "open" as a concept. For example, we all like to think of ourselves as open-minded, not close-minded. We admire top executives who have an open-door policy--have you ever heard of a manager with a "closed door policy?" In home-buying, sellers like to point out the open floor plan. Who ever advertised a house as having a "closed" floor plan?

So also, in computing, open just sounds better. Moreover, when it comes to cloud infrastructure, open source projects such as OpenStack and CloudStack have admirable goals, such as the ease of porting computing workloads from one cloud provider to another, promoting competition, and escaping the dreaded vendor lock-in.

The Larger Issue: Adoption

But, to me, it is premature to debate about whether open source cloud infrastructure is better. The larger issue today is the small percentage of corporate IT organizations that embrace public cloud infrastructure at all. In our Technology Trends survey at Computer Economics last year, we found that less than 10% of IT organizations worldwide have any use or plans to use public cloud infrastructure. Moreover, of these, only half claim use it, or intend to use it, for production systems.

If they are not using public cloud for production systems, then what are they using it for? Our survey found interest in public cloud for software development and testing, disaster recovery capabilities (such as backup and recovery), or for archiving older data.

In addition, I question some of those production uses of IaaS. Discussions with associates who advise data center managers confirm my suspicions. One associate, who works a lot in the entertainment industry, pointed out that one popular use of cloud infrastructure is in rendering animated film. In this case, animators require enormous amounts of computing power and storage to render even a few minutes of animation. As it turns out, cloud infrastructure is perfect for such a use, as it frees the IT organization from having to maintain those high levels of computing resources, which are only used sporadically. Furthermore, the risk is low. If the cloud provider goes down in the middle of a rendering job, the animator can simply resubmit the job. Nothing is lost.

But when it comes to production systems, such as accounting systems or royalty processing, these same entertainment industry decision-makers shun cloud infrastructure. It is not that they want to keep such systems on-premises, as witnessed by the fact that they have been outsourcing their data centers to managed services providers for years. As my associate remarked, "CIOs don't want to be in the data center business any more." But, rightly or wrongly, they are cautious about entrusting production systems to a cloud infrastructure.

Open Source Not a Panacea

Although the goals of OpenStack and other open source cloud projects are admirable, they may be a solution in search of a problem.

• Specifically, migrating workloads between competing cloud providers may not be as big a deal as open source proponents claim. Customer demands are already forcing competing cloud providers to recognize and support each other's APIs. For example, some members of the OpenStack community are urging support for Amazon's APIs.  If OpenStack fully goes this route, application systems written for Amazon's cloud will be able to be deployed on an OpenStack cloud without a lot of migration effort. Even VMware--the vendor with the largest stake in so-called private clouds--supports Amazon APIs and is also a contributor to OpenStack. Therefore, as far as I can tell, portability is not a major issue.

• Second, so far, it does not seem as if proprietary cloud providers are using their proprietary standards in order to extract higher fees from customers. Quite to the contrary, cloud infrastructure is a very competitive market. Whatever concerns IT decision makers have about public cloud infrastructure, one thing they cannot complain about is its cost. Leading cloud providers are not raising prices--rather, they are cutting prices, in some cases many times a year. IT decision makers are not holding on to their on-premises systems because they are concerned about the cost of public cloud--they are focused on risk. This was also a key finding in our Technology Trends survey.

If a cloud provider wants to overcome enterprise IT buyer concerns, it should focus on reliability, security, privacy, and offer a well-staffed support group. Many of the OpenStack providers are doing exactly that. It may well be that OpenStack providers, such as IBM, H-P, Dell, Rackspace and others, will be successful because of their value-added services, not because they embraced an open source infrastructure.

Incumbent Infrastructure Providers Have an Edge

Furthermore, proponents of open source cloud infrastructure may be underestimating the advantage that on-premises infrastructure providers have in moving their customers to the public cloud. Although, as discussed above, IT leaders have concerns about moving production workloads to the public cloud, one thing that does appeal to some of them is the ability to move seamlessly from on-premises system instances to cloud instances.

This is the so-called hybrid cloud infrastructure. CIOs may adopt a hybrid cloud strategy in order to move non-critical workloads out of the data center, freeing up system resources (e.g. the animation rendering application discussed above), or to "burst" to the cloud during period of high demand for system resources (e.g. during a major advertising campaign that strains an in-house e-commerce system).

Now, which provider has the advantage in helping IT organizations set up hybrid cloud capabilities? The provider that is already serving the on-premises data center (Microsoft, VMware, or Oracle, for example) or the one that would like the data center to replatform its on-premises systems to match the infrastructure of the provider's cloud infrastructure (e.g. OpenStack, CloudStack)?

The answer is obvious, which is why Microsoft, VMware, and Oracle are all providing public cloud services that require very little change to the customer's on-premises infrastructure. Unless an IT organization is building a data center from scratch, it is unlikely to want to standardize its internal infrastructure on a completely new technology--open source or otherwise.

Advocating for Cloud and Open Source

Nothing I've written here should be taken as an argument against cloud computing or open source. I've been blogging on these subjects since 2002 and consider myself as an advocate of both. In my view, one day nearly all systems will be delivered via cloud computing, and open source software has proven itself to be a viable business model for a variety of software categories, especially for lower levels in the technology stack. But in the case of public cloud infrastructure, I don't see open source cloud projects as dominating the market any time soon.

Update: The video of my IBM debate is now online. You can watch it by clicking the image below.

Related Posts

The Inexorable Dominance of Cloud Computing
Cutting Through the Fog of Cloud Computing Definitions

Photo Credit: Flickr, followtheseinstructions

SAP's Emerging Cloud Platform Strategy

I participated last week in two days of SAP briefings with a group of about 15 bloggers. Part of the time was devoted to explaining SAP's evolving cloud strategy, which I will attempt to summarize in this post. 

Keep in mind that what I'm sharing here is not SAP's own messaging around its cloud strategy. Rather, it is my interpretation of where SAP is going and what it needs to do to be successful.

SAP Has a Proliferation of Cloud Assets

Over the past few years, SAP has been at work rolling out a number of cloud services. The most well-known is Business ByDesign (ByD), a full-suite ERP system, written from the ground up for software-as-a-service (SaaS). This was an enormous development effort, and it went through two development iterations until 2011, when it was ready to scale in production. SAP now has over 1,000 customers running ByD.  

Following initial delivery of ByD, SAP also began rolling out its line-of-business applications. These were built on the ByD cloud platform to meet the needs of specific business functions, such as sales force automation (Sales OnDemand) and expense reporting (Travel OnDemand). There are others, also.

Then in 2011, SAP acquired SuccessFactors, a well-respected cloud-only HRMS vendor. This greatly increased SAP's stature as a SaaS provider, but it also added another set of cloud assets and executive leadership to the mix. Further adding to the complexity: SAP is in process of acquiring Ariba, the venerable provider of supplier networking services.

From Cloud Applications to a Cloud Platform

In my view, the current situation has led to a number of problems. First, SAP's cloud portfolio is largely a collection of unrelated systems, and several different cloud platforms. There has been no common architecture, and no integrated product roadmap.

Second, the rest of SAP's product porfolio is not standing still. Specifically, SAP has been making large investments in its in-memory database technology (HANA), and it has acquired and developed an impressive array of mobility applications and mobility platforms. All of these products have cloud-delivery aspects. 

Third, SAP lacks a single extensible cloud development environment. (ByD does have a PaaS capability, for partners only, but it is limited to ByD.) Customers and partners don't just want cloud apps, they want the ability to extend those apps and build new applications that can interoperate with them. In other words, they want PaaS (platform-as-a-service) in addition to SaaS.

SAP's emerging cloud strategy addresses all of these issues: it embraces all of SAP's existing applications as well as its database and mobility platforms, and it gives customers and partners a development environment to build upon and extend these services.

Here are key aspects of SAP's cloud strategy, as I see them:

1. Everything as a Service. Behind the scenes, SAP has been rearchitecting its SaaS offerings to be delivered as web services. For example, it has broken up ByD functionality into 32 "honeycombs," so that no two of them share a common database. Rather they communicate via messaging. SAP has taken the same approach with its line-of-business applications.  In fact, all of SAP cloud applications will be deployed as web services, including its mobility and database offerings. I have to believe this also includes SuccessFactors. SAP will now be able to sell individual modules (e.g. Finance), or a complete suite, or combinations in between.
    
2. Platform-as-a-Service. SAP has built a PaaS capability, now referred to as the SAP Netweaver Cloud (earlier code-names included JPass, Neo, and Project River.) It is intended as a multi-language/multi-framework platform. It is primarily a Java-platform, but its open nature also allows development in a variety of other languages, such as Spring and Ruby. Furthermore, it allows developers to access all of the SAP cloud applications, database services, and mobility services that are now accessible via web services (see point #1).  It even allows applications to access SAP on-premises systems such as SAP ECC, CRM, and HCM. Conceivably, therefore, the Netweaver Cloud could be used for customizations/extensions of SAP on-premises systems that have been traditionally done with ABAP coding.
    
3. Ecosystem. The SAP Netweaver Cloud can be used internally by customers or their system integrators, and it also can be also used by third-party developers to build new applications for sale on the SAP Store. This facilitates the growth of SAP's developer ecosystem.

The Netweaver Cloud runs in SAP's own data centers (including those gained through the acquisition of SuccessFactors). There are a number of other features, such as identity services and document services, which I won't go into in this post.

The Pluses and the Minuses

There are several things I like about SAP's emerging cloud strategy.

1. Integration. SAP's is finally integrating all of its cloud assets into a single platform. If successful, nearly anything SAP delivers should be available and accessible through Netweaver Cloud.
    
2. Openness. Netweaver Cloud does not use a proprietary language, like Salesforce.com's APEX. Use of public development languages, such as Java and Ruby, facilitates adoption by developers and also works against lock-in to a single platform. Likewise, the PaaS makes use of open source projects from Apache and Eclipse, which should further facilitate adoption by developers. 
    
3. Availability. Netweaver Cloud has already been released to customers, and it is scheduled for general availability at the end of this month. A free 90 day trial is already being offered. This puts SAP out ahead of Oracle, whose Oracle Public Cloud is still in controlled availability (though hopefully there will be announcements at Oracle's Open World conference next month).  

On the other hand, there are some aspects that give me concern.

1. Will Customers Understand It? The cloud-only providers have one great advantage: simplicity. Everything Salesforce.com builds is on its Force.com platform. Likewise, enterprise cloud leaders such as NetSuite and Workday grew up with single platforms. Their platforms are relatively easy to explain and easy to understand. SAP, on the other hand, has a variety of on-premises and cloud systems. Furthermore, it has built or acquired a variety of database products and mobility applications and platforms. The SAP cloud platform must now deal with all of these products. It's not easy to explain, as witnessed by the difficulty SAP's own team had in communicating it with our group of tech bloggers. If the bloggers struggle with understanding it, what hope does SAP have to make the message clear to customers or prospects?
    
2. Will Developers Adopt It? Developers are a key to success in cloud systems, just as they are in mobility applications. Salesforce.com already has a large and enthusiastic ecosystem of developers for its Force.com platform. Microsoft has an enormous ecosystem of development partners, for whom Microsoft's cloud platform (Azure) is more-or-less an incremental step in using existing Microsoft development tools. Will SAP's current population of partners readily embrace Netweaver Cloud, or will they be content to continue development in the SAP tools they have been using for years? 
    
3. Is SAP Too Late? Salesforce.com's PaaS was first introduced in 2006 (I wrote about it at the time, here). NetSuite has had CloudSuite for years. Microsoft has already rolled out and continues to refine its Azure PaaS. SAP is only now rolling out Netweaver Cloud. Though SAP denies this, I do believe that its cloud development efforts in recent years have taken a back seat to its database and mobility development efforts. So now, SAP is playing catch-up. SAP has a lot of work to do to be perceived as a cloud leader.

Regarding that last point, on the other hand, my research at Computer Economics shows that PaaS is a technology that is still in the early adopter phase. Most organizations are still buying individual SaaS applications and have not yet made a strategic commitment to cloud computing as a platform. They have hybrid systems: some on-premises, and some in the cloud. Of course, there are exceptions: these are the early adopters that embrace cloud computing not only for SaaS applications but for PaaS as a development strategy. Nevertheless, the majority have not yet seen the vision. Therefore, if SAP can quickly make its cloud strategy clear and deliver working product, it may still have a shot at being a major player.

Here are some reports from other bloggers who were at this event:

• Vijay Vijayasankar: SAP Needs A Better Cloud And Platform Story, And A Good Story Teller 
• Jarret Pazahanick: SAP Briefing - Cloud, Mobility and HCM 
• Fellow bloggers Vijay Vijayasankar, Jon Reed, John Appleby, and Harald Reiter: Video discussion on SAP Cloud, Mobility, and Database Strategy

Disclosure: SAP paid for part of my travel expenses to this event. 

Related Posts

SAP in Transition on Mobile, Cloud, and In-Memory Computing
SAP innovating with cloud, mobile and in-memory computing
Salesforce.com to allow customization of its hosted service 

Making Sense of the New Epicor

Epicor held its annual Insights user conference this week in Las Vegas. This was the first gathering for customers of both Epicor and Activant since the two firms merged last year. As such, it was a good opportunity for the firm's executives to introduce what they are calling the "New Epicor" to 4000 conference attendees.

Three Elements of Strategy

Although Epicor made many announcements, in this blog post I prefer to focus on three elements of Epicor's strategy, along with my point of view. 

1. Blending of Two Cultures. CEO Pervez Qureshi and other presenters made a point of emphasizing the new Epicor as a blending of the best of "heritage Epicor" and "heritage Activant." (In the enterprise IT world, the word heritage is preferred to legacy.) Qureshi characterized heritage Epicor as having been a global company, technology-oriented, entrepreneurial, and top-line focused. Heritage Activant, he said, was oriented more toward service, process excellence, and profitability. The new Epicor blends the best of these two cultures, he claimed.
    
2. Protect, Extend, Converge. The second element is Epicor's strategy and vision to protect, extend, and converge the product portfolio. "Protect" means to continue investment in the current products in its portfolio. "Extend" means to introduce new applications and infrastructure capabilities that deliver additional value across current products. Finally, "converge" implies a gradual evolution of current products with new technologies.
    
3. Azure as the Cloud Platform. The third element is Epicor's evolving cloud strategy. Prior to the conference, Epicor's cloud strategy was limited to a small business cloud version of its Epicor ERP product ("Epicor Express") along with some hosted solutions for functions such as HCM and retail merchandising. However, the strategic direction announced at Insights went much further. Wading through the dense language of the press release, I see the Azure announcement as having three sub-parts: (a) Epicor will allow its Epicor ERP product to be deployed on Microsoft's Azure cloud platform, planned for Q3, 2013, (b) Epicor will also use Azure to provide interoperability between on-premises Epicor systems and Epicor point solutions deployed on Azure. (c) A new version of Epicor's SOA middleware ("ICE") will also be deployed on Azure to provide a PaaS offering, facilitate mobility apps, and satisfy other integration needs between Epicor and third-party products.

Epicor executives were upbeat in presenting these and other elements of the new Epicor. But how differentiated is Epicor's strategy, and what does it mean for Epicor customers? Here's my take.

The Azure Strategy is a Winner

Taking these three elements in reverse sequence: although I do not see the Azure strategy as unique, I do see it as attractive. In fact, it is more attractive because it is not unique.  Epicor is at least the fourth major enterprise software vendor in the past three months that has announced plans to deploy ERP in the Azure cloud. The first, of course, is Microsoft Dynamics, which in March announced its plans to deploy Dynamics GP and Dynamics NAV on Azure by the end of 2012.Then, earlier this month, Sage announced similar plans. And now, Epicor.

I have no doubt that others will follow, making Microsoft Azure a first choice for delivery of cloud-based enterprise applications. I have long felt that, just as on-premises database management systems have been standardized on just a few popular products, so also cloud platforms should be standardized. By way of analogy, very few on-premises vendors today write their own DBMSs, with Oracle being the exception that makes the rule. Why then should SaaS providers build their own cloud infrastructure? Salesforce.com did it. NetSuite did it. Workday did it. But how many more can or should roll their own IaaS and PaaS platforms? There is a tremendous amount of cost and effort involved in doing so, not to mention the economies of scale that can only be realized by having thousands of customers. Epicor, Sage, and others are making the right choice by building on an established public cloud infrastructure provider.

Why didn't this happen earlier? Essentially, because Azure (specifically, SQL Azure database capabilities) has not been robust enough to support ERP-class applications. But in speaking with Microsoft earlier this year, it appears that these limitations are now being overcome, which explains why Microsoft Dynamics, Sage, and Epicor are all moving to Azure at about the same time.

There is one more advantage to the Azure strategy. The current Epicor Express offering is limited to customers with under 20 users. I do not believe Epicor's current infrastructure architecture allows customers to scale beyond that point in a multi-tenant environment. Moving to Azure frees Epicor from that limitation, allowing it to sell cloud ERP to larger customers, though I suspect in practice it will still be most attractive to small and midsize businesses.

Finally, moving to Azure immediately allows Epicor to offer cloud ERP in a number of geographies where it does not have partner data centers. Epicor ERP has good international capabilities. Now customers in international locations will also be able to choose cloud deployment in their own geographies to meet regulatory or performance requirements.

Strategy of "Protect, Extend, Converge" Is a No-Brainer

The protect/extend/converge message has two things going for it: it's easy to remember and and it's customer-friendly. It also happens to be the only product strategy that makes any sense for a vendor such as Epicor. Epicor's growth strategy, like Infor's and Oracle's, has been to acquire or roll up a number of smaller vendors to build a large customer base with a diverse portfolio of products. The benefits of such a strategy is clear: growth. The downside of such a strategy is the diverse portfolio. But with a certain level of attention paid to customer support, the large number of existing customers will continue to pay maintenance revenues (the mother's milk of enterprise software) and will also be candidates for cross-selling other Epicor products.

It is interesting, therefore, to compare Epicor to Oracle and Infor and to see the similarities. All three have large customer bases. All three have diverse portfolios. All three have some sort of middleware offering to connect all the solutions: Oracle has Fusion middleware, Infor has ION, and Epicor has ICE. All three have customer programs to "protect" existing customer investments: Oracle has its "Applications Unlimited" program, Infor made its promise to "never sunset" a product, and Epicor has its strategy of "protect." Likewise, all have their strategies to "extend," such as Oracle with its continued point releases of J.D. Edwards, PeopleSoft, Siebel and others; and Infor, with its continued investments in its portfolio. Finally, all have some sort of convergence strategy, such as Oracle with its Fusion Applications, Infor with its development of ION, common user interface, and other common functions.

In other words, Epicor's strategy is the only rational way to deal with a large and diverse installed base built through acquisition. Qureshi's plan to continue aggressively with new acquisitions means that successfully protecting, extending, and converging its product portfolio will become even more important.

The Culture Message Has a Subtext

I found Qureshi's keynote regarding the blending of the Activant and Epicor cultures to be interesting, if not unusual for a customer conference. It would be the sort of thing one would expect to be presented internally, in an "all hands" meeting, for employee consumption. Delivering this message to customers, however, also sends an implicit message: heritage Epicor needed  improvement in product quality and customer service.

Perhaps this subtext is so well understood by the majority of Epicor customers that there was little risk in sending this message.  Still, if Activant's strength--in contrast with Epicor's--was (among other things) process excellence and customer service, what does that say about heritage Epicor?

It didn't end with the keynote. Later in the day, there was a session on the product roadmap for Epicor ERP. The presenters were proud of reports from early adopters of the most recent point release (ERP 9.05.700). But in touting the quality of the release, they were, in effect, reminding Epicor customers of their past experiences. One customer quote was damning with faint praise, referring to the new version as:

A more solid product than we've seen before.

If my wife makes me a nice dinner, the last thing I would tell her is, "This is a more delicious dinner than you've made me in the past."

But, if Epicor customers are all-too-familiar with product quality and service delivery problems in the past, perhaps Qureshi's approach is best: to tacitly acknowledge the problem. Key executives in the new Epicor come from Activant, starting with Pervez Quereshi (CEO), Kevin Roach (EVP and GM, ERP Americas), and Paul Salsigiver (EVP and GM, Retail), sending the message that Activant's focus on software quality and service delivery processes will prevail in the new Epicor.

My question, however, is this: are customers seeing an actual improvement in Epicor's product quality and customer service? Or, is it too early to tell?

I invite Epicor customers and partners to send me an email, or leave a comment on this post. As always, confidentiality is assured.

Related Posts

Microsoft Dynamics ERP on Azure: What Are the Benefits?
Infor’s Two-Pronged Cloud Strategy

Microsoft Dynamics ERP on Azure: What Are the Benefits?

Last week I attended Microsoft’s annual Convergence conference, for users and partners of its Dynamics line of enterprise applications. The back-to-back briefings were a great opportunity to get an update on where Microsoft is going with enterprise applications.

But the big news from my perspective is that by the end of 2012, two of Microsoft's ERP products, GP and NAV, will be available on Microsoft's Azure cloud.

Click on the video interview at the right for my initial thoughts, which I am expanding upon in this post.

Azure Complements Existing Hosted Offerings

Microsoft customers have always been able to deploy NAV (formerly, Navision) and GP (formerly, Great Plains) on-premises. In addition, some customers have chosen in the past to have Microsoft partners host their systems in partner data centers. MyGPCloud is one of the largest such partners, hosting GP for thousands of small business customers. Likewise, Tribridge offers similar hosting services for all Dynamics ERP products.

Now, Microsoft is offering customers the option to deploy their GP or NAV systems on Microsoft's Azure cloud, which runs in Microsoft data centers. This offering will not replace partner hosting but simply will be another deployment option for customers.

Through back channels, I've heard some partners express uncertainty about this new development. Is Microsoft attempting to go direct with customers? How will the partners make money? During the session, Microsoft executives made clear that, under Azure deployment, partners will still maintain the customer relationship and deliver the services for implementation and ongoing support. The only difference is that with the Azure deployment option partners will be relieved from the need to maintain data center infrastructure.

What Are the Benefits?

Over the past two years, I've been one of those encouraging the Dynamics team to go faster in moving to Azure, as cloud ERP is already available from competitors. But now that Microsoft is on the verge of actually doing it, I wanted to know, what are the benefits? Specifically, if customers can already have these systems hosted by a Microsoft partner--and if Microsoft will still work through partners in selling and supporting systems deployed on Azure--what are the added benefits of Azure?

I asked this question a year ago at Convergence and, frankly, the answers were not that clear. After asking this same question in several briefings this year, and adding my own analysis, I think the benefits picture is now emerging.

• Azure deployment is cheaper than hosting. Azure is a true elastic cloud platform, with data center economies of scale that traditional hosting cannot come close to matching. This should allow Microsoft to price these services at a lower cost than what partners can offer.
• Azure deployment scales beyond partner hosting. As a true cloud platform, Azure deployments can scale instantly beyond what partner hosting can offer. Hosted ERP relies upon dedicated resources, which must be planned and expanded manually to meet changing customer requirements. With Azure, customers will never exhaust the resources available.
• Azure supports worldwide deployments better than partner hosting does. Microsoft runs Azure data centers worldwide and can move customer systems and data between them as needed. Hosting partners do not have this capability, unless they are utilizing a true cloud IaaS, such as Amazon's EC2. The move to Azure is therefore a better choice for organizations that are running separate instances in different parts of the world.
• Azure deployment provides easier version upgrades. With partner hosting, upgrades and maintenance are handled more or less as they are with on-premises software: each customer is treated separately (though I suspect some partners are more organized about this than others). With Azure deployment, Microsoft will have a more disciplined approach to application management: rolling out new versions, upgrades, and patches to its customers, similar to what it does today with Microsoft CRM (even though, as I point out in the interview, CRM is not yet an Azure service).
• Azure deployment is provided directly by Microsoft. Most new prospects will have a higher level of comfort with cloud services provided directly by Microsoft and backed by the Microsoft brand and service level guarantees. Hosting is often delivered by service providers who are relatively unknown. The direct Microsoft relationship is also simpler and easier to explain. The software comes from Microsoft and the cloud services are delivered directly by Microsoft.

It is also important to point out at least one advantage of Azure deployment over partner hosting that Microsoft is not claiming--that is, that Azure deployment provides the ability to inter-operate with other Azure services, such as Office 365 or other future Azure data services (some of which I was briefed on). Microsoft has made a big deal about its vision of the so-called "hybrid cloud," meaning that customers will be able to move selected "workloads" to Azure while keeping other workloads on-premises or in partner-hosted data centers. Therefore, if I want to inter-operate Microsoft's Office 365 with my NAV system, it should not make any difference if my NAV instance is on-premises, in a partner data center, or on the Azure cloud.

Optimizing Azure as a Cloud Platform

I am struck by the fact that I've had to piece together this value proposition for Azure ERP myself, lobbing softball questions to Microsoft executives, parsing their answers, and adding my own analysis. If Microsoft itself is not prepared to articulate the value proposition of Azure ERP, how can it expect that its customers or its partners will perceive it?

Therefore, I do not envision customers and prospects staging a mad rush to Azure. As I said in the interview linked above, what if Dynamics throws an party and no one shows up?

Nevertheless, from a strategic perspective, I do believe that moving to Azure is the right thing for Dynamics. Mike Ehrenberg, one of only a handful of Microsoft Technical Fellows, told us an interesting story. He said that when they first spoke with CEO Steve Ballmer about moving Dynamics ERP to the cloud they told him that they could do it in one of two ways:

1. The quick way: hosting it in Microsoft data centers in a highly virtualized environment, as they had done with Microsoft CRM, or
2. The strategic way: working with the Azure team to optimize the Azure capabilities needed to support true scalable enterprise business applications, such as SQL Azure, until it could support Dynamics ERP.

Mike reported that Ballmer thought for about two seconds before choosing the second option. He likened it to Microsoft Windows and Microsoft Office, years ago. It took the requirements of Office as a set of user applications to make Windows "become better" as a PC platform. Likewise, it would take Dynamics as a set of enterprise applications to make Azure become better as a cloud platform.

The problem, of course, is that it's taking much longer to develop Azure as a enterprise-class platform. In the meantime, competitors such as NetSuite, Workday, SAP, Plex, and others have already become established as cloud ERP providers and have gained market share in this emerging market. Nevertheless, Microsoft entering this market later this year is a welcome development that will mean an increasing number of choices for buyers.

Postscript: watch for Part 1 of my market overview of cloud ERP over the next few weeks.