Adversity as a Career Builder?

I read a post at Fast Company called "The Value of Rough Seas." There is a quote in there which got me thinking about whether we really have to participate in some really rough projects to advance in our confidence, skills, and credibility.

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

Certainly, being on a rough project is like combat sometimes and just surviving the experience is a real boost to our confidence on the next project.

However, do we learn just as much when we are lucky enough to be on a project where the leadership is truly competent and the big panic that we brag about surviving was avoided completely? Is there a temptation on some people to enjoy the adrenaline rush of the pressure cooker project a little too much?

As I think about it, we probably gain a lot more visibility on the pressure cooker projects. The pressure certainly helps us remember what NOT to do or what part of a project estimate NOT to short change. I probably makes us better reviewers of other people's designs and other people's estimates.

In some sense, these are really more like project management and risk mitigation skills. And.. these are not necessarily the first skills that come to mind when doing word association with the phrase "I/T Archtiect."

I suspect we might actually learn about the technical aspects of one architectural decision over another in the relative calm of a saner project schedule that allows for some give and take between mentor and protogee.

I guess it depends on the critical success factors of the project. If the delivery date is all that matters to the client, they won't be too impressed with all the extra flexibility you built in which dragged out the date.

But all of this is part of the "art" of being an I/T Architect I think. We have to learn how to judge what the real criteria for success are. True success may not hinge on architectural elegance... though it might be more fun if it was. We have to judge what we have to do to be "done" and declare victory.

Another way of looking at it is the whole tactical vs. strategic struggle. We often want to pursue the really elegant, strategic solution. We often have very tactical clients. In this case, we have to balance how much elegance we have time to work into the tactical solution.

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

IBM Proposes to Donate Part of Rational Unified Process to Open Source Community

IBM's Rational Division Proposes Major IP Donation to Open Source Community
— RUP is a software process platform that has guided some 500,000 developers around the world in projects ranging from small-scale product development to large industrial-strength systems, according to IBM. It comprises what IBM says is 'a vast collection of methods and best practices for promoting quality and efficiency throughout software development projects.' Now IBM proposes to donate a subset of the platform to the Eclipse Foundation.

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

Irving Wladawsky-Berger Blog

I highly recommend the blog of Irving Wladawsky-Berger for his "observations, news and resources on the changing nature of innovation and the future of information technology." If you don't know, he is Vice President of Technical Strategy and Innovation at IBM.

I am particularly fond of a post of his entitled The "Outside-In" Enterprise which describes how technology can alter the balance between what is done inside and what is done outside a corporation. Hint - more can now be done outside corporate boundaries.

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

Are you Pi-shaped?

I once heard a very senior I/T Architect in IBM talk about how the best I/T Architects are Pi-shaped. I wish I could remember his name but let me try to explain his remark.

Imagine if you will, that all possible skill categories make up the horizontal axis across the top of a big skill rectangle.

• Java
• J2EE
• Database
• Middleware
• Object-oriented analysis and design
• Legacy system integration
• Networking, Firewalls, Load balancing
• Security
• Manufacturing industry
• Banking industry
• Insurance industry
• Facilitation skills
• Project Management
• etc.

Now imagine that the vertical axis of this big skill rectangle from top to bottom represents the level of skill

• The 30,000 foot view, the business executive summary view
• The 10,000 foot view, the I/T executive view
• The 1,000 foot view, the first level I/T manager who remembers programming view
• The 500 foot view, the programmer or DBA view
• The 100 foot view, the view of the guy who reads all the manuals for fun
• The 10 foot view, the view of the guy who wrote the low-level device driver code

You can image that each person has some combination of horizontal breadth of knowledge as in "I know a little bit about a lot of things." and vertical slices of expertise as in "I know how every layer of this technology works from concept to low-level coding and performance tuning."

This wise I/T Architect's opinion was that the very best I/T Architects are Pi-shaped as in the Greek letter Pi. He said all good architects have a broad spectrum of knowledge across the top layers of the skill rectangle. Yes, I know nobody knows everything, but through their experience they have seen almost every type of technology applied to a variety of business situations. He said they also have at least a couple of vertical slices where they have the ability to take a "deep dive" into extreme levels of detail. Hence, a "Pi-shaped" I/T Architect. Even better if you can be a three-legged or four-legged table.

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

WebSphere Community Edition

IBM recently announced a new member of the WebSphere product line called WebSphere Community Edition. What sets it apart is that it is a free download. Anybody who wants to use it can get it for free, play with it, build something with it, and prove their idea has value without ever having to pay IBM anything. If after proving to themselves the software developed on WebSphere Community Edition has value and they are afraid to go into production without support, they can then purchase one of three levels of support.

This WebSphere product concept sounds great for small companies and even "skunkworks" organizations inside big companies. They can try out something "under the radar" of all the bean counters. They never have to go beg anybody for funding for this software until they know they have proven their idea works! Then they can go into production without making any modifications to their code with IBM support behind them.

What does it mean to have IBM support behind a product based on open source software? As far as I can tell it means that if a bug is found by a customer paying support in the open-source components of WebSphere Community Edition (in this case Apache-Geronimo I think) then an IBM developer will address the problem, hopefully create a fix, and then this fix is contributed back into the open source world. Essentially, by buying support you ensure somebody is out their working the bug list with a sense of urgency.

The more I think about this, the more I think this is a great idea.

• No cost of entry
• Easy to try out and prove an idea works before begging for $$$ from the bean counters
• Easy to abandon an idea without looking bad to the bean counters
• When you're ready to go public and do real business, you get to sleep at night with IBM support behind that open source code.

I think this concept will sell!

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

Welcome

I have decided it is time for me to jump on the blogsphere bandwagon. My employer, IBM, actually encourages employees to blog now on the premise that the company will win in the long run. Back in 1997 when other companies were trying to figure out how to keep employees off the internet during work hours, IBM was encouraging employees to "get out on the net." IBM views blogging in much the same way today. Here is a quote from the employee blogging guidelines "it is very much in IBM's interest – and, we believe, in each IBMer's own – to be aware of this sphere of information, interaction and idea exchange."

So here I am. I plan to post as I am inspired to do so by events or as I get information I think is worthy of sharing. My topics will be:

• Software requirements gathering
• Software design
• Software construction
• Software development environments
• Software testing
• Object-oriented analysis and design
• Java
• J2EE
• WebSphere products
• Hints & tips in general
• What it means to be a consultant (whether as an internal employee or someone who is brought in from the outside like me)
• Vendor hype
• Political contraints on the solutions we recommend
• Selling your idea to decision makers who can fund it
• Building credibility as an I/T Architect
• Middleware
• Databases and database tools
• Methodologies
• Technology trends

So welcome again. I guess I will put on my seatbelt and try to enjoy this journey into the uncharted blogsphere. Your comments are welcome.

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