SAP Disrupts Everything

I spent the last three days as what seemed like the only custom application development guy in a sea of SAP consultants for whom the world revolves around their favorite package. Since a client of mine is likely going to bite the bullet and go down the SAP path, I had begged my management for some “just in time” training in SAP. I had no illusions that with three days of training I could actually implement anything related to SAP. I just hoped to get to the point I could discuss topics intelligently with the SAP folk who will likely be showing up soon.

The more I listened (and occassionally dared to show my ignorance via an occasional question), the more disruptive SAP’s entrance into the SOA space seems to get. This is not to say that being “disruptive” is all bad. (See my post “A Culture of Innovation or Not” for some discussion about corporate culture and innovation as in “Wouldn’t it be fun to work at a disruptive company like Google?”)

Here are some examples of the kind of disruption in the software industry and SOA in particular that I’m talking about:

• There are numerous releases of SAP which are simultaneously supported by SAP at present. Many companies got up and running a while back and are faced with the prospect of trying to migrate to newer versions when they have customized SAP heavily. (Customization may need more custom work to get them running on the new version.) At the same time, SAP is raising the price of maintenance support of the old versions it doesn’t want to have to support anymore. In the very near future some of the oldest versions won’t have support at all except to pay SAP by the hour.
• Does a back-level SAP customer take the “safe” route and upgrade to a non-SOA-enabled version whose support runs out one or two years later? Or do they risk larger changes to their infrastructure and leapfrog into the latest and greatest version SOA-enabled versions.
• People with skills implementing the SAP using the “old style” BASIS and ABAP will likely have to learn that the latest and greatest versions are based on a J2EE application server. Similarly, the old SAP “modules” seem less and less relavant as SOA-enablement facilitates business processes that cross the old boundaries of modules with acronym names like SD, MM, PP, and FI. The list of digraphs is a lot longer than that.
• IBM is hiring SAP consultants by the way. A huge number of SAP accounts are on those back-level releases. Many want or need to upgrade. The SAP time-bomb is ticking.
  
• People like me who already have J2EE skills might like the idea of having our skills more readily transferable into the high-demand SAP space as SAP adopts the J2EE application server technology.
  
• People like me who already have J2EE skills need to remember that unlike ABAP, there are armies of J2EE-ready programmers in places like India who will also be embarking on an SAP journey soon. IBM announced a $200 million investment in exactly that kind of thing not too long ago. Granted, not all of that is directed at SAP projects but I believe IBM is SAP’s largest integration partner. Read between the lines.
• (only slightly off topic) IBM is still hiring J2EE types by the way ... and hiring them in the US. In fact, I got an email a week or so ago from my organization in the US outlining how many people we’ll have to telephone screen, how many we’ll have to invite for face-to-face interviews, how many offers we’ll have to extend, etc. to meet our hiring goals in the US for the second quarter alone! (I thought it was a pretty big number.) Did I mention you generally have to be willing to travel? Also, as a sign that the job market for people like us is pretty good... not one person bothered to send me their resume as I offerred in “IBM to Invest $1 Billion in On Demand.”
  
• People who have grown up doing point-to-point integration between SAP modules will need to jump into a new projects where point-to-point is discouraged and the new paradigm is to use the XI infrastructre as a broker (that smells a lot like an Enterprise Service Bus or ESB).
• Soon, it won’t be just the J2EE SOA crowd who will be thinking about visually stringing together discrete services to form larger, coarse-grained “composite services.” An army of SAP consultants will soon be trying to modify the out-of-the-box SAP processes by inserting new, client-specific steps. (Gasp) Will they be doing it in visual modeling tool? And which tool will they be using? ARIS for SAP Netweaver? WebSphere Business Modeler? WebSphere Integration Developer?
• This impacts more than you think. How does an I/T architect estimate how long it will take to complete an SOA-enabled SAP project? Will previous estimating guidelines apply? (No!) Will the best practices be different? (You bet!) Will the methodologies have to change? (Absolutely!) How will you test an SOA-enabled SAP solution? (Hmmm..)
  
• And don’t forget the .NET crowd. Project Mendocino is out there exercizing integration options between things like MS Outlook Calendars and SAP.
• With all the buzz surrounding whether an SAP customer should use Netweaver XI or IBM WebSphere products to integrate their systems, it is easy for some of the smaller integration vendors to be ignored.

Is all that disruptive enough? Or do I give SAP too much credit?

There are lots of new skills that will have to be learned by lots of people. There are lots of big impact decisions to be made. Lots of companies will need expert help. I repeat the mantra from a previous post.. its a great time to be an I/T Architect.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.