Last week I listened to an interesting podcast by Forrester analysts Mike Gualtieri and Jeffrey Hammond entitled Talent Matters: Why Application Development Cannot Be Industrialized.   At first I thought this could have been an anti-outsourcing discussion, but after listening and thinking about it, it’s really about a deeper understanding of the importance of having exceptional talent in your software engineering organization.  And it’s a concept that any technology-driven business – including travel technology companies, travel suppliers and travel distribution and intermediaries –  need to be thinking long and hard about.

The conversation can be boiled down pretty simply: application development and testing professionals are not a fungible asset.  Deep down (maybe we don’t have to go so deep), we all know this is true, yet every development project is estimated using the productivity of an “average” developer.  And worse yet, they refer to them as resources.  And according to Gualtieri and Hammond, this is where it all goes horribly wrong.  And they’re right.

It doesn’t matter what estimation method you use – Function Point Analysis, analogy-based techniques, parametric models  – these methods are used to estimate the man-months needed to complete the project.  But not all developers are the same.  There are rock-stars, low performers and everything in between.   So while an excellent guide, the accuracy of the estimates really depend on who are the members of the development team.

Art v. Science

In fact the best developers are ‘artists’ to borrow a phrase from Seth Godin’s latest book, “Linchpin”.  The boys from Forrester talk about attributes of the best developers: creative, passionate, disciplined.  But while artists may be the best developers, not all developers are artists. So as an industry, we have tried to put some more structure around the science of software development practices and to make software engineering a “profession”.  We have also leaned on methodologies and tools to enable average developers to deliver above average results.  It’s helped the industry move forward and develop great software.

The fallacy of the software factory

But the mistake that perhaps many firms make is to think that these methodologies and tools would turn their software development teams into software factories.  Nowhere has this approach towards trying to create software factories been more pronounced than in the IT outsourcing business.  That’s because under the traditional outsourcing model success (i.e. margins) is achieved by trying to break any task down into its most basic components so that those activities can be completed by the most junior and cheapest resources (there’s that word again).

This is not to say that methodologies, tools, reusable libraries are not valuable and don’t make software engineering teams more productive. But they’re not a cure-all for having good software engineers. Tools and methodologies are more like guiderails to reduce mistakes and help less-seasoned developers accomplish more advanced tasks, but don’t necessarily guarantee well written, high-performance software..   So I’m in general agreement with their point of view.  But I think it’s important to talk about software engineering maturity.

Software Product Engineering versus IT Application Development

Now let me shift the conversation slightly from a basic application development perspective (which Hammond and Gualtieri were focusing on) to a software product engineering perspective.  Let me start by saying that I believe that software product engineering is a different animal than developing IT applications.  Software products and platforms – whether sold directly to customers or simply provide the infrastructure to deliver your products or services to your customers – requires a complexity, a thoughtfulness, in development, nay architecture and design, that are not often found in applications designed for internal users.  And Forrester agrees. In fact they have written a report about how some companies whose businesses are technology driven, but don’t sell software per se, are starting to try to re-organize their software development organizations in the image of an ISVs R&D organization. Forrester calls these companies ‘product-centric’ and more and more travel companies of all stripes fit this description.

If you need a rule of thumb, think about who’s using the software in question: is it a customer – who may choose to switch to a competitor if they’re not happy with their experience or the performance of the app – or is it a app or other computing resource used by an employee whose only alternative is to find somewhere else to work? If it’s the former, you’re probably talking about an application that needs a more developed software product engineering approach.

Software product engineering activities differ from IT organizations because:

• They are more mature in software engineering practices when measured against maturity models like CMMi
• Adhere to formalized software engineering practices and use of common coding practices
• Recognize, appreciate, and adhere to release schedules
• Quality is of supreme importance.  Testing is important, but quality is designed in.
• QA teams use test planning, test strategy, as opposed to an ad-hoc approach to testing

I do want to avoid painting all IT organizations with too broad a brush. Some IT organizations are more mature than others and have put more investment into putting software engineering practices, focused on architecture and enforced adherence to coding standards across the organization.  However, it’s more likely that you’ll see that with teams whose code is tied closely to generating revenue or supporting the delivery of the company’s product or service to their customers.  They adopt a “product-centric” approach, as Forrester would say, to software development because they realize that bad software negatively impacts the company’s performance.

Talent Is Even More Important in Software Product Engineering Organizations

My firm, Ness Software Product Labs, is not the same as the big ITO firms. Our mission is to help extend and enhance the capabilities of software product engineering organizations – helping companies build and test software that drives revenues – rather than managing internal IT applications and infrastructure.  To accomplish that goal, Ness SPL believes that it requires a different philosophical approach from what you see from the large ITO firms. It informs the type of people we hire, the way we collaborate with our clients and the kinds of relationships and engagement models we employ.

But in the context of this subject, I want to focus on the talent issue again.  Software product engineering is not ITO.  Architecting, designing, building and testing products that are tied to revenue, that require high levels of performance, scalability and resiliency is not a task to be done by lowest-common-denominator individuals. We believe it requires highly talented individuals…artists with discipline.  We spend a lot of time developing best practices, solution accelerators, and identifying the best tools to use.  We spend at least as much time finding the right people and developing their talent and offer them challenges that most ITO firms can’t.  We don’t try to create a software factory, we try to create an environment where talented engineers can thrive.

And the crucible in which we do that work is not for the faint of heart.  We are part of the software engineering organizations of some of the leading technology firms on the planet: Amadeus the number one travel technology provider in the world; NAVTEQ, the leading mapping and location-based services platform, PayPal the leading alternative payments platform, OpenText a billion dollar Enterprise Content Management firm. And the list goes on.  Our approach and the talent that we hire is borne out by the clients who choose us to be a part of their R&D organization, not to run the plumbing.

A lot of stuff happened while I was OpenTravel’s 2010 Advisory Forum in Seattle this past week:

1. I’d be remiss if I didn’t start with the successful IPO of Amadeus (AMA.MC), the largest GDS and leader in global travel technology solutions…and Ness Software Product Labs’ signature client in the travel technology space.
2. Apple buys Siri.  It’s not just mobile-web search, Siri also has the ability to learn preferences and not just provide better results back, but help complete activities or business processes like making dinner reservations or booking a flight.  It should be interesting to see how the iPhone experience evolves as Siri deepens the integration with iPhone OS.
3. Salesforce.com and VMWare announce VMForce.  Looks like Salesforce finally admitted that APEX was holding back the Force.com Platform-as-a-Service business and partnered with VMWare to enable direct Java-based development on the rest of the Force.com infrastructure. Good analysis by Enterprise Irregulars Phil Wainwright, Bob Warfield and Brian Sommer.
4. 5 reasons iPhone v. Android isn’t Mac v. Windows. Well said.
5. Another Top 5 list.  This time it’s the untapped or under-exploited opportunities in travel.  Mobile payments, re-booking top the list, but read on to see what other opportunities lie in wait.
6. Steve Jobs’ official position on Apple v. Adobe Flash.  Nothing terribly new (or not already said by Daring Fireball’s John Gruber), but if it’s written by Steve…and he gives it almost 1700 words, you should at least read it.
7. Excellent analysis of what Apple’s announcement of iAds will mean.
8. Tech Crunch’s Michael Arrington announces that with the recent announcements at the f8 conference we’re officially in the ‘age of Facebook’.
9. Forrester’s JP Gownder offers an opinion on why consumers will pay more for products and uses the Mac as a shining example.  I only have two issues with the analysis.  First I think that Gownder mistakenly equates repeat purchase with brand loyalty.  But more importantly, the piece reads as if the three categories can have similar impact. As I’m in the middle of Steven Sinek’s “Start With Why”, I believe “self-selection” (as Gownder calls it) reason is by far the most influential. But if you read the book, self-selection has a lot to do with whether or not a company has a compelling “why”.
10. On top of the Amadeus IPO, two big mergers in the travel industry:  Hertz buys Dollar Thrifty and United and Continental Airlines are set to merge under the United moniker. And it increasingly looks like Google will buy ITA.  A lot of activity for sure.

Well I finally landed a new gig with Ness Technologies.  While still in the outsourced product development space it’s a bit of a different mission for me.

My task is to leverage the experience Ness has garnered in the travel technology space through it’s long-standing work with Amadeus, a leading travel global distribution system (GDS) provider based in Europe.  Essentially it’s a chance to build a business within a business almost completely on my own.  A heck of a challenge and one I’m looking forward to.  I’m ready to take the leap.

Used with permission from Eric Chan (maveric2003)

The fun will be in figuring out yet another new industry with the travel biz.  Already see that there is a lot of lingo to learn, new buyer titles and profiles and emerging market dynamics.  Should be fun.

The good news for me is that there seems to be a lot of potential to leverage topics and technologies that are already near and dear to me (Cloud, SaaS, SOA, social media).

And while I expect that a lot of the posts on the blog should start reflecting issues in the travel technology space, I will continue to put in my two cents — here, on Twitter and in my new role as contributor to eBizQ — on the goings on in the software business and impact of emerging technologies.  In fact, later today I’ll be heading to the Microsoft New England R&D Center for Cloud Camp Boston and hope to emerge with some insights and video to share.

In an earlier post about the hype around outcome-based outsourcing engagements, I talked about how it’s a great conversation starter, but doesn’t necessarily end up being the way that contracts eventually get written.  Not that it’s about bait-and-switch (although sometimes it is).  But it begs a question: how pervasive is outcome-based outsourcing?

Today I had an excellent, wide-ranging discussion with Forrester analyst Bill Martorelli about outcome-based outsourcing.  Bill is currently working on an upcoming research report about outcomes which he will be presenting at the Forrester Services and Sourcing Forum 2009 and we were comparing notes and I was looking for some feedback on the messaging I’ve developed for my company, Symphony Services.  We had a pretty big disparity in our estimates.  We were talking pretty broadly about the ITO and outsourced product development (OPD) markets, but I said that it’s probably less than 5% of total contracts, definitely less than 10 percent.  Bill thought that it was larger, perhaps twice that, but as we talked about what really counts as true outcome orientation versus simple output-based, fixed-time/fixed-price or SLA-supported contracts, he felt that my number probably wasn’t too bad.

But what this really highlights is that even some of the brightest minds in the business don’t have a good handle on how much of the outsourcing contracts are outcome-based.  What do you think is the right number, or do you think it’s just so much hype?