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, Salesforce.com, 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 Dice.com and Monster.com:

Rank	Skill	Total Jobs	Previous rank
1	Java	6316	3
2	SAP	4357	13
3	Oracle	3561	2
4	SQL	2461	1
5	C#	1778	10
6	C++	1319	12
7	Unix	1189	5
8	Linux	1092	6
9	Peoplesoft	955	-
10	Windows	947	4
11	SQL Server	817	8
12	PHP	657	19
13	Embedded	489	-
14	Siebel	405	-
15	PL/SQL	367	17
16	JavaScript	337	-
17	Mainframe	306	-
18	Perl	265	14
19	Salesforce.com	253	-
20	Ruby	240	-

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: Salesforce.com 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!

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.

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.