Showing posts with label Leadership. Show all posts
Showing posts with label Leadership. Show all posts

Monday, April 14, 2008

An Unexpected Turn at Management

I have not been nearly as successful at integrating blogging and podcasting back into my life as I wanted after my unreal, fantasy assignment in China ended at the end of October 2007. After the holidays and after some procrastination on my part, I was hit with a reorganization at work. Suddenly I was asked to be a first line manager.

For some people this would have been an exciting event and cause for celebration. But for me it was cause for pause. In some ways I had made a career out of not becoming a manager, a pure sales person, or a project manager. I had managed to advance to a pretty high level on mostly my technical merits, successful projects, and some happy clients who kept signing up for more services based on that success. I was comfortable in a career path that would hopefully get me at least one more promotion some day (soon I hope) to what IBM calls a "Distinguished Engineer." I was to be a mentor but not a real manager.

Now I was asked to officially take over the care and feeding of 14 specialists and architects. Something inside told me that I should say "yes" and give it my best shot. I still want to be a Distinguished Engineer but I think now is the time to grow some other skills which may prove valuable later. In the past, when something unexpected happened in my career it usually turned out to be for the best after all. Visit my other blog if you're curious about my outlook on such things.

Copyright © 2008 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, February 11, 2008

International Conference on Global Software Engineering

If you have been a regular reader of my blog, you know that globalization is one of my favorite topics of discussion. Therefore, I would like to draw your attention to the International Conference on Global Software Engineering which will be held August 17-20, 2008 in Bangalore, India. (Recently renamed Bangaluru.) The event is sponsored by the IEEE Computer Society.

Please note that if you have some thoughts to share, there is still time to submit a paper. The deadline for abstracts is Feb 21, 2008 and the deadline for papers is Feb 28, 2008.

Yours truly is a member of the Program Committee for the event. However, that doesn’t mean I automatically get to attend. I still have pay the registration fee and pay to get myself there… or convince my employer of the wisdom of spending their money to send me. I had the good fortune to visit my team in Bangalore and interview a few programmers for positions back in the fall of 2004 and I would certainly enjoy a return trip for the conference. I would be curious have any of you (my readers) had success at securing funding for travel to this kind of thing? If so, I’d love to hear how you justified the expense to your employer.

Copyright © 2008 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.

Friday, May 25, 2007

On War and Aggessive Project Schedules

I recently attended a 3-day "Business Design Assurance" or BDA held by my client. On the first day it was clear that there were still a lot of unresolved issues and the desired delivery date of the rollout to the first country was a risk. There was a lot of talk along the lines of "we can't go live without XXX!" A certain Senior Vice President could not attend the second day of the BDA but had the following as a message posted on the wall when everyone arrived for the second day of discussion.

"A good plan today violently executed is better than a perfect plan next week!"

General George S. Patton

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.



Powered by Podbean.com

Wednesday, May 09, 2007

The Global Lifestyle Time Challenge

I had a subtle career milestone today. Today I became fully aware that I was now "Global" ... with a capital "G" I think.

At about 6:30 am Central time I checked email at home before leaving for the airport. I saw an email from a business leader in the UK which set off alarms in my head that an important business decision my client needed to make was not being addressed. Knowing that a politically important deadline is approaching, I fired off a "this is a big issue!" email designed to alarm my readers that something important was not happening.

About 8 am Central time today I was waiting for a flight at the airport and my cell phone went off. It was that same business leader in the UK who took notice of my alarm. I don't know about you, but I don't get cell phone calls from people I've never met from other countries every day.

Shortly after arriving at my destination on the East Coast of the US, I scheduled a web meeting for tomorrow morning between people in Baltimore, Raleigh, California, and Beijing.

Later I was on a call between the US and Canada talking about interfaces to a system in China.

Still later I discussed architecture diagrams showing system components in Rochester (NY), Boulder, Dallas, Tulsa, Phoenix, Hong Kong, Beijing, and Toronto. I tried to figure out if the component in Hong Kong was really necessary. Could it be co-located with the rest of the stuff in Beijing?

I ate a hurried dinner of Tandoori Takki with two co-workers. One is a Norwegian citizen born in China but holding an American green card and the other was born in India but has been working in the US for a while. My history is boring compared to theirs.

Five minutes after checking into my hotel, I joined a conference call between the US and China but the co-worker from China didn't make the call. My co-worker later came online in China on instant messenger later and I pinged him about the call he missed. It turned out he was double booked for that timeslot. Heavy sigh. When are we going to solve time zone issues for calendars? I made sure he had the information for the web meeting in 9 hours.

This globalization thing isn't all its cracked up to be. Exactly when is it I am supposed to have some calm moments to think? When is it I am supposed to get more exercize like my doctor told me? Will the guy in California get up to make the web meeting at 6 am his time? Did I even have a right to call a web meeting that required someone to be there at 6 am? Will the guy in Beijing who has to join at 9 pm his time have a decent Internet connection? Did I have a choice on the time given that the guy we want to talk to was available then and it was a comfortable 9 am for him? Will my flight home on Friday be on time so I can make my daughter's piano recital? How early do I set my alarm clock for tomorrow? Early enough to hit the hotel treadmill or late enough to get another hour of sleep?

I have another trip to China coming up in two weeks. It is still fun for now. I can see how this could get old. I would love to hear how my readers in similar situations are handling the demanding hours, encroachment upon personal time, cultural differences, etc.

FYI, globalization has been a frequent topic of mine. You might take a look at some previous posts such as:


(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.

Copyright © 2007 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, December 12, 2006

Fortune Favors the Prepared Mind

I'm not finished yet, but I can already tell that The World is Flat [Updated and Expanded]: A Brief History of the Twenty-first Century is going to be one of those books which is going to havea great impact on my professional life. There is so much truth (I don't have to like the truth) in the information presented, I was motivated to shoot an email to almost everyone in my email address book to recommend the book to them as a way to prepare for the impact of globalization on their life and careers.

The email had "Fortune Favors the Prepared Mind" as the subject line and read as follows:

A friend of mine recommended The World is Flat [Updated and Expanded]: A Brief History of the Twenty-first Century to me as a great book on the impact of globalization. I'm only about 20% done with it (the audio version) but I think there is a lot of good material on outsourcing, offshoring, India, China, etc. which I believe would benefit each of you as you think the future and the kinds of opportunities we all probably need to prepare for.

See also some great quotes from the book at www.wikiquote.org.

Some samples:

Every morning in Africa, a gazelle wakes up.
It knows it must run faster than the fastest lion or it will be killed.
Every morning a lion wakes up.
It knows it must outrun the slowest gazelle or it will starve to death.
It doesn’t matter whether you are a lion or a gazelle.
When the sun comes up, you better start running.
-African proverb

• In the pathbreaking 1989 essay, “Computer and Dynamo: the Modern Productivity Paradox in a Not-Too Distant Mirror,” the economic historian Paul A. David explained such a lag by pointing to a historical precedent. He noted that while the lightbulb was invented in 1879, it took several decades for electrification to kick in and have a big economic and productivity impact. Why? Because it was not enough just to install electric motors and scrap the old technology – steam engines. The whole way of doing manufacturing had to be reconfigured. In the case of electricity, David pointed out, the key breakthrough was in how buildings, and assembly lines, were designed and managed. Factories in the steam age tended to be heavy, costly multistory buildings designed to brace the weighty belts and other big transmission devices needed to drive steam-powered systems. Once small, powerful electric motors were introduced, everyone hoped for a quick productivity boost. It took time, though. To get all the savings, you needed to redesign enough buildings with small electric motors powering machines of all sizes. Only when there was a critical mass of experienced factory architects and electrical engineers and managers, who understood the complementarities among the production line, did electrification really deliver the productivity breakthrough in manufacturing, David wrote.

Bill Gates: 30 years ago, if you had a choice between being born a genius on the outskirts of Bombay or Shanghai or being born an average person in Poughkeepsie, you would take Poughkeepsie, because your chances of thriving and living a decent life there, even with average talent, were much greater. But as the world has gone flat, and so many people can plug and play from anywhere, natural talent has started to trump geography.

• America integrated a broken Europe and Japan into the global economy after World War II, with both Europe and Japan every year upgrading their manufacturing, knowledge, and service skills, often importing and sometimes stealing ideas and equipment from the US, just as America did from Britain in the late 1770s. Yet in the sixty years since World War II, our standard of living has increased every decade, and our unemployment rate – even with all the outcry about outsourcing – stands at only a little above 5 percent, roughly half that of the most developed countries in Western Europe.

• By automating these jobs, it enables companies to save money and free up talented brainpower from relatively mundane tasks to start new businesses in other areas. You should be afraid of free markets only if you believe that you will never need new medicines, new work flow software, new industries, new forms of entertainment, new coffeehouses.

• It takes a leap of faith, based on economics, to say there will be new things to do. But there always have been new jobs to do, and there is no fundamental reason to believe the future will be different. Some 150 years ago, 90 percent of American worked in agriculture and related fields. Today, it’s only 3 or 4 percent. What if the government had decided to protect and subsidize all those agricultural jobs and not embrace industrialization and then computerization? Would America as a whole really be better off today? Hardly.

• Well, here’s the truth that no one wanted to tell you: The world has been flattened. As a result of the triple convergence, global collaboration and competition – between individuals and individuals, companies and individuals, companies and companies, and companies and customers – have been made cheaper, easier, more friction-free, and more productive for more people from more corners of the earth than at any time in the history of the world.

• The sense that our kids have to be swaddled in cotton wool so that nothing bad or disappointing or stressful ever happens to them at school is, quite simply, a growing cancer on American society.

• In China today, Bill Gates is Britney Spears. In America today, Britney Spears is Britney Spears – and that is our problem.

• As exciting and as visible as the flat Indian high-tech sector is, have no illusions: It accounts for 0.2 percent of employment in India. Add those Indians involved in manufacturing for export, and you get a total of 2 percent of the employment in India.

• Immigrants are always hungry and they don’t have a backup plan. Young Chinese, Indians, and Poles are not racing us to the bottom. They are racing us to the top. They do not want to work for us; they don’t even want to be us. They want to dominate us.

• The best companies outsource to win, not to shrink. They outsource to innovate faster and more cheaply in order to grow larger, gain market share, and hire more and different specialists – not to save money by firing more people. (p. 360)

• The business organization consultant Michael Hummer once remarked, “One thing that tells me a company is in trouble is when they tell me how good they were in the past. Same with countries. You don’t want to forget your identity. I am glad you were great in the 14th century, but that was then and this is now. When memories exceed dreams, the end is near. The hallmark of a truly successful organization is the willingness to abandon what made it successful and start fresh.

• People don’t change when you tell them there is a better option. They change when they conclude that they have no other option.

• Louis Pasteur said it a long time ago: “Fortune favors the prepared mind.”



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

Wednesday, November 22, 2006

Companies that Need SOA the Most Are Least Likely to Implement It

My eyes were drawn today to an ITBusinessEdge post "Companies that Need SOA the Most Are Least Likely to Implement It". How could I resist that title? (That reminds me of a previous post of mine "Naming Well, an Essential Skill of an I/T Architect" but I degress.) That post in turn drove to yet another cleverly named post

Is SOA success in the genes? by ZDNet's Joe McKendrick -- Todd Biske recently responded to my post about Microsoft's recommended approach to SOA (inch by inch, it's a cinch; mile by mile, its a trial), and ponders whether some organizations can get SOA right away, but others will never get it. How do organizations end up with their IT out of synch with business [...]

The basic premise here is worth entertaining. Companies that already have good alignment of I/T and business, already have good governance in place, already think proactively and strategically about I/T, etc. will find moving to a Service Oriented Architecture just the next incremental step in their improvement process. For the other companies out there (the vast majority?), the gap between where they are today and SOA is an insurmountable chasm that they dare not even try to cross.

I think there is an element of truth. I've seen a lot of situations where a company could benefit from new approaches but because they organize a bunch of independently funded, tactical projects no one project can fund the leap to the next level of maturity and flexibility. (See also "The Scourge of the I/T Architect's Universe".) Just a couple of weeks ago an acquanitance of mine at a major manufacturer told me he was interested in using SOA software products for their EAI-like-middleware value but he didn't think his organization was ready to embrace SOA yet. I guess this is like "flying under the radar" to wait until the political situation is more receptive to SOA.

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.

Thursday, September 07, 2006

Living on the Bleeding Edge for Fun and Profit

"Let’s start by acknowledging that bleeding-edge has negative connotations for a lot of people. Just think for a minute about the imagery. Bleeding edge evokes danger. ....Engage in that battle, and you might survive, but you’ll get bloodied in the process. ....But my conversation with a couple of IT executives has me thinking about an alternative vision for the bleeding edge.....until you start messing around with new stuff, you can’t answer the question about whether it might provide a competitive advantage or suggest a new business model.....The implication here is that even a company that is uncomfortable adopting a new technology until someone else works out the bugs can’t really afford to wait to check it out. The bleeding-edge might be your competitive edge. And it starts to look smart, rather than dangerous."


Thursday, July 27, 2006

Leading a Software Project Like Directing a Movie?

A couple of weeks ago a co-worker passed me an article that really got me thinking about what it takes to lead a significant software development project. In Successful software management style: Steering and balance* Walker Royce, Vice President Rational Brand Services, makes an interesting argument that running a major software project is a creative act, more like directing a movie than what most of us think of when we think of project management.

I must admit his argument is seductive. I think that as an architect, I consider myself more of a “creative type” who makes something out of nothing. Often I don’t like being held to a plan I had no part in making. And when I help make a plan, I budget some time for some tinkering.

Maybe Walker Royce has a point. Here are some quotes:

“Managing software projects successfully has proven to be very failure prone when using the traditional engineering management discipline. Comparing the challenge of software management to that of producing a major motion picture exposes some interesting perspectives. Both management problems are concerned with developing a complex piece of integrated intellectual property with constraints that are predominantly economic. This article introduces some comparisons between managing a software production and managing a movie production, then elaborates four software management practices observed from successful projects. The overall recommendation is to use a steering leadership style rather than the detailed plan-and-track leadership style encouraged by conventional wisdom.”

""Heresy!" some may shout. "Software projects need more disciplined engineering management, not less." Before you dismiss my claim as an insult to the profession, consider these observations:

  • Most software professionals have no laws of physics, or properties of materials, to constrain their problems or solutions. They are bound only by human imagination, economic constraints, and platform performance once they get something executable. Some developers of embedded software are the obvious exception.
  • In a software project, you can change almost anything at any time: plans, people, funding, milestones, requirements, designs, tests. Requirements -- probably the most misused word in our industry -- rarely describe anything that is truly required. Nearly everything is negotiable. "

"Metrics and measures for software products have no atomic units. Economic performance more typical in service industries (value as observed by the users vs. cost of production) has proven to be the best measure of success. Most aspects of quality are very subjective, such as maintainability, reliability, and usability."

"Process rigor should be much like the force of gravity: the closer you are to a product release, the stronger the influence of process, tools, and instrumentation on the day-to-day activities of the workforce. The farther you are from a release date, the weaker the influence. This axiom seems to be completely missing, or at least grossly underemphasized, by the process evangelists and literature, but it is usually very observable in successful software projects."

"Most unsuccessful projects exhibit one of these characteristics:

  • Over-engineering on the early phases (creative aspects) of the life cycle. You need maneuverable processes that easily adapt to discovery and accommodate a degree of uncertainty to attack a few major risk items, prototype solutions, and build early and coarse artifacts. What creative discipline can you think of in which more process rigor is considered beneficial in helping humans think?
  • Under-engineering on the later phases (production aspects) of the life cycle. Extensive change-managed baselines of detailed and elaborate artifacts need engineering processes with insightful instrumentation and attention to detailed consistency and completeness to converge on a quality product."

On the flip side, there is the problem of “Can my customer culturally handle the kind of “give and take” in a creative software development process? Do they understand the idea of “discovery” of requirements or do they think they've identified them all already? Can customers really admit how little they know about what they want or how poorly they sometimes articulate their “requirements”. Can they accept trying out an idea, deciding it was all that good, and throwing the work away?

Another problem area is that for most of us is that we have to live within a budget which often must be cast in stone very, very early in the process before those requirements (negotiable as they may be) are really well understood. How many customers really work in an organization that allows them to “go back to the well” and ask for more money without commiting some kind of career suicide?

Then there is the recurring problem of technical orgainzations expecting to have their budget estimates cut so they pad their numbers. Business users then come to expect to routinely receive padded numbers and promptly cut the estimate by an even larger percentage. For a humorous look at this situation see Project Approval Games: Three Fantasies mentioned in a previous post Feudal Line Management and Shared Resources.

My gut tells me to accept a lot of Walker Royce’s ideas and bake them into a project plan that appears more traditional by adding a lot of tasks with formal sounding names that really mean “verify we really understand what they want”. My experience is that customers often articulate pretty well the “happy path” of what they want when everything works like they hope. They are not so good, however, at telling you how many things can go wrong and telling us what the software should do when an exception occurs and we are no longer on the “happy path”. It may be wise to add a few formal sounding task names that really mean “contingency for exception handling we don’t know about yet goes 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, July 05, 2006

Feudal Line Management and Shared Resources

There is often a fuzzy line in practice between the role of a project manager and an I/T architect. I say in practice because all too often it is not possible to be a “pure” I/T architect. We have to help the project manager be successful if we want to continue to have our fun creating new solutions to solve new problems.

I know, for example, that my project managers often rely on me for help setting up a viable project plan. How are they supposed to know which tasks in the technology mix are predecessors of others if the I/T Architect doesn’t tell him? And since all of my projects have at least some first-of-a-kind (with the client anyway) element to them, how would the project manager know what the tasks are in the first place.

Then there are the resource issues. If the first-of-a-kindness of the project involves some development tool or middleware that we haven’t used before then a good I/T Architect should help the project manager identify the skills required. I know once names are submitted, I often get involved in the interview and selection process as well.

One of my project manager friends and I were discussing a common project management problem – the resource that everybody needs for their project. In our case, we are anticipating that if our client adopts SAP then the already thin ranks of the programmers supporting the legacy systems will be in great demand. Who will provide the routine support if these people are in requirements discussions related to SAP? Who will create that urgently needed report if they are in a conference room trying to help the data migration team move the legacy transaction history over to SAP? What if the client’s business climate becomes more competitive and the business requires yet another tweak to the legacy system to support the latest marketing program? But there are all those SAP meetings to go to!

We came to the quick conclusion that the client could hire 20 or 50 or 100 SAP consultants (or another 250 in India) and not deliver a working SAP instance any faster because those few legacy subject matter experts (SMEs) could only attend just so many hours a day of meetings.

My project manager friend pointed me to a set of really wonderful project management “fables” which uses the feudal system of middle age Europe and the story of Robin Hood to illustrate the real-world, political problems faced by today’s project managers in a the resource constrained realm of shared resources. Check out Robin Hood PMs and Feudal Line Management by Dick Billows at 4pm.com. This article makes some great points and is amusing reading and all too true! A small sample of this gem:

“Sure, there were all those blasé assurances of “full support” from the line managers before the project started. Now that the work has begun, these feudal Sheriffs of Nottingham patrol their castle walls hurling stones and boiling oil on PMs who attempt to utilize one of their artisans.....’A person can have but one boss and that is I.’.... the sheriff notes the PM’s project work assignment on a scrap of paper but does not assign a specific individual from the castle to complete the task. ... They (the PM) don’t know who will be working on the assignment When the sheriff finally does allow work to start, the selected individual is usually not the most skilled artisan in the castle. Often, the sheriff picks an individual whose absence from the castle may actually improve the castle. .... The sheriff may recall them on a whim or to silence another whining Robin Hood. How does the borrowed person react to all this? It’s clear that the project assignments should not, in any way, interfere with the person’s accountabilities in the castle. It’s there after all, that the sheriff will decide on compensation, promotion and continuing employment. The PM has none of these rewards to dole out... With several borrowed people on the team, usually on critical path assignments, the project team takes on an excessively casual, holiday-like atmosphere. This is in stark counterpoint to the user or client King who views the project as a crusade and reminds the PM of its importance at annoying frequent intervals.”


Another gem from the same site, Project Approval Games: Three Fantasies where the fantasies are Executive Fantasy Land (too much confidence in the PM), the Used Car Lot (PM as “slick shyster” trying to rip the executive off), and The Eager Puppy Dog (which drives PMs to pad their project estimates with contingency and executives to assume there is extra fat which can be cut).

Read both and enjoy!


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.

Thursday, June 15, 2006

The Globalized I/T Architect

There was a lot of fanfare about the IBM "town hall" in Bangalore, India recently. My teammates in Bangalore all got to attend. Based on the Tuesday morning conference call comments, it was a big hit over there

Sam Palmisano, also had some interesting words in the Financial Times the other day. Basically he said the multi-national corporation is dead ... to be superceded by "the globally integrated enterprise." I have no way of knowing how much of this is truly original thought but I would point his comments out to readers.

All of this globalization has a huge impact on those of us who have to shepherd complex software projects along. The globally dispersed development model is alive and well. I suppose, however, that almost any big company that might move a lot of software work offshore has already done it. So now what happens? What does this mean for us as "high wage country" I/T architects? Here are a few thoughts:

  1. Whether we like it or not our job often become to ensure that the global model chosen by the bosses way above us is succesful. Project sabatoge to get them to change their mind is career suicide.
  2. Our job will be getting even more consultative. We will likely spend even a greater percentage of our time worrying about business requirements.
  3. Our "Soft Skills" become even more important as we spend more time writing, presenting, facilitating, persuading, planning, coordinating, selling our ideas, etc.
  4. We'll focus more and more on the things which must be done face-to-face with the business users, excutives, clients, etc. If you can do your job over a VPN from your home office, beware because the job could probably be done from the other side of the world.
  5. We'll write more documentation than ever before so as to enable the armies of offshore developers to be successful (see #1). More and more we will be successful when we achieve results thru others. (Almost sounds like management doesn't it?)
  6. The offshore teams' work will move "up the food chain" to become more and more strategic. See a URL I've pointed to before, IBM to invest $200 million in Global Business Solution Center. The technical lead for this effort, Ray Harishankar, was recently appointed an IBM Fellow, the highest level a technical person can achieve in IBM. There are only 62 of them today out of over 300,000 IBM employees.

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, December 12, 2005

Forget Business - I/T Alignment ?

I found an illuminating post on I/T Architecture that proposes a view about Enterprise Architecture which is counter to the prevailing “business – I/T alignment” winds. This post called “Why Enterprise Architects should eschew IT / Business alignment“ in James McGovern’s blog “Enterprise Architecture: Thought Leadership” advocates approaches which are no doubt heretical to some – but makes points that have worried me for some time.

Here are some provocative quotes to get your attention:

“The phrase, IT should align with the business is commonly heard in magazines such as CIO. I have blogged sporadically on the fact that this form of hype is actually detrimental to the health of the enterprise.”
“Enterprise Architects that embrace agile methods understand that there is a chaordic balance and attempting to make everything predictable is not only limiting the possibilities of greatness but in many situations futile. Predictability as a system quality is further championed by folks who don’t write working software for a living and instead focus in on comprehensive documentation. These folks encourage practices such as Six Sigma, Eight Omega, CMM and other efforts without focusing on the real problem space; lack of innovation.”Predictability causes mediocrity. Enterprises that desire to be predictable buy the same software as their competitors, are rare to implement technology within their vertical first and prefer to let other enterprises work out all the bugs. “
“I am firm in my own belief that the recent practice of vendor consolidation may be the decline of the IT enterprise as many within our profession have outsourced their architecture via Powerpoint to vendors whose sole competency is commoditizing solutions and promoting them to your competitors.”

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