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.

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.

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.

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.

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.

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.

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.

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.

 

Epidemic Career Advice

A friend recently loaned me a thought-provoking book called The Tipping Point: How Little Things Can Make Big Difference by Malcolm Gladwell. The general subject is how epidemics spread. Not just diseases but more importantly - epidemics of information. What starts fashion trends? How does word-of-mouth lead to a restaurant becoming wildly popular? Why are some advertising messages memorable and why do others flop? Click here for a summary of the book’s primary points and definitions.

When I was about half way through the book I commented to the friend who loaned it to me how much I was enjoying it. He runs his own Real Estate Title business and he commented that the book changed the way he looked at his career and the way he runs his business. He explained that a lot of his business comes thru referrals from real estate agents. Around Christmas time and New Years, many businesses like his invite customers, prospects, and business partners to parties. He said he had done that before but after reading this book, he decided to wait until after the usual party rush. He threw an “Equinox” party in March and invited all the real estate agents around him. He was amazed at how many people called to ask “What’s an equinox party?” and how many more people showed up for this unusually named event than had showed up at Christmas parties in previous years. The equinox message was “sticky”

His comment got me thinking, “Is there an application of The Tipping Point in the field of Enterprise Architecture or in a successful I/T Architect career?”

In the book, the author identifies a “Law of the Few” which describes how an epidemic can start with only a few people... if they’re the right kinds of people:

• “Connectors” – People who know lots of people. People other people want to know. They are “social glue”.


• “Mavens” – People who provide us with new information. People who accumulate knowledge but are not passive collectors. They want to share what they know. They educate and help without persuading.


• “Salesmen” – They persuade us when we are unconvinced. They get us to make decisions or change our minds. They build trust and rapport quickly. They infect others with their emotions.

The author also says that in order for a message to spread rapidly, the message has to be “sticky”... an attribute called the “stickiness factor”.

Another important consideration is what Malcolm Gladwell calls “The Law of Context.” Rapid spread of information, rumors, opinion, disease, etc. is heavily dependent on the conditions and circumstances of the time and place.

Back to the question, “Is there an application of The Tipping Point in the field of Enterprise Architecture or in a successful I/T Architect career?”

Is, for example, all the current focus on Service Oriented Architecture (SOA) an example of an information epidemic? It seems that not too long ago, only the true “early adopters” of technology were taking it seriously. Now, even some of the more technology risk adverse companies are taking notice. Is the SOA message “sticky”? There are certainly a lot of “salesman” out there extolling the virtues of SOA. There are certainly a lot of I/T Architects who want to be "thought leaders" in this area. The concept of being a thought leader certainly seems like being a “Maven” to me. Am I an SOA “connector” by virtue of the number of people in my email address book, the number of visitors to this blog, the number of people I’ve talked to on IBM conference calls over the last 13 years, and the number of clients I’ve shared a whiteboard with? All this talk about SOA also comes in the context of many companies moving from mere cost cutting to seeking business flexibility to chase “top line growth”. And what about the “resume” factor as epidemic context? I am sure there are thousands of technologists who all want to make sure their resume contains real-world experience with the latest buzzwords and alphabet soup just in case the next round of “business transformation” has them looking for a job soon. That context certainly makes one segment of our industry very receptive. (It may be a little off topic but check out Scott Mark’s “Resume Points to Consider if You Want a Job at a Large Enterprise” and James McGovern’s “Enterprise Architecture and Resume-Driven Design” for some good discussion on this.)

Returning to my friend with the Real Estate Title business, what should I do to take advantage of these concepts to enhance my I/T Architect career? What follows is my attempt to cast the characteristics of an information epidemic into career advice.

• Be a connector. Spread the word of another’s success. Know who to talk to that knows people. Be a friend just because you can. Don’t worry about whether there is something in it for you. If all your friends are in I/T, make a conscious effort to cultivate personal relationships in other areas.
  
• Be a maven about something someone cares about. We all need to have some expertise that others value. More importantly, don’t hoard your knowledge. Help others be successful. (The Golden Rule comes to mind.) Pass lessons learned (good and bad) on to others so they can benefit. Educate others respectfully for their benefit. Expect to learn something valuable in the process but something probably unanticipated.
  
• Though some I/T Architects may consider it “going over to the dark side”, be a salesman. Maybe you don’t sign up for a real sales quota ($$), but be able to persuade others and sell your ideas. It is also important also to be able to translate back and forth between business and technology domains and be able to communicate costs and benefits to both sides in their language. Be enthusiastic about what you’re doing let it infect others. Be trustworthy.
  
• Make your architectural messages “sticky”. State your message in a way it will make sense to the hearer and in a way it will be memorable. See also my previous post “Naming Well, an Essential Skill of an I/T Architect”. Looking back on it, I think that good class names, method names, variable names, pattern names, etc. are “sticky”. Learn to judge how much detail is just enough for the listener and how much detail is too much for them.
• Be aware of the political context. I used to call this “political awareness”. Be aware of what is keeping your client up at night. Be aware of which “boat anchors” (an architectural anti-pattern) are out there that nobody will criticize because the guy who bought it is too powerful and won’t admit to making a mistake. Know how to work your organization’s budget cycle (or your clients). Also it is good to know what is keeping your customer’s customers awake at night, too. Be aware of which decision makers are “movers and shakers” and which ones are coasting to retirement. Know who has influence even if they don’t make the decision.
• And here's the hard one. Don’t be afraid to be part of an epidemic. Ride the wave fearlessly. Enjoy the process. Stretch the envelope. Get out of your comfort zone. See also "The Value of Rough Seas." Now if only I can practice what I preach.
  

"A smooth sea never made a skilled mariner." -- English Proverb

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

Feel Your User's Pain

All you Microsoft bashers out there will enjoy this post on Dave Nicolette's agile software development blog: Connecting Users with Developers. Make sure you click the "Share Pain" button and view the video!

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

Supply Chain, the Next Sarbanes-Oxley

I have spent most of my I/T architect career working on customer service and sales & marketing type applications in the industrial sector. I will admit a lack of real-world experience in the area of supply chain. However, when I read Security Compliance: Customs Rattles the Supply Chain I found myself wondering how long it would be before my first supply chain project.

It seems that the recent political spat over the safety of US ports and public discussion of how ports could be used by terrorists has shined a bright spotlight on something called the Customs-Trade Partnership Against Terrorism, or C-TPAT. There is now some widespread speculation that this currently voluntary program might become mandatory and have as big an impact on US corporate life (and I/T Architects) as Sarbanes Oxley.

In a program called Operation Safe Commerce, it seems that the Department of Homeland Security has been quietly using GPS and RFID technology to track the cargo containers enroute to some major US importers and the results have been unsettling. A few quotes:

....companies actually know very little about what goes on in their supply chains.
Among common unsafe practices identified by these sources were: truckers dropping off containers without ever encountering terminal security, containers left in unsecured areas, and containers bypassing a port that's considered safe (even if scheduled to pass through that port) and traveling instead through a country that poses a greater threat—without either the company or U.S. Customs and Border Protection being informed.”

Some other randomly selected quotes:

Right now, information about any given supply chain is hard to come by. And that's by design. The goal of supply chains is to get something that's needed—a part, a product—to where it's needed as quickly and cheaply as possible. If a container arrives too late to be loaded onto one ship, it's rerouted and loaded onto another. And as long as the container arrives on time—or close to it—no one need be the wiser. In fact, historically, each person or entity that handles a shipment collects and shares information only to the extent necessary to guard against liability.
Similarly, Customs was created to enforce tariffs and calculate import taxes. And while Customs' role expanded to combat drug trafficking in the 1980s, regulating trade was the department's primary job until September 11, 2001. Now, says Robert Bonner, former commissioner of U.S. Customs and Border Protection (he resigned in November), "The priority mission of U.S. Customs is national security."
Experts say that Bonner, who was sworn in at Customs on Sept. 24, 2001, was right to change the agency's focus. Most agree that the likelihood of terrorists attacking the United States through the global supply chain is so high that it's a matter of when, not if. Such an attack (most analyses focus on a dirty bomb) won't primarily be designed to kill a lot of people, but to cause panic. "It isn't the event but the sudden lack of faith in the system that it causes," says Stephen Flynn, senior fellow for national security studies at the Council on Foreign Relations.

If a bomb goes off, Flynn says, there will be huge pressure on the government to close all the nation's ports until every container on every site in the country is inspected. An October 2002 war game that mimicked that scenario found that closing the nation's ports for as many as 12 days created a 60-day container backlog and cost the economy roughly $58 billion.

Legally, a company is responsible for a container only when it formally purchases it, which—precisely for that reason—usually doesn't occur until it reaches a port, either in the United States or abroad. Target, for example, typically does not legally purchase the clothes it orders from China until they arrive in the terminal. But the government wants importers to take responsibility for everything that occurs prior to purchase, even if the container is in the custody of a trucker in China or a longshoreman in Rio de Janeiro. The principle vehicle for this is C-TPAT. This so-far voluntary program gives certain benefits, such as reduced inspections, to companies that can show they meet a minimum level of supply chain security.

The second prong of Customs' strategy is to collect as much information as it can about what's happening in the supply chain so that, through data mining, it can spot anomalies. The key to this is the Automated Commercial Environment, or ACE, a $3 billion-plus trade processing system begun in 2000, which Customs plans to complete by 2010. ACE has modules that do everything from serving as Customs' ERP system to targeting containers for inspection. Within the next six months, carriers entering the United States through land-border crossings in seven states will be required to send close to 100 data elements to Customs, including information about the vehicle, its driver and its cargo. If they don't, they don't get in. Customs is also piloting an ambitious ACE add-on called the Advance Trade Data Initiative (ATDI), which requires importers to share with Customs every bit of information about a shipment, including the purchase order, which ports it passes through, proof of delivery and its final destination within the United States.

Soon, companies that achieve this level of compliance will be rewarded with a Green Lane designation—essentially a "get out of Customs free" card that will do for borders what E-ZPass does for highways.

It's also important to limit access to supply chain information. "If the bad guys know that IBM is going to ship products from point A to B on a particular Tuesday, it gives them a leg up," says Debbie Turnbull, IBM's program manager for supply chain security. A bad actor inside a company could alter the information attached to a container from Karachi, Pakistan (which might raise an alarm), so it looked like it was coming from a factory in Hong Kong (which might not). Or that bad actor could pass scheduling information to a crony outside the company. IBM uncovered one such plot a few years ago. A worker in a plant in Mexico noticed that one container he was about to load was 53 feet long on the outside, but only 50 feet long on the inside. Upon inspection, it was found that the container had a false back, behind which was hidden several million dollars in narcotics.

Even secure processes "can be compromised," says Ken Konigsmark, Boeing's C-TPAT program manager. "[Overseas workers] get paid peanuts, and it would be very easy to bribe them." CIOs need to be able to tell when a truck driver leaves a factory and when he arrives at a port. The CIO can then alert Customs if a four-hour trip turns out to take 12.

For example, Customs wanted information that UPS stored as address line one in address line two. In other cases, Customs wanted information that UPS simply didn't have, such as a driver's passport number.

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

I/T Architect Certification Revisited

I previously blogged about a Vendor-Neutral I/T Architect Certification Program sponsored by The Open Group. I noticed recently that IBM became the first employer to have its internal I/T Architect Certification Program “accredited” by The Open Group. This was effective January 26, 2006. I believe what this means is that I/T architects who work for IBM and are certified by internally by the IBM I/T Architect Program will also qualify for The Open Group I/T Architect Certification. (For anybody who cares, I've been an IBM-Certified I/T Architect since July 1996.) The Open Group calls this “indirect” certification. I expect HP will also get their I/T Architect certification program accredited as well as HP is also a “Platinum Member” of The Open Group. If your employer does not have an accredited certification program or you are an independent, you have the option to get a “direct” certification. See I/T Architect Certification for more details.

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

$1 Billion Investment in "Info on Demand"

My buddy Bob Z. pointed out this bit of news about IBM to Invest $1 Billion in "Info on Demand" including a plan to add almost 10,000 new consultants over the next 3 years. Wow! I think now is a great time to be an I/T Architect. Send your resumes to me so I can get the employee referral bonus ! (sorry, I couldn't resist... hey at least I'm honest)

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

Google to Partner with IBM?

There is an interesting piece on CNN Money Googling IBM in which Eric Schonfeld argues that Google should seek a partnership with IBM. Some quotes to get your attention...

"Partners and analysts believe that Google (Research) is ready to plunge into the lucrative business-software market—and IBM (Research) may be the best partner to help it dive in."

"Of all the big tech companies, IBM is perhaps the least threatened by Google, since IBM's focus is on large corporate customers. IBM, in turn, could tap into Google's small-business constituency.

Talk about a powerful partnership," says IDC's Gens. "It would bring hipness to IBM's brand and corporate gravitas to Google."

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

Why I Hate Frameworks - Humor with a Purpose

For anyone who may have enjoyed the humor found behind my previous post Waterfall Methodology Makes a Comeback! there is some still more humor with a purpose to be found in the post Why I Hate Frameworks on The Joel on Software blog.

Why I Hate Frameworks does a great job of pointing out the danger of using frameworks which attempt to solve every problem of software architecture known to man by providing seemingly infinite flexibility. Along the way, the framework becomes so complex it becomes unusable for the very practical, near-term problem we face now.

Thanks also to Deepak Kaul for pointing out this gem was also on Grady Booch’s blog.

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

.

Waterfall Methodology Makes a Comeback!

Check out this post I discovered via link on Grady Booch's blog regarding the comeback of waterfall methodologies being celebrated at an upcoming Waterfall 2006 Conference. Register now!

For anybody who doesn't know, Grady Booch is an IBM Fellow and was founder of Rational prior to its acquisition by IBM.

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

Naming Well, an Essential Skill of an I/T Architect

I had a recent experience on my project which caused me to think about the impact of names and the choice of words we make on I/T Architects and the success we have on our projects and in our careers.

We had a production problem that was giving us fits. I came into problem determination somewhat late and was invited to a meeting to discuss the issue. There were error messages in the log and the team was investigating the data associated with the transaction that failed. One developer who had been looking at it for a while said "I don't see a problem... the data looks good." There was then much discussion about what the cause of the problem might be. Someone raised the possibility that perhaps the transaction that threw the error was not the cause of the problem at all. “If the problem was a deadlock on a database record, then the next transaction to try to update the same record would fail.” Without thinking much about it, I threw out the comment "Then the transaction that failed was the victim and not the perpetrator." Another architect on the project then smiled, leaned over, and made an interesting side comment on all this with a comment along the lines of "That's why you're THE architect!"

At first I didn't quite know what he meant. It appeared to be some reference to me being the lead architect. Also something about my casual (casual to me at least) comment had something to do with me getting promoted over time to my position. He and I have a great working relationship I think (tell me if I’m wrong “Z”) and the apparent reference to my rank in the organization made me a little nervous. I didn’t know where this was going and there was still a room full of ears in the room and a couple still on the phone.

Then he let me in on his perspective. He said I had quickly come up with two very descriptive words; "victim" and "perpetrator." His opinion was that my choice of words were immediately understood by all. (My words now.) They provided a "shortcut" for everyone who had not yet realized that the problem might not be with the transaction that threw error messages into the error log. The choice of words allowed all to quickly change gears and consider a new (and perhaps more likely) cause of the problem.

Shortly later I had several hours to think about this while I was captive in a seat in coach as I was flying cross-country. I was, of course, glad my comments and the names I chose were helpful. I wondered to myself at 34,000 feet, “Are the words we choose to name things really that important?” I had a slightly more provocative thought, “Was my ability to choose names for I/T concepts that were quickly understood a major contributor to my success in my career?" Could it be true that the names I have chosen over the years for all those problems, symptoms of problems, objects, attributes, methods, database tables, columns in databases, subsystems, components, use cases, etc. really have been a major productivity boost for me and project my teams? Bored with the SkyMall catalog I continued...

• How many hours of development time have been saved over the years by not having to explain a concept over and over because the name itself helped explain the concept quickly?


• How many painful hours of documentation were avoided?


• How many hours of skill transfer were avoided when new developers joined a project in mid-stream?

Unfortunately, there is no way for me to know but my gut instinct is that the number of hours saved over all the projects and all the team members over all the 20+ years in technology is large. Intuitively, I think it must really be a big deal.

As I found no way to get comfortable in my airline seat in coach so as to get some sleep, I contemplated still more questions. “How do you tell if you're good at it?” After all, nobody goes around saying "I want Phil on my project because he names things well." More likely they say something like "I want Phil on my project because he's been successful before" or "I want Phil on my project because he's up on all the latest technology."

Wait a minute. Keeping up is hard work keeping up and there are only so many hours in the day. Could the real story be that I am successful in spite of being a step behind the latest tech craze because I name better than the ultra-geek who is up on the latest thing? Thankfully, I fell asleep in that uncomfortable seat before this thought went too far.

Now that I’m back home, I guess I have no excuse for continuing to think about this whole “naming thing.” With all the ethnic diversity in the software business, is this an area where aspiring I/T Architects from other cultures (than mine) might have trouble picking the perfect name for others to grasp immediately? My guess is probably "yes" but I'm no cultural anthropologist or cognitive psychologist or anything like that. (Incidentally, my architect-friend who complimented me on my choice of words "victim" and "perpetrator" grew up in Brazil.) If the recipient of my architecture documents is from a different culture than mine, does that make me the one at a disadvantage? Again, my professional instinct says the answer is "yes" but I can’t prove it. Is naming well a skill that almost any technically inclined person can learn? Or is it a gift? Is there a "naming gene" that predisposes me to compete at a higher level in the software business "naming olympics?" Do I name well because of how God wired my brain or because of my unique combination of life experiences? Or both? I wish I knew.

In conclusion, I believe I have convinced myself that “naming well” is indeed an essential but unrecognized skill of an I/T Architect... and I am grateful to have this small advantage to keep me gainfully employed a little longer. :-) I’m not sure I know how to teach someone else to “name well” but I know a good name when I hear it. I invite your comments on this topic.

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