Tuesday, February 21, 2006

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.

Thursday, February 16, 2006

$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.

Monday, February 06, 2006

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.

Sunday, February 05, 2006

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

Friday, February 03, 2006

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.

Wednesday, February 01, 2006

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.