Friday, November 19, 2010

Oracle Applications customers reveal their future plans

I'm a huge fan of primary research, especially when it is paired up with great analysis. Some Enterprise Software and Solutions (#EnSW on twitter) analysts base too much of their commentary and advice on what they read in the news, see at user conferences, and hear from other analysts.

Computer Economics is an #EnSW analysis firm with a difference. Frank Scavo and the folks at Computer Economics do great research - quantitative and qualitative - on the #EnSW world. If you are an IT executive, or an #EnSW vendor, you owe it to yourself and your enterprise to check out their research.

The latest published research from Computer Economics is a study called "Go-Forward Strategies for Oracle Application Customers." In the spirit of full disclosure, I should mention the following, and you should bear these facts in mind as you consider my comments:
  • I have been in the #EnSW world for around 25 years now, including long stints in executive product roles at Oracle and SAP.
  • My company, C3, may someday be competing with Oracle (and other #EnSW vendors).
  • Computer Economics provided me with a copy of this $995 report at no cost for my review.
Here are some key findings from the report, followed by some of my thoughts about the results:
  • Finding: Dissatisfaction with the cost and benefits of support runs high across the Oracle Applications customer base, with 42% of respondents reporting dissatisfaction with the quality of Oracle support, and 58% reporting dissatisfaction with the cost of Oracle support.
  • My thoughts: That is a very surprising result, showing an astonishingly high level of dissatisfaction!
  • Finding: Customers generally expect Oracle to grow as a share of their IT spending, despite their level of satisfaction.
  • My thoughts: There are a number of obvious reasons for this result, including vendor consolidation, customer expectations of growth in their business coming out of this continued weak economy, and the difficulty of moving from one application product set to another.
  • Finding: Third party maintenance and support is attractive to a substantial fraction of Oracle Applications customers.
  • My thoughts: A far smaller percentage of Oracle Applications customers are considering third party maintenance and support as compared to the fraction who are dissatisfied with support quality and price. It is not clear to me that any third party can really deliver bug fixes, patches, and legislative and regulatory updates. Nonetheless, #EnSW vendors are increasingly dependent on maintenance and support revenue, and thus they are increasingly vulnerable to customers using third parties, or going off maintenance and support entirely.
  • Finding: Despite - of perhaps because of - their dissatisfaction with the current applications support, Oracle Applications customers are not planning a rapid migration to Oracle Fusion Applications, with 5% planning to migrate away from Oracle, 24% researching or planning to migrate to Fusion, and the remainder with no plans to migrate to Fusion. e-Business Suite has the largest percentage of customers considering Fusion Applications, and JD Edwards has the largest percentage of customers considering moving away from Oracle.
  • My thoughts: Oracle is just beginning to roll out information about Fusion Applications, with the first big "reveal" coming at this year's Oracle Open World. Many Oracle Applications customers have only a limited understanding of the benefits and features, and limitations, of Fusion Applications. Over time, you can expect this result to change dramatically.
  • Finding: The report includes information about the staff required to run various Oracle Applications products, including e-Business Suite, JD Edwards, Peoplesoft, and Siebel. JD Edwards requires the smallest number of support staff, with e-Bueinss Suite and Peoplesoft at the other end of the spectrum to operate.
  • My thoughts: There is significant value in this section, and in the report recommendations, for Oracle Applications customers.
Computer Research has done the industry another mitzvah in sponsoring and executing this research and analysis project. Oracle Applications customers, and #EnSW vendors, would benefit from reading this insightful report.


Sunday, September 26, 2010

Technical Debt: Your Vendor Owes You

Gartner recently set off a new industry debate when it released its piece Measure and Manage Your IT Debt.

Vinnie Mirchandani (@dealarchitect) has a typically pointed, incisive, insightful response, called Gartner's "IT Debt" Scare (I guess you can tell from the title where this piece is going ;-) ).

Both Gartner and Vinnie make excellent points, but I have a somewhat different point of view.

First, Gartner was very creative to once again bring a new perspective to an emerging problem. However, there can be more than one perspective on this issue, as Vinnie's piece points out.

What is Technical Debt?

Technical debt is a term apparently
coined by Ward Cunningham in 1992 to describe the shortcuts, compromises, and mistakes made in developing software. For example, many times a software project is on a deadline, and a "good" approach would take too much time or cost too much in resources, so project members take note of the problem and use a quick hack to just get by for now. The quick hack introduces costs later in the project that build up over time if the "technical debt" is not paid off. For some great overviews of technical debt, see here and here, plus the infographic here.

Technical debt is commonly used to describe architectural shortcuts made in software product development in start-ups, but can be applied as a concept (as Gartner has done) to many other related areas - for example, IT lapsed maintenance, deferred maintenance on a home or public utilities, or failure to invest in areas that give a long-term payoff.

Technical debt - TO or BY the software vendors?

Some technical debt has little or nothing to do with enterprise software vendors; it's the same kind of technical debt accrued by large and small software vendors where shortcuts are taken during IT projects.

However, as Gartner positioned this problem (according to other reporters such as Vinnie and Larry Dignan, as I have not read Gartner's article on this topic), at least part of this debt is a debt to enterprise software vendors - forgone upgrades, or even going off maintenance. The theory is that firms will skip an upgrade from time to time (or, worse, a patch), or go off maintenance on enterprise software, creating some amount of technical debt; after all, upgrades get progressively harder to apply as more upgrades are skipped over, and going off maintenance can lead to missed security patches as well as costly "relicensing" fees in the future. One way to look at this technical debt is that it is a technical debt owed to enterprise software vendors.

However, another way to look at this is as technical debt owed BY enterprise software vendors to their customers. After all, if these updates, upgrades, and patches had enough value in them, and cost little enough to apply, then the ROI (benefit/cost ratio) would be sufficient to justify keeping up with the vendor's software releases. The gap between the ROI needed and the actual ROI for each release is a form of technical debt - but its a debt owed by software vendors to their customers.

There are two ways vendors can increase the ROI of these releases - by increasing the numerator (return or benefit) or decreasing the denominator (investment or cost). Simple, right? Increasing the benefit can be accomplished by planning periodic usability or functional updates that can go along with emergency fixes when needed, or by reducing the frequency of patch releases. The cost can be reduced by reducing the frequency of patch releases, creating tools that determine whether a particular release is needed by the customer, by handling the updates on the customer's behalf, by avoiding schema changes, and thoroughly testing every upgrade.

SaaS versus on-premise

Any enterprise software discussion these days has to include a discussion of SaaS (or cloud) versus on-premise deployments. What does the cloud have to with this topic? SaaS-delivered applications change the economics of software in many ways, and technology debt is yet another case of this. SaaS-based applications may not automatically result in greater benefits related to new releases, but they do offer the opportunity to reduce the costs of upgrades - because most of the infrastructure upgrade costs are borne by the
vendor, so SaaS vendors have developed techniques and a body of knowledge that minimizes those costs.

Often, this is not the case with on-premise software. Customers have a very diverse landscape of systems, integration points, operating system versions, and set of applied patches; as a result, it just isn't possible for vendors to sufficiently test upgrades for all these permutations. Of course, customers are also responsible for the costs and efforts of each upgrade, not benefiting from the economies of scale when many customers are on identical environments simultaneously upgraded - as in a SaaS deployment.

On-premise software vendors generally do not optimize for low cost of upgrades, at least not to the same extent as SaaS vendors. By definition, on-premise software vendors cannot test every customer's upgrade with every release; in the SaaS world, such testing is standard operating procedure. These days, SaaS vendors even give customers some time to test upgrades before switching over to a new release, allowing customers time to test any custom extensions or integration points, as well as to test new features and develop new work processes to benefit from the new functionality of each release.

Many times, software upgrades go along with infrastructure upgrades - the new version may not be available for a particular brand of previously-supported hardware, a previously-supported operating system, or perhaps an outdated database. When this is the case with on-premise software, the customer has to bear the cost of upgrading to new infrastructure, testing other related systems on the new infrastructure, and training employees who manage the infrastructure and the new software. These costs are, again, not borne by the customer in a SaaS environment; the SaaS vendor takes on this burden. Incidentally, this burden is lower for the vendor in the SaaS world, since only one (or two, when multiple versions of applications are supported simultaneously for customers) configuration needs to be supported and tested, and because the SaaS vendor controls the upgrade cycle to minimize costs and disruption.

Do SaaS applications completely eliminate technical debt?

No. But SaaS applications significantly reduce technical debt, primarily by eliminating a backlog of unapplied patches and upgrades, eliminating costly infrastructure upgrades, and eliminating the "death matrix" of supported platforms and infrastructure.

(c) Oracle Corp.

Maybe I'll cover virtualization in a future blog, as virtualization holds some promise as a way for on-premise software vendors to come to grips with some of these problems and alter the economics of upgrades once again. Feel free to share your thoughts in the comments section below.


Saturday, September 25, 2010

Bill McDermott and Tom Bergeron: Separated at Birth?

This struck me last night while watching re-runs of "America's Funniest Home Videos" - the host, Tom Bergeron, looks an awful lot like SAP's co-CEO Bill McDermott.

McDermott and Bergeron: separated at birth? You be the judge ... ;-)

Thursday, September 9, 2010

Who will Oracle acquire next? (The answers)

After about a week of voting, readers of this blog have identified the companies they believe Oracle will acquire next. I'll leave the survey open for a while longer, but about 250 people have voted and the results are pretty clear.


Overwhelmingly, respondents to this survey believe that Informatica is the company Oracle is most likely to acquire soon. Informatica describes itself this way:
Informatica enables organizations to gain a competitive advantage in today’s global information economy by empowering them to access, integrate and trust all their information assets.
That is to say, Informatica helps companies consolidate and make sense of their data. Informatica is well-known for its Extraction, Transformation, and Loading (ETL) tools, but they've expanded their product portfolio and grown their business over the past several years under the remarkable leadership of Oracle alum Sohaib Abbasi. Plenty of Informatica's senior executives and employees have worked at Oracle in the past, and the company's headquarters are even located very close to Oracle in Redwood City.

An acquisition of Informatica could fill a very important hole in Oracle's product line, enabling Oracle to consolidate its position in data warehousing and analytics, one of the hottest growth areas in the database market today. Of course, such a deal would have to pass regulatory approval, and there could certainly be antitrust concerns, but I suspect this deal would get some scrutiny before a quick approval., the leading independent CRM company and a leading Cloud platform, is our respondents' second choice for a company Oracle is likely to acquire soon. is also led by an Oracle alum with a great track record: the inimitable and charismatic Marc Benioff. Marc and his team have played a key role in promoting a major architectural shift, and business model shift, in the IT industry, from "on prem" to SaaS and Cloud. Marc, and many of his team are also Oracle alums, which could help with the integration in a merger with Oracle.

Unfortunately, I think this acquisition is not likely to occur. is currently valued at about $15 billion, and an acquisition would likely drive this price up to at least $18 billion. It's hard to see how Oracle could make the financials of this deal work. This deal would also likely generate more regulatory scrutiny than an deal for Informatica, but I think this would also get approved under the same theory that led to approval of the acquisitions of Siebel and Peoplesoft.

The Top 10

Of the companies our survey respondents think Oracle will acquire next, most are platform technology companies:

Company Responses
Informatica 66 36
VMware 30
Red Hat 26
Teradata 26
NetSuite 25
SuccessFactors 19
Taleo 19
Computer Associates 17, NetSuite, SuccessFactors, and Taleo are the applications companies that made the "Top 10" list. What do they have in common? Each is a SaaS application. is a SaaS CRM company (with a growing Cloud platform (PaaS) business); NetSuite is a SaaS ERP suite (with a growing PaaS business); SuccessFactors and Taleo are SaaS human resources businesses. Acquiring any of these companies is likely to help accelerate Oracle's entry into the SaaS business.

The Write-Ins

In addition to the votes for companies named in the survey, respondents were given the option to write in a choice of their own. 18 responses were written in, a fairly high rate (almost 10% of respondents wrote in another choice).

5 of the write-in "ballots" were for Cloudera, the Hadoop company. Hadoop is a leading technology in the area of "Big Data," a topic that has to be on Oracle's mind as it considers opportunities and threats in the future.

There were a couple of write-in votes each for Vertica and Jive Software. Vertica is the latest start-up from database legend Michael Stonebraker, creator of Ingres, Postgres, and other technically interesting database companies. Vertica's main product is its columnar database, a technology that could be interesting for certain data management problems (like data warehousing). Jive Software is social software for the enterprise, which could help Oracle build next-generation applications.

Best Answer

The best write-in answer was provided by an anonymous survey respondent whose answer to "Who will Oracle acquire next?" was both funny and prescient. The response, given the day before the official announcement: Mark Hurd.

Oracle Alums

I ran the same survey among a group of relative insiders, the OracAlumni Network. This is a group of 500o+ former Oracle employees, many of whom remain in close contact with Oracle and its market, and who believe that Oracle will acquire next:

Red Hat

Very similar list, particularly at the top end.


If our survey respondents are any indication, Oracle will continue acquiring companies, and Informatica should be at the top of its shopping list. If you'd like to chime in with your thoughts, visit our continuing survey at


Friday, September 3, 2010

Who will Oracle acquire next?

Oracle has been very acquisitive in past years. In a recent analysis of Oracle's acquisitions, Stephen Jannise of prepared this excellent infographic of Oracle's acquisitions timeline, categories, and size:

I would have put Industry Solutions at the left, to show a real spectrum from industry to application to middleware to database to hardware, but this graphic reveals real insight into Oracle's strategy and focus on acquisitions over the past 5 years.
The article also points out some interesting analysis of what characterizes a good deal for Oracle. According to Stephen:

At the highest level, the motivations behind Oracle’s largest acquisitions appear to be the following:

  • Grow market share leadership in key enterprise markets;
  • Expand profitability by consolidating high-margin support revenue; and,
  • Increase strategic relevance by offering a complete technology stack.

This last bullet is something that has played a larger role in really only two of Oracle's acquisitions, both recent, but does two points define a trend? It certainly makes sense and is consistent with speaking points from the company's senior executives.

So, who do you think Oracle will acquire next? Vote in this poll to share your opinion.

After the poll closes, I'll post an analysis of the results here.


Wednesday, August 11, 2010

What can we learn from software development job posts? (Java, SAP, Oracle, SQL, and C#/C++ will get you a job!)

Several months ago, I posted some analysis of IT-related jobs listed on Dice and Monster. At the time, the hot job skills were SQL, Java, and XML. Things haven't changed much since April - although some specific skills have moved down or up on the list.

In summary, here are some conclusions we can draw from this data:
  • In almost all job skills, there are more jobs posted now than there were in April or last year in June.
  • The most popular skills are Java, SAP, Oracle, SQL, and C#/C++.
  • Job posts mentioning specific programming languages and popular applications have experienced the largest increase in jobs posted over this period.
  • The biggest jumps (by percentage, sometimes from a small base) were in job posts mentioning Android, Google, Facebook, iPhone,, and AJAX.
  • The biggest drops (by percentage) were in job posts mentioning Fortran, PowerBuilder, and Informix.

Here are the top 20 skills listed in job titles on and

Skill Total JobsPrevious
1Java 63163
2SAP 435713
3Oracle 35612
4SQL 24611
5C# 177810
6C++ 131912
8Linux 10926
9Peoplesoft 955-
10Windows 9474
11SQL Server 8178
12PHP 65719
14Siebel 405-
18Perl 26514 253-
The methodology in the analysis continues to evolve, so the results aren't perfectly comparable.

Some additional findings:
  • Language skills showed the largest increase in demand as a category, up 78%. Applicatoins grew 45%, platforms grew 36%, and databases grew 33%.
  • Database: Given the large base, there was a surprisingly large jump in posts for Oracle jobs (up 34%). SQL Server and MySQL also had large jumps, but from substantially lower bases. If you're going to invest in learning a database, at this point, Oracle is the clear leading choice.
  • Applications: had the largest jump by percentage (up 113%), but from a relatively small base (118). SAP (and related skills of ABAP and BASIS) had a large jump from a large base (up 50%). Siebel also had a big jump in mentions (up 36%).
  • Languages: There was a huge increase in job posts for Java skills (up 92% from a large base). Other languages that showed large increases from large bases include C# (up 47%), PHP (up 57%), and C++ (up 28%).
  • Platforms: Only in the platforms category was there a lot of change other than just growth. Unix was still the largest platform skill by mention, but Linux passed Windows with 34% growth. There was substantial growth in mentions for Google, Android, iPhone, and AJAX. There was healthy growth for most platforms, with the notable exception of Blackberry-related jobs.
  • Skills that are not in high demand or growing: Informix, Sybase, PowerBuilder, Fortran, Blackberry, Palm WebOS, Yahoo, Widgets/Gadgets.
  • Skills that are surprisingly low in demand: HTML5, Azure, Facebook.
  • Overall, there was an increase of 50% in job posts on these two sites.
If you have any skills you'd like to see tracked in these posts, please post a comment and I'll see about including them next time. Thanks!

Wednesday, May 19, 2010

Why is in-memory database important to #SAP ?

Very busy these days, but wanted to share some thoughts about in-memory database and why it is so important to SAP - and the industry. All of this is just my opinion, and based only on my experience.

SAP is really a collection of business processes implemented in software. No shock there. In some cases, these processes are implemented in code. Yech. In other cases, these processes are implemented as simple or complex finite state machines dynamically driven by data or metadata; unfortunately, these state machines are written on different programming models, using sometimes very different (domain-specific) languages and technologies. Generally speaking, these state machines are integrated (or can be integrated through customization) in various ways that can be very interesting to enterprises, allowing for processes like "build to order" to function properly (which integrates "order" with "collection" with "dunning" with "schedule" with "manufacture" with "ship" with ...).

Because these processes are so diverse, and have been implemented literally over a thirty year stretch in time, there is not a lot of consistency in their underlying technologies and programming models. With all this inconsistency, it is not straightforward to produce and consume events, which makes these processes hard to configure, integrate, and extend.

Event-based systems are not foreign to SAP, but (modern) event-based technology (at least within the applications) is. Anyone who has used ARIS to do the design of business processes for SAP implementations has probably used "event-driven process chains" (EPCs) to describe processes; implementing the event connections, however, has often/mostly been a process of writing custom code. There is no publish/subscribe bus for (most important) SAP events, thus there are no (substantial) event publishers or subscribers in the SAP application suite.

If SAP were to undertake a rewrite of its applications, it would have the opportunity to implement events in a consistent way in the applications. I am not certain if this has been done with Business ByDesign ("ByD"), which was a project which undertook to rewrite some of SAP's applications, but very few mySAP Business Suite customers will be replacing their mySAP suites with ByD any time soon.

If, on the other hand, SAP were to undertake a rewrite of its application server tier to replace all calls to a database with calls to "HassoDB" (the in-memory database that got so much attention at SAPPHIRE this week), SAP would have the ability to simultaneously event-enable its product essentially with little to no additional effort. If HassoDB understands that an object is being stored, updated, or accessed, HassoDB could publish an event - and that event could be consumed by new applications that speed up integration between business processes, allow the insertion of new business processes, or that simply generate alerts for users.

SAP even has a design for such a capability: SAP Live Enterprise from SAP's Imagineering team.

How could this capability be deployed?
Well, imagine that a sales person gets an alert every time their customer makes a payment, is late with a payment, submits a complaint or service request, or places an order on-line. Or that a salesperson sets up an "auto-responder" for those events, thanking the customer or asking her for feedback as appropriate. Event-based capabilities would greatly speed up and improve service.

Another example could be in integrating business processes. Rather than hard-coding the "on-boarding" process for a new employee, there could be an event-driven integration. The hiring process could generate an event when an employee's starting date is set; other processes could subscribe to that event, and do the appropriate processing, including reserving an office, preparing the HR orientation, ordering a company credit card, requesting an entry badge, or assigning and configuring a computer. Whenever the on-boarding process changes, rather than editing the process definition, taking the application down in the process, and restarting it, instead an administrator would just load a new action and subscribe it to the appropriate event.

Finally, how will customers license the in-memory database? Will they have to buy it or will it be included in maintenance? If it is the latter, and if the in-memory database can be made compatible with older versions of SAP, then this would be substantial justification for the maintenance fees SAP has charged customers over the years. Even if customers have to separately license and pay for this capability, if it is made compatible with all versions of mySAP under maintenance, that would be a huge benefit for customers. I'm looking forward to SAP bringing "HassoDB" to market. With the help of the database gurus at Sybase, I think it is possible that in-memory will finally come to "Big Data" enterprise problems.

Tuesday, May 11, 2010

Top 10 Reasons Why Steve Jobs and Apple Reject Adobe Flash

In the spirit of Top Ten lists, here's Steve Jobs' "Top Ten Reasons for Rejecting Adobe Flash" (for the irony-impaired, please note that this post is not based on the truth):

#10: Adobe Flash is too proprietary to run on any of Apple's beautifully open systems (except for all Macs).

#9: Adobe Flash is too much of a power hog to run on any of Apple's battery powered devices (except for all Mac laptops).

#8: Very few applications are affected by Apple's rejection of Adobe Flash (except for just about all social games, just about all enterprise software packages with modern interfaces, and just about all financial services and health and education web site applications).

#7: Very few web sites are authored using Adobe Flash, as compared to HTML5 (except for 85 of the top 100 web sites in the world).

#6: Very few iPhone, iPod, and iPad users would like Apple to support Adobe Flash (except for an overwhelming majority, including my son).

#5: The Apple community has, over the years, benefited very little from Adobe's support (except for just about every graphic designer in the world, who generally use Adobe products on Macs).

#4: HTML5 will someday (in several years) be able to do just about everything Adobe Flash does today.

#3: Someone managed to hack up a very old game to be able to run in HTML5 (in a lab experiment).

#2: Adobe has not backdated any stock options to any Apple executives.

#1: Apple does not need to provide reasons for its decisions about what software they will allow you to run on a device you own.

The BI recession?

Bob Evans described a customer claim that we are in "The SAP Recession" (quoting from an article from Reuters). According to his opinion piece:
Timken Co. CEO Jim Griffith said, "I call this the SAP recession" (and Timken's an SAP customer!). But despite how it bad that sounds, Griffith intended it as a compliment. (I think).


"I call this the SAP recession," Griffith is quoted as saying, "because companies have a much better control over their inventories and so our customers did a much better job of reducing inventories immediately when they saw the demand go. And the further back you were on the supply chain, the more that hit you."

There is a lot to be said for this point of view. I was at a major consumer products manufacturer in an earlier decade, when tough times hit our business. The tough times hit the company hard, because we did not have the systems (or standard agreements!) in place to cut hard and quickly - on discretionary spending, capital outlays, supplier contracts, or employee hours. As a result, our suppliers and employees were buffered from the effects of the downturn. They could see the hits to our earnings and thus predict the arrival of the "rainy days" ahead - they were able to adjust their spending and expectations, softening the blow of our customers' hard times throughout our supply chain. Given that we were not lagging other large companies at the time in our IT systems, it is likely that similar scenarios played out across the economy, leading to a much softer, slower, and economically more efficient deflation of the economy.

Jim Griffith has a good point, although I think he is misplacing the beginning point of this new era. Due to Y2K concerns (and good marketing on the part of SAP, other ERP vendors, and their systems integration partners), many companies implemented integrated enterprise systems for employee management, budget control, financial controlling and reporting, purchase order management, supplier contracts, and other enterprise spending vehicles in the period leading up to January 1, 2000.

Shortly thereafter, the global economy (and the US economy in particular) faced a significant downturn. For the first time in a recession, companies had the tools to clamp down hard on spending - tools including ERP systems (including purchasing, travel, budgeting), reporting and BI systems (for visibility and transparency), collaboration tools (such as e-mail and workflow approval), and business processes (for adjusting budgets, approving capex and opex spending, stopping all hiring and travel, and much more). Companies used these tools, and it seemed to me that the result was a much steeper decline into recession than ever before. I remember months that went by after 9/11 when there were zero jobs posted on job bulletin boards, no consulting contracts issued, and no employee travel approved.

2001 was the first cyclical downturn where most large companies had pretty good expense control capabilities, pretty good ability to adjust budgets on the fly, and pretty good ability to manage supplier contracts via ERP. In previous downturns, expense control was haphazard, but with SAP you could shut off employee travel (for example) in an instant. As a result, the downturn was more abrupt - the economic equivalent of program trading, but without a regulator that could turn off the program.

Every recession (and upturn!) after Y2K can be thought of as being accelerated by ERP systems like SAP. What has changed since 2001 is a pervasive use of business intelligence (BI) tools in most leading companies. Now, companies can not only shut off transactions, but they can analyze business performance such that they can identify (and efficiently/brutally execute) strategic business opportunities including facility consolidations and shutdowns, offshoring and outsourcing efficiencies, supplier consolidation, and even exits and shutdowns of poorly performing business units.

Perhaps this recession, rather than being called "The SAP Recession," should be called "The BI Recession" ...

Monday, April 5, 2010

What can we learn from software development job posts? (SQL, Java, and XML will get you a job!)

About a year ago, I posted some analysis of what we can learn from job posts. Since then, the job outlook for at least the American economy has substantially declined, but there are still opportunities available if you have - or can develop - the skills in demand. A year ago, according to job posts on, the hot job skills were Java, SAP, and Oracle. How about today?

Well, with a slight change to methodology, things look pretty much the same, but the changes are interesting. Last year, I only looked at terms that appeared in job post titles; this time around, I searched on terms that occurred anywhere in the job post. I can't say I used a totally comprehensive set of terms, or that the queries don't produce some false positives and negatives, but without further disclaimers, here are my findings.

The top 20 IT skills in demand on
  1. SQL
  2. Oracle
  3. Java
  4. Windows
  5. Unix
  6. Linux
  7. XML
  8. SQL Server
  9. HTML
  10. C#
  11. Dynamics
  12. C++
  13. SAP
  14. Perl
  15. IBM
  16. AJAX
  17. PL/SQL
  18. BASIS
  19. PHP
  20. MySQL
(For the rest of the list in the analysis, see the end of this post.)

A little surprising that Dynamics came in above SAP on this list, and perhaps there were some "false positives" putting BASIS above PHP, but probably nothing really shocking there. There was strong demand for many skills, but very little demand (relatively) for iPad (just 13 jobs!), HTML5 (34 jobs), Fortran, Azure, and eBay -- all under 100 job posts mentioning these skills.

Overall, your best bet is to learn Oracle, SQL Server, Java, and XML on your choice of platforms, and
you've got job security 'til the end of time (or at least for the next few quarters).

Some additional findings:
  • SQL is a great skill to have. Oracle and SQL Server are the best databases to learn in terms of job openings [NOTE: no analysis was done on salaries, so your mileage may vary if you care about earning potential. There was one job on Dice for a TPF programmer, and I bet that pays pretty well!]. DB2 and Sybase also had strong demand.
  • Java, C#, and C++ are all continuing in strong demand. Perl, PHP, Ruby, and Python also have strong demand. There is some, but significantly less, demand for Flash, COBOL, and ABAP development skill.
  • XML skills are greatly in demand. There is significant demand for AJAX skills as well.
  • Dynamics came in very strong on the Applications front, with SAP also very strong. There is some continued demand for Peoplesoft and Siebel skills. is significantly less, but there is still substantial demand for skills.
  • There is not a lot of demand for Mac, iPhone, or iPad developers, with none of those platforms cracking the 500 job posts mark. Blackberry was the only mobile phone platform above that mark, with some significant demand. Android is in slightly less demand than iPhone, but growing much faster.
  • Amazon and Azure, two leading cloud platforms, had very little demand for candidates.
Overall results:

Skill Sought
# of Posts Mentioning
Oracle 12533
Java 12104
Windows 9877
Unix 8872
Linux 7703
XML 7600
SQL Server 7196
HTML 6198
C# 5773
Dynamics 5066
C++ 4937
SAP 4713
Perl 3943
IBM 3306
AJAX 3244
PL/SQL 2656
BASIS 2306
PHP 2085
MySQL 2061
DB2 1996
VMWare 1776
Python 1629
Peoplesoft 1603
Embedded 1466
Sybase 1379
Mainframe 1342
Siebel 1153
Google 837
Ruby 786
Flash 604
Blackberry 580
COBOL 537 521
ABAP 479
iPhone 387
Mac 372
Android 316
Twitter 283
Facebook 248
Amazon 236
Assembler 191
Widget 174
Yahoo 165
Informix 153
Palm 133
PowerBuilder 111
eBay 62
Azure 53
HTML5 34
iPad 13

Saturday, March 20, 2010

Palm must build great accessories to survive

Palm is in a tough situation. As reported widely, Palm's operating results are beginning to cast doubt about the viability of the company. There is no easy solution for the company, but a series of tough measures and creative development efforts can turn things around.

Palm makes a number of smart phones, notably the Palm Pre Plus and the Palm Pixie Plus [Disclaimer: I am a very happy owner of a Motorola Droid, but have owned Palm devices since the original Palm Pilot]. The Palm phones incorporated a large number of innovations, from wireless charging to sleek styling, but the market for smart phones is very competitive these days. Palm made a number of missteps in entering the market, from bad timing to baffling advertisements. Now, Palm finds itself in a crisis that may leave it unable to survive: the channel is full of aging stock, losses are mounting, and the economy shows no signs of rescuing the company.

How Can Palm Survive?

How can Palm survive, with all these issues in front of it? And why do I think I have any answers for them? I've been following Palm since the US Robotics days of the Palm Pilot, and owned many Palm devices, from the awful Treo 300 to the wonderful Tungsten TX. I was also CEO of OQO, the mobile gadget company that made sleek, stylish, powerful handheld computers. We faced, and failed to overcome, some of the same issues Palm now faces and must overcome if it is to survive. Other companies, such as Apple Computer, have faced similar problems, and gone on to greatness, and so can Palm.


First off, Palm has to survive, and that means it has to have enough cash to continue operations. The company must cut expenses ruthlessly. The company must also ensure that it has access to capital if necessary, even if it dilutes the current owners. Also, the company should aggressively focus on identifying and eliminating every source of warranty repair claims - this will help it improve current operating margins, as well as help it build a reputation for quality, and create some IP arou
nd design for quality that will help it with future products.

Second, Palm has to find a way through its problems - chief among them is getting through the inventory on hand, finding a growth segment (or a collection of growth segments) it can better serve than other smartphone options, and creating a product pipeline that will not suffer the same problems as the current lineup.


There is very little difference from one leading edge smartphone to the next - touch screens, video, camera, applications. iPhone phanboyz will tell you that there are more apps for the iPhone, but realistically any good app is available for all platforms (except the Google apps, which are pretty much only available on the Droid now). Smartphones are not really distinguished by functionality or cost any longer. Now, they are pretty much distinguished by the markets they target. iPhones are for those who view themselves as hip, urban, and elite. Blackberry's are for wonks and businessmen (and heavy text messagers). Droids are for supergeeks. Who are Palms for?

All this is to say that phones are now accessories, like handbags or shoes. They say something about you. Palm needs to find a target market segment that is underserved with the current competitors, and do a great job of meeting their needs. Looking at its assets, we see a stylish phone with a few interesting accessories, with a built-in keyboard, and with a relatively powerful operating system. To whom could this phone appeal? We can speculate:

  • Corporate executives
  • Bloggers and other social media aficionados
  • IT workers
  • Customer-facing mobile workers
  • Students and mobile gamers who don't want to live with the restrictions
    Apple forces on them
Regardless of what we can speculate, Palm needs to do hard research, and then follow through with the programs that appeal to these users.

Also, as this is a relatively short-range problem Palm must solve, it must do so without large new product R&D investments and without a new line-up of smartphones. Palm's options are pretty much limited to adding new channels (e.g., new countries and carriers) and introducing new accessories.

Accessories are an option Palm should explore. First off, accessories can be sold directly or
through the channel, at very high margins compared to phones. Second, accessories can be brought to market more quickly than new phones, at very low R&D effort. Third, accessories can be exactly the customization Palm needs to appeal to chosen market segments - rugged cases, attached printers and scanners, executive cases, waterproof cases, customized cases showing the owner's twitter name, etc. Finally, if designed properly, accessories can be made to create a "system effect," if they are upwardly compatible with new Palm phones. This can encourage buyers to upgrade to new phones when available.


Palm needs to get serious about its future - reduce burn, reduce channel glut, create a defensible "core" market segment it can own and grow, and develop products that serve that core segment better than others in the future (accessories and new phones as well). Palm has always had a special kind of magic - Apple's cool with Google's geek chic. If Palm can make it through its current tough times, we can hope for a return to the kind of creativity and innovation that made it special in the good old days.

Wednesday, March 10, 2010

Oracle Promoting Microsoft Bing? Microsoft Paying Oracle and Subsidizing Java? Cats and Dogs Living Together???

Today, I got an alert from Java that an update was available, so I clicked "OK" to install. Imagine my surprise when I got the following prompt during the installation procedure:

Is Larry Ellison aware that Oracle (which now owns Sun and its Java products) is promoting Microsoft Bing? By the way, a colleague told me that he received a similar promotion for a Yahoo! toolbar rather than the Bing toolbar, so perhaps Oracle is not solely promoting Microsoft, and perhaps this deal was done before the acquisition. Still, it's odd that Oracle would promote a Microsoft product.

It's even odder that Microsoft is so anxious to promote Bing that it will even do so while subsidizing Java and paying Oracle, two that must be high on Microsoft's "Most Wanted" hit list - does Steve Ballmer know that Microsoft is paying money to Oracle, and (horror of horrors!) subsidizing Java???

Cats and dogs living together indeed ...

Sunday, February 14, 2010

Will SAP be acquired?

Lately, SAP has had management shake-up followed by management shake-up followed by management shake-up. SAP's challenges have led many to speculate whether SAP can remain independent. In that vein, Enterprise Irregulars ran a poll asking readers to state their opinions of whether SAP will be acquired, by whom, and when. The poll will remain open, but the results at this point are not changing quickly with new votes, so this is as good a time as any to assess the results.

With over 340 nearly 600 votes in, two thirds over 70% of all who voted expressed the opinion that SAP will be acquired.

Poll 1 (343 votes as of 14 Feb 2010) (594 votes as of 22 Feb 2010)
Who will acquire SAP?

No one, SAP will remain independent: 34% (116 votes) 29% (170 votes)
AT&T: 1% (4 votes) 1% (6 votes)
Cisco: 2% (6 votes) 2% (13 votes)
Google: 3% (9 votes) 2% (12 votes)
HP: 7% (24 votes) 7% (39 votes)
IBM: 29% (99 votes) 34% (200 votes)
Microsoft: 18% (61 votes) 18% (104 votes)
Oracle: 4% (12 votes) 6% (36 votes) 1% (3 votes) 1% (5 votes)
Other: 3% (9 votes) 2% (9 votes)
Poll 2 (275 votes as of 14 Feb 2010) (485 votes as of 22 Feb 2010)
When will SAP be acquired?

Not for the foreseeable future. SAP will remain independent: 41% (112 votes) 33% (159 votes)
Announcement in first half of 2010: 6% (17 votes) 6% (31 votes)
Announcement in second half of 2010: 20% (55 votes) 25% (119 votes)
1H2011: 10% (27 votes) 12% (59 votes)
2H2011: 8% (23 votes) 9% (42 votes)
2012: 10% (28 votes) 10% (49 votes)
2013: 1% (4 votes) 2% (12 votes)
2014 or later: 3% (9 votes) 3% (14 votes)
Analysis of poll results

Clearly, an overwhelming majority of respondents believes that SAP will be acquired (not everyone voted in the second poll). 225 of 341 (66%, or just a shade under 2/3, of) Over 70% of respondents indicated a belief that SAP will be acquired. IBM was the leading contender, with 29% 34% of respondents, followed by Microsoft with 18%, and HP with 7%. Of those expressing an opinion as to when SAP will be acquired, 10% believe it will be announced in the first half of 2010, 34% 37% go with the second half of this year, and 17% 31% believe it will be next year.

Can SAP be acquired?

Obviously, SAP can be acquired. It is for sale every day on multiple stock exchanges. The founders might have to be negotiated separately, but, yes, the company could be acquired - theoretically.

In practicality, there are a large number of issues that would make an acquisition of SAP very challenging.
  • The founders own a controlling share of the company. Their support would be essential for any acquirer. At the moment, the founders do not seem to have an interest in the company being acquired, but this can change. The founders might like to be the largest shareholders in IBM (for example) some day - or (to put it indelicately), their heirs might.
  • The remaining shareholders have to approve an acquisition with a large majority. This could happen only if they expected that the company's management would provide a significantly worse return on their equity than would an acquirer. This is not so hard to imagine, particularly if the latest management shake-up fails to produce a return better than the market as a whole, and if a suitor would propose an acquisition with a significant premium.
  • Projected customer retention would have to justify the purchase price. Given how hard it is to move off SAP, and given the current difficulties with third-party support models, this criterion seems to be easily satisfied, at the right price for the company.
  • European and national regulators (e.g., in the US, Russia, and China) would have to be satisfied that the acquisition of the company would not decrease competition in the market. This criterion would be satisfied if the acquirer were not a major applications supplier prior to the merger, and particularly if Oracle were surging or SAP were showing signs of an impending collapse. Passing this hurdle would be tricky, although AT&T, Cisco, Wipro, or others should be able to overcome this; Oracle and Microsoft would have significant challenges based on their applications portfolio (although they could divest), and IBM and HP might have smaller challenges based on their size and control of the enterprise market in various segments.
  • The most challenging issues could be with national labor laws, particularly in Germany. These labor laws restrict the types of changes that can be made by the company without approval from the workers, such as reductions in force, changes to compensation levels or structures, and changes in management and reporting structures. Any acquisition of SAP will require approval from the German workers, and this may be difficult to obtain, particularly if the founders give up their standing by offering to sell their shares to a foreign company.
Summary, and my €0.02

Given all these issues, an acquisition of SAP is very unlikely in the short term, and perhaps could not occur unless SAP faces an existential crisis. Many would argue that such a crisis is looming, as evidenced for example by the results of the poll above. Time will tell. Regardless, I would advise employees of SAP to focus on overcoming the company's short-term challenges, and exploiting the opportunities within its grasp.