Friday, May 26, 2006

Are All the Good I/T, Science, and Engineering Jobs Going Overseas?

Over the last several years, I have endured much gloom and doom talk among I/T professionals about the evil influence of offshoring of I/T jobs to India, China, and other lower-cost countries with large numbers of highly educated workers. The mood around me seems to have improved over about three years ago from one of panic to one of acceptance (or is that resignation that offshoring isn't going away?).

I recognized early that one important enabler of this business model was the wide availability of inexpensive and reliable telecommunications. This allows, for example, me to have my regular Tuesday and Thursday morning conference calls with my co-workers Bangalore without anybody really worrying about the cost of the phone call. I do, however, remember making my own jokes about how the US needed the CIA to put some Navy SEALs in mini-submarines on the floor of the India Ocean to cut the fiber optic cables heading to India.

As a sign of the improved relationship with my Indian friends, I got brave enough to share my joke with one of our programmers from Bangalore. I was pleased to find he took my joke in a good natured way and countered my joke with a laugh and something along the lines of "Oh... we have so many redundant lines we'd be ok in Bangalore. But Pakistan... if you cut one fiber optic cable the whole country would be out of business!"

I've been a little behind in my blog reading and I stumbled across a gem on Irving Wladawsky-Berger's blog. He's the IBM Vice President, Technical Strategy and Innovation. He has a posting entitled Skills, Jobs, Competitiveness, and Innovation which address the comment I've heard many times from I/T professionals "I wouldn't let my child go to college to major in computer science." He makes several good points:
  • According to the Association of Computing Machinery (ACM) the size of the IT employment market in the United States today is higher than it was at the height of the dot-com boom.
  • Information technology appears as though it will be a growth area at least for the coming decade, and the US government projects that several IT occupations will be among the fastest growing occupations during this time.
  • And... like we in leadership positions in custom application development business at IBM Global Services have been preaching to our practitioners... the role of the I/T professional in the US and developed countries is changing to one which is more consultative vs. heads down pounding code into the keyboard. Soft skills and business knowledge are becoming more important. "These new jobs are much more collaborative, interdisciplinary and broad than in the past. They require solid technical competence, combined with industry, business and management knowledge as well as good communication and interpersonal skills."

I will add this one cautionary note. The attitude now is both that offshoring is not going away and that decision makers will lead with offshoring. By "lead with offshoring" I mean that almost any big project will be assumed from the beginning to be delivered by a globally dispersed team. For consulting organizations, that means the first proposal will already have global resources baked into the projected costs. (If for no other reason than the assumption that the competition will.) For more evidence see IBM announced a $200 million investment.

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.

Wednesday, May 24, 2006

SAP Projects and the "Big Bang" Theory

A fellow IBMer saw some of my previous posts about navigating the SAP maze from a custom development point of view and sent me an email basically asking the question "Can SAP projects be iterative? All the ones I've ever seen always seem so 'big bang.'" The more I thought about his question, the more I realized how reasonable the question seemed to those of us who've been building custom applications. After all, how many small SAP projects have you seen? How many have put something in production in 3 months? Don't most of them have budgets in the tens of millions of dollars (or even more)?

I decided to pose his question to a "real SAP consultant" I met recently. She claimed that SAP projects can be iterative. An project can cycle thru multiple iterations of the ABAP programs used for point-to-point integration with SAP (the old style integration pre-dating XI) and companies can and do gradually add new modules to their SAP environment. (This is probably more incremental vs. iterative).

I challenged her "don't the customization done at the beginning of an SAP project drive the generation of database schemas? Aren't these database schemas hard to change?" She said she typically isn't involved in that kind of SAP setup but that it could be done. There was, however, a catch. Such a change would probably require some kind of data migration project associated with it to move data from one schema to another. My gut tells me these data migrations are almost always painful. There is a reason IBM acquired Ascential a while back. The phrase Master Data Management (MDM) is familiar to all SAP consultants. If your client is looking at SAP, you'll get familiar with it too.

I think this may shed light on why SAP projects appear to be such a "big bang". Most companies do not want to support more than one system of record simultaneously. (The "E" in ERP stands for "Enterprise" so otherwise you are taking the "E" out.) They want SAP to take over all of whatever it is doing (for example the order to cash process). Otherwise you get into a need for the new SAP and the old legacy system to exchange a lot of information to keep each other "in synch" with what they are doing. Everyone these days wants their data up-to-date in real time so that probably means real-time synchronization.

I know of a company facing exactly that kind of decision. They don't really like the idea of rolling a new system out across the whole company. They'd prefer to roll new capabilities out to a single line of business first. But... each line of business shares a lot of the same customers and dealers. They often share warehouses. Shipments to customers often contain a mix of products from different lines of business. With today's legacy systems, customer can mix products from different lines of business on the same order. Imagine the implications of changing the order to cash process to a new SAP system and rolling it out to only one line of business at a time:
  • Do I track inventory in two different systems?
  • How do I load a truck at the warehouse if the shipment includes products from both systems?
  • How do I keep up with vacant storage bins in the shared warehouses if the inventory is split between two systems. Do I draw a line down the middle and and disallow putting line of business A's inventory on the line of business B side of the line?
  • How will I generate the pick list for the people that load the trucks? Will they have to work from two lists? How do yo make sure it'll all fit on the same truck?
  • Dealers don't have to split orders by line of business today, will they have to split their orders into two separate orders tomorrow while we're in transition?
  • Will customers have to check the status of different line of business orders separately?
  • Will my dealers get a single invoice with all line items like today? or will they get two separate invoices, one for each system?
  • Will dealers get a single monthly statement?... or two separate monthly statements?
  • When a dealer visits the B2B website today they can order products from different lines of business from one screen. In the future, will they have to go to one screen for one line of products and to a different screen for the others?
So, the choices are clear (or is that murky?):
  • Offload the data integration onto your employees and customers; making them deal with separate orders, separate shipments, separate invoices, separate statements, etc. OR
  • Spend millions on middleware solutions to broker all transactions so that they all look to the external customer like there is a single back end system OR
  • Put the "E" back in ERP and don't even try to roll out an order-to-cash process until your whole business (Enterprise) is ready.
Which would you choose?

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.

Tuesday, May 16, 2006

Consumers Wag the Enterprise I/T Dog

Here's an interesting read. What happens when your customers have a better PC and more bandwidth at home than your employees at work? What happens when your teenager's cell phone offers more features than your sales force automation solution. What happens when these people come on board as employees? Will they be satisfied with what your enterprise has to offer them?

Gartner: Commoditization means consumers will wag the enterprise IT dog by ZDNet's David Berlind -- As one of the four major pairs of themes underlying Gartner Symposium/ITxpo here in San Francisco, Gartner research chief and distinguished analyst Steve Prentice explained to attendees why the commoditization and consumerization of technology is not to be ignored an an enterprise's strategic information technology roadmap. Prentice's presentation was given as part of the event's open ceremonies. Companies [...]

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

Sunday, May 14, 2006

Data Integration Nightmare for Your Supply Chain?

A while back I had a post Supply Chain, the Next Sarbanes-Oxley regarding the possibility of greatly increased government regulation of supply chains due to Homeland Security concerns. This included the possibility of US importers having to take responsibility for security of their inbound shipping containers enroute (regardless of when they legally take ownership of the goods), increased demands for standardized data (What was the passport number of the driver who brought the goods in from Mexico?), and more. The US Customs is currently piloting with some major importers a program which uses Global Positioning Satellite receivers to track the exact route taken by ocean bound shipping containers. (Why did your shipping container make a stop in Pakistan on the way to the US?) This kind of information collection is currently voluntary but there is speculation it could become mandatory. For an update of pending Customs-Trade Partnership Against Terrorism legislation take a look at C-TPAT Legislation Update.

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

Thursday, May 11, 2006

Is the Mainframe the Best SOA Platform?

A while back I had a post about a major US bank running a web services performance test and getting spectacular results using multiple zSeries Application Assist Processors (zAAP). James Governor makes an interesting point that using zAAPs on the mainframe can significantly reduce software licensing costs, making it a potentially attractive platform for new SOA-related infrastructure. A specific customer example with Farmers Insurance is cited here. Another post says that mainframe CICS customer are upgrading to the lastest CICS version which is XML- and web service-enabled at a faster pace than seen by CICS in 35 years. The same post claims 25% of z-Series mainframes are now running WebSphere Application Server... thats one in four. This post gives a customer reference from Wachovia (only the 4th largest US bank) which is running WebSphere tools on the mainframe.

Ex-Smalltalkers rejoice!

Check out Is smalltalk set for a renaissance? on James Governor's MonkChips blog.

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

Tuesday, May 09, 2006

How to Talk to an SAP Consultant (If You Must)

I discovered via last week’s post SAP Disrupts Everything that I am not the only one in the I/T Architect blogsphere who is craving information on the integration of SAP with the rest of the information technology world. It was by far my most popular post ever. (Thanks to everyone who visited and special thanks to those of you with widely read blogs that directed others to this post.)

I am just becoming aware that the package-world people and SAP people in particular don’t communicate very well with us custom development types.

A prime example is the use of the word “requirements”. You’d think this was an almost universally understood word in software development. Well... maybe not. When I think of requirements, I think of things like the answer to “What do you want your system to do?” or maybe a collection of use cases. Oh.. and don’t forget non-functional requirements like “if the database crashes we need to be able to recover in 4 hours or less”.

I am still trying to figure this out but it seems that to someone who has grown up in the SAP space, the word requirements takes on a very precise and specialized meaning. This is not a term used in the same sentence with open-ended, green field questions. SAP has something called a “business process hierarchy”. At the top level, this might include something like purchasing. At the next level down purchasing is decomposed into purchase requisition, purchase order, etc. At the next level down, it would be further decomposed into things like release of purchase orders, transmission of purchase orders, scheduling agreement delivery schedule, transmission of scheduling agreement, etc. This decomposition continues down to an excruciating level of detail, perhaps 6 levels down. A “requirement” then is which of these many low level business process are chosen out of the SAP-approved business process hierarchy which are identified as “in scope” for the SAP implementation in question.

In the newer versions of SAP, all of these many different business processes are loaded into a tool called Solution Manager which visually provides a hiearchial way to browse these business processes. This tool also provides a way to load things like the user roles and client’s organizational hierarchy. Maybe requirements becomes a slightly bigger term encompassing all the “in scope” items in Solution Manager. Not 100% on that so I’m open to comments or correction.

I’ll try to point out more examples of SAP-specific language and nuance as I bump my head against them.

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.

RFID and Privacy Issues

Some of you may have seen a previous post of mine Real World RFID Application in Production Now . I heard about another interesting (chilling?) RFID application in the works in the casino industry.

If you have been to a big name casino, you’ve heard about the “players cards” or “players club cards” in which the gambler gives up all anonymity in exchange for the chance to be earn some of the famous casino perks or “comps” (short for complimentary drinks, meals, shows, etc.). This also makes it easier to become a “rated” gambler. The gambler inserts a coded card into a card reader at slot machines, blackjack tables, etc. and the casino can determine who is gambling, what games they play, how long they play, how much they bet per hour, etc.

I heard that the casios are going to embed RFID chips into the players cards. They also plan to embed RFID into the high-value gambling chips (eg. $100 chips and greater). Of course, the casinos can put RFID antennas in the ceiling, floor, game tables, etc. along with all the other video devices used to spot cheaters.

Imagine you run a casino. You track the players club card in the wallet of a high roller’s back pocket as he gets off the elevator and heads for the gambling floor. He buys some big chips. You can track his movements from table to table and from slot machine to slot machine. Red Alert! He’s heading for the bar with $12,000+ in chips in his pocket! That $12,000 is not in play while he’s in there. Radio the pit boss to have a hostess intercept him with an invitation to an exclusive high limit black jack table and offer some free cocktails.

I’m not a security and privacy expert, but it seems like there’s plenty of opportunity to exploit the RFID infomation here.

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.

Wednesday, May 03, 2006

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.

Get Ready for n-Series

I just finished three days as practically the only non-SAP consultant amongst about 200 of my SAP consulting bretheren from IBM Global Business Services (formerly IBM Business Consulting Services). I must say that it was well worth my time and as I have the bandwidth to blog about it, I will add more posts about what I learned, my observations of the SAP space as it affects enterprise architecture, SAP and SOA, WebSphere vs. Netweaver XI, and maybe a few predictions about the future of the SAP space.

Let me start my run of blogs on this topic with hardware, however. Perhaps you’ve heard these platforms:
• z-Series (the mainframe)
• i-Series (AS/400 midrange)?
• p-Series (IBM’s unix platform running the AIX operating system)
• x-Series (IBM’s Intell-based servers used for both Windows and Linux)

But... have you heard of “n-Series”? Neither had I. n-Series is the IBM brand for a storage appliance. This appliance has great usefulness in the SAP space where customers are constantly making copies of databases.

Since it is an appliance, it plugs into the customer network with its own operating system embedded in it. This frees up resources on SAP database platforms for other things.

n-Series also offers FlexVol™ which decouples storage space from physcial disk drives. With it “system administrators can dynamically assign storage space to a user from the available pool of storage resources based on that user's space requirements. This flexibility can help your organization simplify operations, improve utilization and efficiency, and make changes quickly and seamlessly.”

n-Series also offers Flex Clone™ which provides the ability to quickly make copies of databases. In the SAP space, customers are always making copies for testing, promotion, exporting via batch processes, etc. “FlexClone technology generates nearly instantaneous replicas of data sets and storage volumes that require no additional storage space. Each cloned volume is a transparent virtual copy that can be used for enterprise operations.” Apparently, the embedded operating system keeps track with which blocks of data in any given file have changed. It provides virtual copies or “clones” for data blocks which still match the original copy. It senses when a user/system has made a change to data block within a virtual copy and only then allocates new disk space. The result? Faster copies, less physical disk space required, and faster backup and recovery.

Click here for more information on n-Series

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.

Monday, May 01, 2006

I've Gone Over to the Other "Dark Side"

In previous posts I have made some references to "going over to the dark side" whenever I talked about marketing types, salespeople, and selling in general.

For an application architect who has taken some pride in creating exactly the custom application solution a client needs, there is sometimes another "dark side" to be reckoned with. I'm talking about our fiends and colleagues who specialize in packages. Not all of us who've made a career in custom development like the prospect of our favorite clients looking at SAP, Oracle's ERP, Peoplesoft, Siebel, Reteck, or one of the other popular packages. It seems those "package types" speak a different lingo. Frankly, we are jealous of the salaries these specialists command. We wonder whether "packaged enabled business transformation" could be any fun compared to creating a solution from scratch. We wonder if anybody will ever do a big custom development project ever again. We fear we had better jump on the bandwagon.

Well, for a short time at least, I have gone over to this "dark side." For three days, I get to spy on my colleagues in IBM's SAP consulting practice and attend some of their training. One of my clients is seriously looking at replacing some legacy systems with SAP. In particular, I am focusing on the project methodology they use and the middleware issues related to connecting SAP with non-SAP systems. I'll get to spend some time learning the different approaches to this problem proposed by both IBM Software Group and (gasp) SAP's NetWeaver and XI.

Its too early yet to see how this is all going to turn out but my friends in the SAP space know how to do training. Below is the view of Baltimore's Harborplace from my hotel window. Its a tough job but somebody has to do it.

 Posted by Picasa