Talent Defections at Sun: Advantage IBM

 

This sort of activity is common in mergers and acquisitions. I wish I could say that I had experienced this only once, but the sad truth is I have been on the inside and watched this happen several times. And it always is the same. Something big happens, (e.g. a merger, an acquisition, a new “C”-Level Executive) and people leave. In my last corporate counsel position a new CEO was hired just two months after I had come onboard. The General Counsel who had hired me, an intelligent attorney with a superb management style, abruptly announced his untimely retirement just three months later. His replacement lasted a short 12 months. Within a year and a half the new CEO’s friend and confidant had assumed the General Counsel position and the department I had been a part of was completely eliminated.

So is it any surprise that Sun is experiencing a bit of a brain-drain after the acquisition by Oracle? Andy Patrizio reports for InternetNews in his article Defections Batter Sun Microsystems that some key Java-based developers are reading the writing on the wall and have decided to avoid the tap on the shoulder and request to come to some non-descript conference room. Patrizio reports that so far Java’s creator, James Gosling, has not jumped ship. Josh Farina, analyst with Technology Business Research, states:

"It'd be in their best interests to make offers to get people to stay on board … Oracle is really good at making companies run better, but ultimately it needs the talent to stay because … it's in the line employees who make it happen.”

And the affect is not solely on the software side of the business. To get a preview into this slippage in Sun’s sales see the posts in this Blog Oracle’s Purchase of Sun: A Game Changer and IBM and SAP vs. Oracle and Sun: Let the Speculation Begin. Scott Handy, vice president of marketing, strategy and sales support for IBM Power Systems, reports that customers are calling IBM requesting migration assistance. Sun’s customer base looked at Oracle’s track record and see price increases in the future. Handy states,

“They are all quite concerned. When Oracle bought Siebel and PeopleSoft, they increased the maintenance licenses by 25 percent per year. With BEA, licenses went up 45 percent. So they are looking at OPEX going up just to keep what they had".

IBM is geared up and ready for these migrations. In 2003 IBM acquired a company called Sector 7, a company specializing in migrations. IBM created a program entitled Migration Factory and to date have performed over 1800 migrations. Before the Sun acquisition the ratio was about 40% of the migrations were from Sun but now that percentage is starting to increase. For the first six months of this year IBM has migrated over 170 Sun customers and another 66 Sun storage customers. 

It appears that IBM is doing what it has always done and that is using their hardware to get business in the door and then turn that into sales for long-term services and software.

 

SaaS Contracting: Tips Leading to the Decision and What to Include in the Agreement

 

There are many items to consider before deciding to adopt a SaaS approach to your IT operation.  Marcia Gulesian, a software developer, project manager, CTO, CIO, and author of numerous feature articles on IT, has captured the salient points in her article SaaS: Financial, Legal & Negotiation Issues.  As the title to her article suggests, the financial implications should be addressed first.  Gulesian has a very descriptive section on the differences between buying the software application and leasing it.  She discusses the differences of owning an asset and its tax advantages of the deductibility of depreciation as opposed to the leasing option.  There is a brief explanation of cash flows between the two alternatives, finding your opportunity cost, and making your determination on the comparison of the present values of the cash flows from the cost of owning versus the cash flows from the cost of leasing.  Before we go too far afield, my readers can attest to the fact that I always try to define our terms before delving into the nuances that the subject line suggests.

Wikipedia’s definition of SaaS is very complete yet succinct:

“Short for Software as a Service, SaaS is a software delivery method that provides access to software and its functions remotely as a Web-based service. SaaS allows organizations to access business functionality at a cost typically less than paying for licensed applications since SaaS pricing is based on a monthly fee. Also, because the software is hosted remotely, users don't need to invest in additional hardware. SaaS removes the need for organizations to handle the installation, set-up and often daily upkeep and maintenance. Software as a Service may also be referred to as simply hosted applications.”

I also have a posting in this blog, which I must admit has become quite popular based on the number of hits registered to it, entitled SaaS is the Future.  In it I discuss how a Managed Service Provider (“MSP”) can help software developers get their product to the market faster since the infrastructure barriers and capital expenditures are significantly lessened.  In another posting about Unified Communications I have quoted Mat Taylor, a senior software architect with British Telecom, regarding the benefits of SaaS:

"The ability to get things done faster, get workers more engaged in a business scenario, provide better customer service, are all big productivity wins that benefit the bottom line"

In light of the above discussion surrounding “lower total cost of ownership and quicker time-to-value”, Gulesian cautions us that the other factors to include in the financial calculation is the maintenance and support fees that come with ownership as compared to the SaaS fees which includes these items.

SO WHAT DO I INCLUDE IN THE SAAS CONTRACT?

Gulesian points out three areas that must be addressed in the contract:

·         Integration with your non-SaaS systems

·         Loss of control of data

·         Dependence on the provider for security

The CIO and his or her team are the main players to address the integration issue.  Although the next two points also require the IT organization’s participation and input, these are matters that must be addressed upfront in the agreement itself.

Risk of loss of your data is paramount.  In the event that the SaaS provider is unable to provide the support anticipated, it is essential that you have access to the applications as well as your proprietary data.  Inability of the provider to provide support may happen for a myriad of reasons such as bankruptcy of the provider or a real or threatened patent infringement claim and subsequent injunction.  The preferred approach to protect against such loss is to insist that the provider place its code into an ESCROW account.  Language can be drafted which will instruct the trustee  of the escrow ( an independent and trusted third party) to release the code to the beneficiary (i.e. you) upon the happening of certain events which are defined in the escrow language in your SaaS agreement.  One shortcoming to this occurrence is the downtime that may be involved in getting your systems up and running, but this is a necessary protection that you must include in your contract.

Transition assistance is another item to consider.  In the future you may wish to change the SaaS application currently in use.  Language should be included to require the provider’s assistance in developing the data migration strategies and the procedures to be followed so you can move your data to another application.

Since the SaaS model is economical by nature (see Wikipedia definition above), traditional discounting expectations are not available.  Pricing is based on users or seats.  The more users subscribed, the more likely the cost per user can be discounted.  So plan accordingly and try to build in volume discounting per blocks of users.

Other items Gulesian notes for inclusion in the agreement are:

·         Service Level Agreements (SLAs) regarding

§  Availability

§  Response times

§  Notifications of outages

·         Regulatory compliance

·         Data integrity

·         Data Privacy

·         Frequency of backups

·         Disaster Recovery

Gulesian’s article hits the main points and I highly recommend it to my readers.