For a time, I hosted the Portland Software Development Roundtable. For a few of these sessions, I took notes and published them here.

The materials that follow are very rough outlines of our discussions: you won't find polished articles here. These outlines don't necessarily reflect my point of view or the point of view of all of the attendees.

Much has been written about the commoditization of IT, but I have not read much about the commoditization of IT services specifically. As one who makes his living providing IT (consulting) services, this is a topic of interest for me. It is my observation that IT services are not immune to the ever-rising tide of commoditization. I believe many classes of IT services have already become commodity. For the purpose of discussion, a simple definition of commodity services would include low cost and abundant availability as identifying traits.

We have all been witness to the impact of globalization on the domestic IT industry, which begs the question: Is software development becoming a commodity service? If so, what must software developers in Portland OR do to adapt to, and survive this phenomenon?

One idea that comes to mind borrows from the experience of the computer hardware industry, and relates to aggregation concepts. If one can combine commodity components to create a new product that is both useful and affordable (i.e. high-value) then commoditization becomes an enabling force, an opportunity, if you will, to provide something that was not feasible to provide before. Using this analogy, how might this concept of commodity aggregation apply to IT services?

The link below is an essay by Nicholas Carr that addresses the subject of commoditization of IT, but more from the commercial software and hardware perspective. You may remember Mr. Carr from the piece that he wrote last year about how IT doesn't matter. The article was widely published and much debated. While not directly related to my question about IT services, it does address the issue commoditization in broader terms.

http://www.wired.com/wired/archive/12.05/view.html?pg=2

Attendees:

• Rodney Bell
• Vivien Chung
• Ron Ellis Gaut
• Karen King
• Brian Knowles
• Diana Larsen
• Kieth Lofstrom
• Jeff Olfert
• Jim Shore
• Jim Tyhurst
• Dave Woldrich

Notes from our discussion:

• Competing on price doesn't mean you have a commodity
• If you can't differentiate, you compete on price.
• Contract bid scenarios usually focus on price because it's difficult to differentiate.
• How do you demonstrate higher quality or cheaper maintenance costs?
• Track defect history, customer satisfaction
• Perhaps quality determination services is an underserved market
• Warranties
• What about developer metrics, like CMM and ISO 9000?
• These demonstrate repeatability, not success


• Compete on image
• Starbucks
• No, it's not image, it's consistency


• Leverage local presence
• Personal relationships
• "Our specialty is the local relationship."


• Focus on expertise: a success story
• Good combination of politics and developers
• 73% success rate
• Unusually successful, but can't advertise that we fail 27% of the time!
• Failures aren't due to development


• What about open source?
• That's commoditizing products, not services
• Cygnus, a company that sold the open-source GNU tools, was sold for $700 million. They were a services company.


• Services
• Combining the easy things into a unique service
• People want the packaged solution
• Boeing is "just" a systems integrator
• They work very closely with their suppliers
• Not anybody can do this: Boeing has decades of experience
• The point is that there's nothing wrong with being a systems integrator
• "I'm the guy standing behind this" (warranty)
• Differentiate by continuing the relationship after delivery
• Service contract
• Risk: a warranty can be used as a hammer against the customer: "we can't make changes; that would void the warranty


• Communicating project requirements
  • Story of offshore success: Complicated project, offshore team was the only one that did that successfully, and they were the only successful team.
  • Wait! I know about that project!
  • It was never deployed successfully
  • Deployment problems were due to onshore issues, not offshore team
  
  
• Offshore failure stories
• Wrong spec
• Not done on time


• Systems continue to evolve after "delivery"
• Offshore teams have a disadvantage here--not enough "bandwidth"
• When developers sit across from users, they can more successfully evolve the system over time
• Specs continuously change
• Change control boards (CCBs)
• CCBs exist to prevent change
• No, they exist to prevent frivolous change
• And ensure payment
• Scrum/XP
• Close customer relationship; customer is part of the dev team


• Commoditization is about specification and changing specification
• People don't know what they want
• They don't know the possibilities
• They know but they can't express it


• Software developers aren't a commodity; we need to dispell that belief.


• Design shop--provide a long-term service


• "Solutions center" message