Major news in the travel industry with Google-ITA going through and a pair of big announcements by Expedia, Facebook takes infrastructure open source and more:

1. Google’s plan to buy ITA Software cleared the DOJ on Friday.  While this wasn’t unexpected, it certainly was not the way that many in the industry wanted to kick off their weekend.
2. Expedia and American Airlines kiss and make up, bringing AA fares back to Expedia and Hotwire sites.  For now Expedia will continue to use the existing GDS connection to get fare data and availability, but the statement does indicate that in the future Expedia will use some fashion of American’s direct connect technology through a GDS, although the exact implementation is left unsaid.  Tnooz’ Dennis Schall wonders whether the OTAs that are not owned by GDS will enjoy a competitive advantage
3. In perhaps bigger news, Expedia announced that it’s going to spin out TripAdvisor as a separate public company.  It will be interesting to see how this affects the stock price for Expedia and how the street evaluates the relative value of the businesses going forward.  All this comes on the heels of Expedia’s JV in APAC and softening of their stance on direct connect with their recent rapprochement with American Airlines. Many changes in a short period of time signals either genius strategy or panic. I guess we’ll see which in time.
4. PE firm Apax Partners spent well over a $1B to buy two mid-cap ERP firms Epicor and Activant. The combined entity – which is effectively a roll up of roll ups –  will have revenues of about $876M.
5. Google has been outspoken in their belief the current patent system needs reform and is fighting a number of patent infringement lawsuits in which they’re the defendant, most notably with Oracle over the potential improper use of Java in the Android OS. So naturally they bid $900M to buy the vast patent portfolio of Nortel. It has been suggested that perhaps this is being done as a deterrent to current and future plaintiffs – “if you sue me, I’ll sue you”. Even with “Emperor Palpatine” stepping down, the whole “don’t be evil” thing still doesn’t seem to be in vogue anymore.
6. Cisco cloud security guru Christopher Hoff is never one to pull punches (must be the jui jitsu) and holds to form, calling BS on cloud-bursting as a de jure hybrid cloud strategy.
7. Facebook announces the Open Compute Project, releasing their data center hardware stack as open source to any and all comers which should help many companies enhance the efficiency of their infrastructure operations. This is a big move as many would consider datacenter strategy a distinct competitive advantage. Combine this with Rackspace’s OpenStack cloud platform (Rackspace is also a member of the Open Compute initiative) and I think we may see some interesting developments in the future.
8. This is getting idiotic. Living Social raises another $400M on top of the $200M they already raised – for a business that has zero barriers to entry and may be ultimately harmful to the companies who offer the deals through the service. Maybe Mike Fauscette is right and we are in a new bubble.
9. In what may look like the marriage of two industry dinosaurs hoping to survive the Ice Age, Texas Instruments announced it will acquire National Semiconductor for $6.5 billion which is a 77% premium National’s market cap. It seems that the rationale for the deal is bolstering manufacturing efficiency, but not much was said about innovation, which may be telling on its own.
10. Has Facebook peaked as an e-Commerce platform? Forrester’s Sucharita Mulpuru thinks so. Well at least maybe this will put an end to made up terms like f-Commerce.

Today Forrester’s Henry Hartevledt, everyone’s favorite travel analyst appeared on Fox Business to talk about the dispute between American Airlines and Orbitz.  It doesn’t look like Henry thinks this will turn out well for AA.

A few nuggets from the video:

• Orbitz delivers $800M in sales for American each year. That’s a lot of money for American, yet only represents 5% of Orbitz’s business. Harteveldt believes American will feel some pain in the short term.
• While American makes an economic case as a primary driver for their decision to pull flights from Orbitz, Henry states that Orbitz is actually one of American’s cheapest third-party distributors.
• When asked whether American can pull off  a direct model like Southwest: “Unlike Southwest, American is not really a distinctive airline…American doesn’t have any leading performance statistics such as on-time or anything to make people seek them out.  I don’t think American will be successful in replicating Southwest’s direct distribution approach”
• Forrester research shows that half the people who shop on a travel agency site actually purchase their tickets on the airline’s own site.
• Travelport’s chance at an IPO are “scuttled, at least for the short term.”

Following my last post, I wanted to look at each of Forrester’s recommendations and add a little color commentary where I thought that they either don’t go far enough or have some gaps that you should not overlook.

• Improvement No. 1: Define Quality To Match Your Needs. When you read the headline, it sounds great. But unfortunately, it’s framed in the context that it’s not possible to deliver perfect quality, so try to focus on delivering good enough quality. I don’t disagree with the premise – Zero Defects is a myth. Even 5-nine’s quality delivers some real horrific stats when applied to things like plane crashes and survival rates of open heart surgery. Now software is never a life-or-death situation, but it’s important that when you define “good enough” that the metrics you define are tied back to the impacts on the business. How do the technical/operational metrics impact application performance, revenues, customer attrition, support costs. If you frame “good enough” within this context…and have measurable metrics…and the ability to measure accurately enough (think about building something that requires tolerances of millimeters, but all you have is a yardstick)…you’re in a good place. But in my mind we see too many products rushed to market (Google is a prime culprit) that just aren’t ready. There’s a mindset that it’s OK to ship beta-level products to your customers as a general release that I don’t believe is healthy.
• Improvement No. 2: Broadcast Simple Quality Metrics. I believe this is directionally right, but only half the story.  On one hand this speaks to the maturity of one’s engineering processes. If you have no metrics at all, you likely don’t have much of a process and almost no chance to improve it as you can’t tell whether any changes you make help or hinder the effectiveness of your software engineering team. This is an area where Ness SPL’s strategic consulting practice has helped clients install proper metrics programs. But the other piece where simple metrics fall short is that it implies that you’re looking at your own team’s performance in a vacuum. You should also try to measure yourself against other peers so that you can identify where you have the greatest opportunity for improvement and therefore where to focus the efforts of your SLDC process re-engineering efforts.
• Improvement No. 3: Fine-Tune Team And Individual Goals To Include Quality. Absolutely agree. If you don’t measure your people on the quality of software they deliver, it won’t happen. And importantly, these measures aren’t just for the testing team, but the entire R&D organization.
• Improvement No. 4: Get The Requirements Right. I’d say this is a bit of a “Duh” statement if it wasn’t for the number of times that companies don’t get the requirements right. In a Capers Jones study “Software Quality In 2010: A Survey Of The State Of The Art”, defects injected at the requirements stage are the number one source of delivered defects, the hardest to prevent and the most costly to repair.

• Improvement No. 5: Test Smarter To Test Less. There are a number of methodologies to try to optimize the effectiveness of your testing regime based on risk.  I want to amplify one of the suggestions that Forrester made because I didn’t think it came through clear enough, but feel is a very important point: focus your testing on sections with high rate of code change.  If the code didn’t change, it’s highly unlikely the test results will.
• Improvement No. 6: Design Applications To Lessen Bug Risk. If you look at Six Sigma dogma, Dr. Deming’s third principle is “Cease dependence on inspection to achieve quality.” The object is to design quality into the product from the outset. Again looking at the Capers-Jones study, defects injected at the Design phase are the most severe and pervasive. Forrester states: “Architectural complexity, spaghetti coding techniques, and poor design all increase the likelihood that your application will contain bugs. Mitigate that likelihood with better design principles such as separation of concerns, frameworks, and design patterns to reduce design complexity and the likelihood of bugs in your code.”  ‘Nuff said.
• Improvement No. 7: Optimize The Use Of Testing Tools. Another area of full throated support except for one thing: tools alone don’t do very much. You need the expertise to know how to get the value of the tool and create a sustainable benefit. I am a big fan of test automation, but as I’ve written before, the line you draw between desiring a test automation program and an actual well run, sustainable test automation program, is not always straight.

Are you following any of Forrester’s “7 Steps”? Please provide share your thoughts and reactions in the comments.

Forrester’s Lisa Visitacion and Mike Gualtieri wrote an interesting report a few months back entitled “Seven Pragmatic Practices To Improve Software Quality” (subscription required). The crux of the report is that development teams are constantly and consistently under pressure to deliver software faster and therefore don’t have the time to implement a true best-in-class quality program. So in lieu of making fundamental changes to your teams’ existing processes, they suggest seven changes that can help you ensure that your software is good enough.

The report provoked a few thoughts from me, which I’ll break into two posts.

First, while each of the recommendations is individually valid, they are also sort of a cop out. I worry anytime I see the word “shortcuts” in a document.   You need to know whether the short cut is saving time and effort (good shortcut) or, to use a construction analogy, is akin to using baling wire and duct tape in structurally important areas (bad short-cut).

Now I do not believe that Forrester is arguing against using fundamentally sound software engineering and testing practices. They are merely trying to provide helpful guidance to make incremental enhancements to existing processes, acknowledging that we don’t live in a perfect world where R&D organizations have the luxury of all the time and resources they want to release perfect products. But, going back to my construction analogy, I think it’s important to know whether you’re adding these improvements to a strong foundation or a house of cards.

One might think that adherence to good software engineering principles is de jure in the technology companies we buy software from. But as a company that works with leading technology companies R&D organizations on product development initiatives, not only in the travel space, but also in the ERP, CRM, BI, Storage and Life Sciences space, I can tell you there is wide variability in the maturity of their engineering processes (in a CMMI-style context). One company’s process is not necessarily better than another’s, they’re just different.

It’s also important to realize that the level a company’s software engineering practices is not as much a reflection of the team’s skill or knowledge, but often a by-product of their collective experience. It’s just human nature – more often than not, you do things as you’ve seen them done before, especially if you’ve achieved successful outcomes in the past. But that does not necessarily make those practices best in class.

Having worked with such a wide community of technology leaders, Ness Software Product Labs has developed best practices around architecture, development and testing and helped our clients improve the effectiveness and efficiency of their software engineering teams and define effective metrics and measures to track their progress.

So while Forrester’s recommendations are good tweaks, they don’t replace the need for a thorough and rational review of your software engineering practices which can measurably and materially enhance the performance of your software engineering organization.

I understand that pushing change through an organization is hard and cannot be implemented overnight, but it’s important that when you undertake any change – major or minor – you understand the projected impact of those changes, and measure them to know whether those expectations are being met.  Will modest enhancements to your process achieve the objectives of the business? If so, great. If not, then you’re wasting energy and need to re-evaluate whether you have to embrace more significant changes, no matter the short-term pain.

In part 2 of the post, I’ll look at each of the “7 Steps” and add a little commentary.

Foursquare outages, a hotelier emerges from bankruptcy, Facebook groups, executive changes and more:

1. Altimeter Group’s Ray Wang describes the 5 pillars of consumer tech that are influencing enterprise applications and their impact on innovation. Amongst the examples given was the Royal Caribbean CIO’s recent presentation at InformationWeek 500 CIO event highlighting how design thinking coupled with real-time analytics and on-board mobility could improve the cruise experience on the largest ship ever built.  So no doubt there are lessons to be learned for travel companies.
2. It’s been assumed that location-based services will be a critical strategy component for the travel industry…but only as long as services like Foursquare are actually working.  On Tuesday, Foursquare had an 11-hour outage. And while everyone thought they were out of the woods, they’re down again on Wednesday.  Now who was it that said architecture matters?  That’s right…me.
3. American Airlines says it will compensate travel agents for the value they create. The question is what constitutes value. And will all travel agencies have the resources to implement the direct connect? Yes, there are platforms like Farelogix’s SPRK out there, and yes it’s free, but is it reasonable to request that travel agents add another technology platform to accommodate AA?
4. Excellent article by Xotels’ Patrick Landman in Tnooz who wonders whether the hotel industry is ready for the adoption dynamic pricing.
5. Facebook made a big announcement on changes to Groups and addresses data portability and privacy.  Forrester’s Augie Ray, breaks it down.
6. Homeaway buys Instant Software, makers of vacation rental management software. Seems like a reasonable vertical integration strategy. No terms disclosed at this time.
7. ExtendedStay emerges from a messy bankruptcy with familiar owners.  Just 3 years after selling it to Lightstone Group, Blackstone reacquires ExtendedStay for about a BILLION less than it made in profits from the sale in 2007. And on top it that, it got to shed about $5B in debt which will give Blackstone “the flexibility to improve its customer experience and offerings”, according to a spokesperson.
8. Dick Costolo takes over as CEO at Twitter for co-founder Evan Williams who unexpectedly stepped down to focus on product strategy
9. That’s not the only executive change. Tony Bates leaves Cisco to become the CEO of Skype and Padmasree Warrior takes on the role of SVP/GM of Cisco’s Enterprise, Commercial and Small Business Development Group in addition to being CTO.
10. And one more…Wyndham appoints Gareth Gaston as its new SVP E-Commerce.

The week was pretty much dominated by the launch of Facebook Places, but a few other things happened too…including a $7B acquisition by Intel that I only partially get as a lot of dollars must have gone for parts of Intuit’s business that’s far afield from Intel’s chip business. But who am I to judge. Anyway, here’s this week’s list:

1. I really liked this article on how to identify productive, creative types (hat tip to Forrester analyst Mike Gaultieri).
2. Yet another travel search contender with a quirky name and a unique twist on presentation of results – Hipmunk.  Ding-dong, the fare matrix is dead? Check ‘em out and decide for yourself.  Pretty ballsy to start up a company like this, just weeks after Google buys the leader in the space.
3. Excellent analysis and insight into the Oracle-Google patent fight from RoughlyDrafted. This is not the simplistic money-grab as one might think. So if Google has to pay royalties for Java, can they still give Android away for free?
4. It’s looking more and more like NFC is coming to the iPhone next year and other devices. I’m still not sold on the use case.
5. The opening weekend didn’t go so well for RIM’s Blackberry Torch? Should RIM start marketing the Torch as a “Limited Edition”?
6. The list of iPad-versaries continues to build. Up next: what I’m calling the “EvilPad” from Google and Verizon. The twist? It’s based on Google’s much anticipated Chrome OS, not Android. I wonder if Verizon will prioritize traffic for EvilPad users J
7. Facebook announces Places.  This is perhaps the most reported announcement of the week and there are a ton of articles about what it means, but the best was probably from Altimiter Group’s Charlene Li.  Much of the initial focus was on what this means for Foursquare or Gowalla (and perhaps how quickly they can sell themselves to Google, Apple or Microsoft), but others think that Yelp has the most to fear. From a travel perspective, you can find good insights from Tnooz and Troy Thompson at the Travel 2.0 blog.
8. Intel buys McAfee for $7.68 Billion…that’s with a “B”.  I can understand the need to add security directly onto the chip, but that’s a pretty penny to pay for it and so much of McAfee’s revenues seem off-task for Intel. It certainly can’t be that Intel felt they needed to augment their brand recognition. Maybe they just felt they needed the deal to remind people that they’re still here?
9. Travel rewards startup Topguest, which only went into beta a few weeks ago, is the first travel related company to integrate with Facebook Places.
10. Product quality is a big issue and there are a number of ways to improve it.  CIO Magazine’s Thomas Wallgum recaps 7 steps to improve software quality from Forrester’s latest report.

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.

Here’s your weekly reading list:

1. T2Impact’s Timothy O’Neill-Dunne tries to judge who’s right in the airline merchandising row.  Spoiler Alert: it ain’t the BTC.
2. American Airlines is trying to make GDSs, distribution channels to embrace XML in order to access ancillary services, which otherwise can’t be done prior to arrival at the airport.  However, American insists there will be no incremental costs to book via the direct connect channel.  GDSs probably don’t want to have to work through Farelogix, but also don’t want to modernize their feeds from EDIFACT to XML on a supplier-by-supplier basis.
3. Redmonk’s James Governor explains how VMWare isn’t getting into the relational database business, but that doesn’t mean they’re not in the database business.
4. First broken by BusinessWeek, it looks like Google is going to buy ITA Software for more than $1B, fully ushering in Google to the travel meta-search game (which they’re kind of in already with their recent integration of hotel results into Google Maps.  If this is true, it’s not good news for Kayak.com nor for Microsoft’s Bing Travel, the current leader in meta-search who also leverages ITA’s technology.  Good analysis on the rumor from Tnooz.
5. Altimeter Group’s Jeremiah Owyang breaks down the announcements from Facebook’s f8 conference.  Also check out Robert Scoble’s take on Facebook’s Ambition.
6. Does HTML 5 Herald The End Of RIA Plug-Ins? It’s behind the Forrester paywall, but I wanted to share it anyway.  It’s a pretty good analysis that separates the hype behind HTML5 from the reality that a lot of people have invested in RIA platforms and that HTML5 is still an emerging standard and therefore it will take a while to kill of RIA platforms like Flash.  However, the analysis doesn’t really take the rise of the mobile Internet.  I think it’s a pretty big miss and could act as a tipping point in favor of HTML5, but we’ll see.
7. HTC passes on Palm Buy. Not many options left. Lenovo? Motorola? Dell? My decision to by a Pre last summer is looking worse and worse.
8. Blippy offers a lame explanation of how credit card information ended up on Google. The “it’s less bad than it looks” line is the sort of non-apology apology that I have grown to expect and loath from companies and celebrities. What I’d like to know is whether Blippy went through PCI-DSS certification or if they even know what that is.
9. Apple tries to take over the travel industry next.  Great writeup by PatentlyApple.  But I’m not sure NFC will play as central as a role in reality as it does in the patent application.
10. 2 great posts by Don Dodge on what makes successful startups here and here.  Really nice to see him getting back to good content rather than shilling for Google.

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?