The Enterprise System Spectator

Tuesday, October 31, 2006

Oracle plays hardball with Linux support

Oracle just threw a monkey-wrench into the Linux machine shop. It announced last week at its user conference that it will take Red Hat's distribution of Linux, remove Red Hat's trademarks, and begin maintaining the product under a support agreement for about half the price of what Red Hat charges.

Oracle is touting its new offering, dubbed Unbreakable Linux, as a way to increase the enterprise-class status of Linux. "Oracle's Unbreakable Linux program is available to all Linux users for as low as $99 per system per year," said Oracle co-President Charles Phillips in Oracle's press release. "You do not have to be a user of Oracle software to qualify. This is all about broadening the success of Linux. To get Oracle support for Red Hat Linux all you have to do is point your Red Hat server to the Oracle network. The switch takes less than a minute."

What's striking in Oracle's press release is how many other parties are quoted as positive about Oracle's move. Oracle got Dell, Intel, HP, IBM, Accenture, AMD, Bearing Point, EMC, BMC, and NetApp all to say good things about Oracle's decision. Some of them that have their own Linux support services, such as HP and IBM, are caught between maintaining their relationship with Oracle and building their own Linux businesses.

Red Hat is in a really tough position, with its stock plunging 24% on the news. It responded on its website, with a FAQ entitled "Unfakeable Linux," in which it points out deficiencies and incompatibilities in Oracle's offering, specifically Oracle's lack of support for Red Hat and JBoss applications, as well has potential hardware, software, and other incompatibilities between Oracle and Red Hat Linux. (Red Hat's website is extremely slow today, probably because of all the hits it is getting from the Linux community on this FAQ.)

As usual, the most insightful commentary is on Slashdot, if you can find it. For example, "Korgan" writes...

Actually, the whole reason they're doing this is because they're pissed off with Red Hat for buying JBoss when Oracle wanted it.

I kid you not. Search Google for comments from Larry just after Red Hat made the purchase and you'll see why.

This is just continuing that. Oracle at the time said they were considering their own Linux distro in an attempt to compete with Redhat. To paraphrase Ellison...

If Redhat are going to step on our toes, we'll stomp on theirs

This isn't going to make any real difference to Redhat in the long term. Oracle would be smart to position their distro as the best possible platform for their own primary products (such as the databases, ERP software and so on.) However, the chances of that are pretty slim.

Given Oracle just recently released a mammoth patch for their 9i and 11i products that, while containing more than 100 bug fixes, didn't manage to fix all known bugs, I seriously doubt they're in any way prepared to take on the responsibility of a full fledged Enterprise ready Operating System. This is going to kick them hard.

Although I think this may overstate Oracle's motives, I don't think it is far off. It wouldn't surprise me at all, now, if Oracle's intention is to drive down Red Hat's stock price and ultimately be able to buy Red Hat along with its recent JBoss acquisition.

That would allow Oracle to own the entire technology stack, from operating system through database and middleware, all the way to enterprise applications.

Friday, October 27, 2006

TomorrowNow a threat to Oracle's maintenance business?

I conducted a phone interview last week with Andrew Nelson, founder and CEO of TomorrowNow, a third-party maintenance support provider for Oracle's PeopleSoft, J.D. Edwards, and Siebel products. I've mentioned TomorrowNow in the past, but I was interested in how its business has been progressing in the year and a half since it was acquired by SAP.

TomorrowNow has not yet announced its third-quarter results, but Nelson indicated a major increase in new customers: over 200 today, with 60% running PeopleSoft, 30% on JDE, and 10% with Siebel (its newest support offering). The firm plans to offer support for Baan (now Infor's ERP LN) beginning in January 2007, and has already signed up some customers for this offering. Over the past year, TomorrowNow has built out its worldwide support organization to Europe, Asia, and Australasia, in addition to its base in the U.S.

Target MarketAlthough TomorrowNow markets its services for all users of PeopleSoft, JDE, and Siebel, in my view there are a few key segments where the firm's offerings are most attractive. Nelson confirmed that one sweet spot is companies that are running SAP globally but still have instances of PeopleSoft, JDE, or Siebel. These firms, which may be looking to standardize on SAP, have little reason to stay on Oracle support contracts, and they welcome a lower-cost option that is backed by a major player such as SAP.

Another sweet spot is companies that have many modifications and do not intend to upgrade Oracle's Fusion product. In Nelson's view, such customers are paying maintenance fees to Oracle (at 22% of their license cost) to "prefund Fusion," even though they have no intention to upgrade to Fusion. Why shouldn't they save 50% or more on maintenance fees by going with TomorrowNow?

Furthermore, TomorrowNow actually supports the customer's modifications to source code as part of the support contract. Oracle's support agreements, in contrast, only provide support for original source code.

A Threat to Oracle?The short answer is no, and yes. On the one hand, even with TomorrowNow's apparently prosperous third quarter, the firm's scale is still small. Its 200 customers are a drop in the bucket in terms of Oracle's installed base. Its 200 or so employees are a small workforce compared to the thousands in Oracle's support organization. The bulk of Oracle's customers are fearful of cutting off maintenance support from Oracle. As discussed earlier, TomorrowNow's greatest appeal is to customers that are either planning to migrate away from Oracle's products or have so highly modified their systems that they have no plans to upgrade.

On the other hand, third-party support providers play an important role in tipping the balance of power a little bit back toward the customer. It's no secret that the major software vendors derive a healthy part--sometimes even the bulk--of their revenue from maintenance agreements. It's something of a captive relationship. Once a customer has implemented a major enterprise system, it's not an easy matter to change systems. If the software vendor is the only source of support, the vendor can almost name its price and the customer has little choice except to "go naked" (drop support).

But the existence of third-party support organizations such as TomorrowNow gives customers a much-needed choice, which pulls the balance of power back toward the customer, even if the customer does not choose to go with the third party.

As the enterprise software market continues consolidation, there are many good packages that are being lost in the portfolios of the remaining vendors. Infor's collection of 50-plus systems is an extreme example. Vendors enjoy a continual revenue stream of maintenance dollars from the installed base of each of these systems. But if they get greedy, it's likely that we'll see many more providers such as TomorrowNow stepping in to deliver more value at a lower price.

Sunday, October 22, 2006

Trends in IT security threats

Over at Computer Economics we're running a new survey on the current and expected severity of various IT security threats. If you have responsibility for IT security in your organization, please take the 10 minute survey now.

Respondents who complete the survey will receive a free summary of the results, which will be useful in assessing the relative priority of IT security measures to counter these threats.

The pointlessness of user security training

"Might it be so that we use the term and concept of user education as a way to cover up our failure?" he asked a crowd of security professionals. "Is it not somewhat telling them to do our job? To make them be a part of the IT organization and do the things that we are bound to do as a specialized organization?"

In Gorling's view, the answer to those questions is yes. In corporations in particular the security task belongs with IT departments, not users, he argued. Just as accounting departments deal with financial statements and expense reports, IT departments deal with computer security, he said. Users should worry about their jobs, not security, he said.

On the one hand, Gorling does have a point. Filtering out email attachments containing malicious code is a far better approach than exhorting users not to click on attachments from unknown senders. Similarly, new browser technology to flag counterfeit websites is a more effective solution than trying to train users to discern a phishing attempt.

On the other hand, I don't think user security training is pointless. The primary focus, however, should be to educate and remind users of the organization's security policies, such as acceptable use of computing resources, such as use of e-mail, instant messaging, backup procedures, encryption, and wireless access.

By the way, at Computer Economics we've just launched a new online survey regarding IT security threat trends. The survey takes about 15 minutes, and if you respond we'll send you a free copy of the resulting report. Take the survey now.

Tuesday, October 10, 2006

Salesforce.com to allow customization of its hosted service

Salesforce.com, the hosted CRM provider, is introducing a Java-like programming language called Apex to its services. Apex, which is currently in beta-testing, will allow users of Salesforce.com to customize the service or add new features. General availability is expected by the end of the second quarter of 2007.

CEO Marc Benioff announced Apex in his firm's Dreamforce conference in San Francisco yesterday.

The new capability allow users to go beyond mere customization of the user interface. It allows customers to add entire chunks of new business logic to the application. According to a presentation on Salesforce.com's website, Apex operates in a fashion similar to triggers and stored procedures.

What's really interesting about Apex, however, is that Salesforce.com is built on a multi-tenant architecture, which means that Apex code for each customer is being segregated from the code from every other customer, even though each customer is running on the same instance of Salesforce.com.

If Salesforce.com is successful with this capability, it removes one more objection to software-as-a-service (SaaS), the inability of individual customers to customize it. It is consistent with the firm's related work on its AppExchange platform, which allows customers to build, share, and sell entire applications running within Salesforce.com's hosted environment.

Wednesday, October 04, 2006

Compiere's open source ERP business model and growth plans

Late last week, I interviewed Jorg Janke, founder and CEO of ComPiere Inc., an open source ERP/CRM developer. In June, the firm announced it had received $6 million in venture capital to expand its business, and I wanted to find out what it planned to do with the money. I had also gotten word of a plan by a few members of Compiere's open source developer community to "fork" Compiere's source code into a separate version, and I wanted to get Janke's view on that.

Through the rest of this post, "Compiere" refers to the open source product, and "ComPiere Inc." refers to Janke's corporation, which manages the development of Compiere.

Business ModelLike most attempts to make money with open source, ComPiere Inc.'s business model requires some explanation. Janke along with co-founder Kathy Pink began Compiere development in 1999. They released it under an open source license that mimics the Mozilla Public License. Basically, this means tha anyone can download the software, play with it, implement it, use it, and enhance it--all at no charge. You can even redistribute it and create derivative works from it as long as such derivatives are distributed under the same open source license.

ComPiere Inc. makes money by offering services to its worldwide network of consultants, many of whom pay a fee to ComPiere Inc. to become "Partners," in exchange for sales and marketing support, second level technical support, and training services.

The Partners, which currently include about 100 organizations employing a total of 300-400 individuals, make money by providing traditional implementation and consulting services. Some of the Partners also develop complementary products or extensions to Compiere, which they are free to sell as proprietary products, as long as they do incorporate Compiere's source code. (ComPiere Inc. itself makes money from sales of proprietary products, such as migration tools that facilitate upgrade between versions of Compiere.) Partners also form the bulk of Compiere's open source development community, as they submit bug fixes and enhancements to Compiere Inc. for incorporation into the product.

In addition, Janke estimates that there are another ten to fifteen "freelancers"--independent consultants who are not Partners but provide implementation consulting services for Compiere. These freelancers also participate in Compiere's development community.

Business VolumeSince there are no sales transactions recorded for open source software, it is difficult to make head-to-head comparisons between Compiere and commercial software vendors such as SAP or Oracle. Open source projects like to use "number of downloads" as a substitute for sales figures, but although these numbers may run into the hundreds of thousands or even millions, they do not represent actual use of the product.

I was able to determine from Janke, however, that there are about 250 companies paying for support from ComPiere Inc. or its Partners, which is a pretty good indication of Compiere's installed base. There are, no doubt, some companies that have downloaded Compiere's source code and have managed to run it in production without any knowledge of ComPiere Inc. or its Partners. According to Janke, some of these companies eventually reach out to Partners for support, especially when they get in over their heads. But the total number of such organizations is difficult to determine.

Problems in the Development CommunityAs indicated earlier, there have been grumblings among Compiere's development community that have evolved to the point that a few of the non-Partner developers (freelancers) have forked development of Compiere into a separate open source project, dubbed Adempiere.

A public discussion on the decision to fork Compiere's source code is available, and it provides interesting insights into the dynamics of an open source development community.

The motivation to fork Compiere's source code seems to be centered around several issues:

The speed at which ComPiere Inc. processes fixes and enhancements submitted by contributors and the refusal, in some cases, to even accept them.

The refusal of ComPiere Inc. to provide Compiere version migration tools except in the sale of a support agreement.

Rumors that ComPiere Inc. is planning to limit the functionality of its open source offering, to better position some future proprietary offering.

I asked Janke about each of these issues. In the case of the first, Janke admits that resources at ComPiere Inc. have been limited: basically, all product development at ComPiere Inc and contributions from the community are funneled through Janke and Pink. One of the reasons that ComPiere Inc sought venture capital was to be able to hire more developers to support contributor efforts to enhance Compiere.

In the case of the second issue, Janke indicated that licensing of migration tools is one of the services from which ComPiere receives revenue, which it needs in order to fund its services to the development community.

As for the third issue, Janke denied any plans to restrict functionality of Compiere in order to make a separate closed-source offering more attractive. I would also add that if a closed source offering made any use of Compiere's source code, it would by definition need to be an open source product. After our discussion, Janke wrote an even stronger rebuttal of this point:

There is certainly no plan to cripple the product or discontinue or "privatize" functionality - the very opposite is the case. We will continue to develop substantial new functionality Open Source, and hope to increase Open Source contributions from the community. It's disconcerting to see people spreading unsubstantiated false rumors in this regard.

Janke said that he hopes the addition of new developers at ComPiere Inc. will enable new enhancements and fixes submitted by the development community to be incorporated more quickly, and that the developers who have forked the source code will want to return to the original Compiere project. It takes a lot of work to maintain an open source project, and certainly one combined effort will be more productive than two.

While I was writing this post, Janke wrote a Compiere status update that addresses the issues I have outlined above, and more. It is worth reading for a more complete view of what ComPiere Inc. is doing with the venture funding.

The future of open source ERPCompiere is just one attempt to build a complete ERP system under the open source model. Open For Business (OFBiz) is another. ERP5 and Tiny ERP are still others. OpenMFG might be considered as well, although its license is not truly open source. In addition, there are several open source CRM projects, most notably SugarCRM, which offers an open source version as well as a "professional" or commercial version.

Although open source ERP has been gaining some ground, none of these projects match the scale of open source efforts such as Linux, Apache, mySQL, or JBoss. It appears that the higher one moves up the technology stack, the more specialized the requirements and the narrower the development community. ERP applications, at the top of the stack, would appear to be the most difficult market in which to sustain an open source development effort.

If this be the case, then it would appear that the primary success factor is a critical mass of developers. ComPiere's greatest asset, in my opinion, is not Janke's knowledge and experience as a developer--it is the 100 Partner organizations that are committed to extend, enhance, and support Compiere. Janke is right to devote a good chunk of his venture funding to hire new developers (he indicated four new programmers added in the past few weeks, and a total goal of about 20 a year from now). His development staff's top priority should be the rapid evaluation and incorporation of changes submitted by the Partner network. In addition, the freelance contributors should be treated the same as the Partners--if they have fixes or enhancements, they should be evaluated on the quality of their contributions and not given lower priority just because they don't pay a Partner fee. The freelancers--especially those in developing countries--have more time than money, and ComPiere Inc. should take advantage of that fact. The development community--whether Partner or freelance--is the competitive advantage for open source, and organizations such as ComPiere Inc. should take every opportunity to serve and grow that community.

Other open source projects, such as Linux and the others mentioned earlier, demonstrate that open source products can be as good or better than their commercial equivalents and that they can even claim a dominant market share, as in the case of Apache for web servers. Open source ERP may not reach this level of market share, but it can certainly gain more than it has today--as long as it fosters a robust and thriving development community.

Sunday, October 01, 2006

i2 innovates with hosted vendor-managed inventory services

I've written quite a bit in the past about i2's fall from leadership in the supply chain management software business. For example: i2's virtual abandonment of its SRM business. So, it's good to see something that appears to be a real innovation for i2.

i2 dubs the new offering "planning as a service (PaaS)." It combines i2's supply chain management software, hosted as a software as a service (SaaS) offering, with offshore business process outsourcing (BPO) services to operate the program on an ongoing basis.

i2's offering appears to be an outsourcing arrangement more than anything else. For example, a large consumer packaged goods manufacturer might go to i2 for help in setting up a vendor-managed inventory program. Instead of just selling software to the manufacturer and letting the customer struggle to put together all the pieces, i2 now takes the lead for all aspects of the program. It does the analysis to build the business case, designs the to-be process, sets up and tests the design through a pilot program, and implements and executes the full program on an on-going basis.

The software can be hosted by i2, or, if the client prefers, it can run the system behind its own firewall. The outsourced personnel are largely located offshore, in Banglore, India, playing to i2's strong relationships there. My source indicates that i2 is also looking at other offshore locales, including one in the Central or South America to balance out the time zones around the world. The offshore connection also suggests that i2 will be able to scale the offering more easily than if these personnel were located in the U.S. Early experiences indicate that i2's resource requirements are most heavy at the initiation of the project, when there is much work to do in understanding the client's business and normalizing/cleansing the client's data. Once the relationship moves into ongoing execution, the resource requirements taper off quite a bit.

Some might argue that i2 is finally recognizing what its clients were really looking for all along. Supply chain consultants have told me in the past that i2's products were really more of a tool set than complete package, and that it took a lot of skill and experience to tailor i2's products as part of a supply chain program that is specific to a given company and industry. Many clients simply do not have the expertise to do this.

Now, by taking responsibility for the entire program, including the results, i2 is aligning its resources to meet the real needs of the client. I suspect it is also enjoying a much larger budget (the whole pie) than it would get by just providing software and implementation service, which are just two small slices.

Before deploying this consumer-oriented solution, Panasonic suffered from misdirected inventory, stock-out problems, and dead inventory in slow markets. Sales and profits were weak, and relations with key retailers were less than ideal.

After implementing the i2 solution, inventory distribution is now completely aligned with consumption, and customer availability jumped from 70% to 95%. The average week of supply in the channel went from 25 weeks in 2004 to just five weeks--and trending downward--in 2005. Unit sales of the targeted plasma television rose from 20,000 the previous year to approximately 100,000 in 2005. Operating profits for the business unit went from a 10% net loss in 2004 to a projected 13% profit for 2005.

Best Buy, the initial retailer covered by the vendor-managed inventory model, has since elevated Panasonic from a Tier 3 Supplier to a Tier 1 "Go To" Brand for plasma televisions.

Panasonic was i2's first success with its new VMI service, and my source indicates that there are two other consumer industry clients in implementation as well as two clients in high tech electronics that are in process. These accounts are not yet ready to go public, but their early progress is quite encouraging.

I believe that i2's offering is a good example of how technology providers can combine the concept of SaaS with managed services, including offshore outsourcing, to deliver greater value to clients. Other traditional vendors should take note.

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision.
My consulting firm, Strativa, offers assistance that is independent and unbiased.
For information on how we can help your organization make and carry out these decisions, write to me.

For reprint or distribution rights for content published on the Spectator, please contact me.