Software Engineering Services Blog

5 Links for Developers and IT Pros 10/7/11

5 Links for Developers and IT Pros 6/24/11

5 for Friday: Scrum Software Development, SaaS, Open Innovation and More

Here are some links we found share-worthy this week. If there's something you found that you don't see here, share via the comments!

1. 8 Lessons from the First Scrum Team Given the ongoing interest in and widespread practice of the Scrum software development process, its easy to forget that there was a first Scrum team. Well, there was a first team and Joe Kinsella was on it. In this post, he looks back on his experiences and shares these lessons, most of which focus on the "people factor" when assembling Scrum teams (hiring continuous learners, encouraging communication, developing social bonds, etc.). Also, as variation on the "test driven development" theme, he emphasizes the value of the "continuous demo" of software under development.
2. SaaS Product Marketing—Upgrade and Upsell Strategy Any company that has made the switch from offering on-premise software to a SaaS model will tell you that this move brings with it numerous changes to the sales process. In this post, Joel York goes into great detail describing the best ways for these vendors to package their solutions to facilitate upgrade and upselling potential. The key, he says, is to think in terms of purchase scenarios that mirror customer need and thus allow you to lay the foundation for organic sales growth. 
3. Is the Saas Delivery Model Dying? On a related note, in this post the folks at Openview Venture Partners interrogate some findings by Bloomberg Businessweek Research that suggest a slowing of SaaS adoption. Faulty sales models and a failure to focus on customer success with each new engagement could account for this, they suggest. Or, as they also suggest, the data could just be wrong!
4. Another Form of Creative Thinking The concept of "open innovation," first introduced by Professor Henry Chesbrough of the Haas Business School, has gone through three distinct phases according to this Financial Times article [registration required]: companies incorporating the innovation of others into their design process; companies sharing innovative ideas that they themselves chose not to use; and the third phase in which companies develop business models around the open concept itself. There is an accompanying graphic mapping these phases that you can check out here. 
5. The Tnooz Alternative Travel Innovation Summit Awards Martin Collings penned this snarky rundown of the presentations by innovators at the recent PhoCusWright Travel Innovation Summit (Ness was a sponsor). My two favorite categories were "You Really Know Your Target Market"—awarded to Vacation Relation, a kind of travel dating service— and "I Was Expecting Nothing But Left With Something"— awarded to Off&Away and TripAlertz. The awards granted by Collings were not all particularly flattering, but his take on the event and its participants was refreshingly candid.

So, what did you come across this week?

Measuring Business Agility

Attendees will undoubtedly hear at our upcoming Executive Networking Event, "business agility" is the leading reason IT decision makers give for cloud adoption.

However, as I discussed a few weeks back, no technology can by itself make an organization more agile. Certainly, technology can be an enabling factor, but its adoption must be accompanied by an equally enabling organizational change if true business agility is to be attained.

One aspect of organizational change that we have consistently advocated involves improved engineering effectiveness. Of course, improving an engineering organization's effectiveness requires first that one define "effective" and then that one put appropriate measurements in place so that actual improvement can be demonstrated.

While it strikes me as intuitively obvious to assert that more effective engineering practices will necessarily make a business more agile, such an assertion inevitably raises a very important question: How does one actually measure business agility?

Here are a few ideas:

• Time to Market - This is one metric that Kamesh Pemmaraju suggested when I asked him this selfsame question recently. Showing improvement in this area would require establishing benchmarks that accurately determine both the starting point of product development as well as its end point (release 1.0? 1.1? etc.). It would also call for calculating the benefits of getting to market earlier, benefits that would naturally vary based on the competitive landscape, the maturity of the market, and other factors.
• Profit - Michael Hugos defined business agility as "the ability to consistently earn profits that are 2 – 4% higher than the market average" (he refers to this as "the agility dividend"). I agree that, to be meaningful, business agility should have an impact on profitability (not to mention revenue). I also agree with Hugos' distinction between "self-sustaining" agility (i.e., agility that pays for itself through increased efficiency and productivity) and the "self-consuming" sort (agility purchased solely via cost-cutting). However, I'm not convinced that comparisons to market averages are that useful. More importantly, I don't know that profitability is an appropriate measure of other aspects of business agility such as the ability to diversify product mix or, as mentioned above, speed time to market.
• Real Options - Agility should mean that you can do new things more quickly as well as adapt to changing market circumstances more efficiently. In order to measure this kind of agility, the focus needs to fall on something intangible: Real Options for Future Action. In other words, the true value of agility resides in what it allows you to do. The way to capture that, as detailed in this Oracle white paper, is to focus not only on things like cost of implementation and TCO but also on things like "cost of change."  For example, it may be less expensive to implement a particular hardware solution than to invest in a robust service oriented architecture. However, when change inevitably comes, it may be more expensive to modify the former solution than the latter. Thinking this way begins to allow you to place a value on the real options afforded by a particular solution. And if agility is about anything, it's about having options.

So, how would or do you measure business agility?

Five For Friday: Fresh Links on Mobile, Metrics, Agile and the Cloud

Here are some helpful links that we came across this week. What did you come across?

1. Hottest Jobs and Skills in Cloud, Mobile App Development - Meredith Levinsin from CIO.com also commented on the IBM Tech Trends Survey that I mentioned here last week. Aside from emphasizing that data center techs will need to expand their cloud knowledge if they want to stay employable, she also highlights the importance of mobile developers understanding user experience since mobile apps "are much more user driven than traditional enterprise software." How many developers nowadays make the connection between their coding activity and the user experience they are thereby creating?
2. How to Improve Your Innovation Metrics - Tim Kastelle over at the Innovation Leadership Network offers some broad but useful guidelines on developing metrics that will help you improve the effectiveness of innovation efforts. One key recommendation: Use multiple metrics. As he puts it, "There is no single number that will tell us everything we need to know to manage innovation."
3. Case Study: Rapid Iteration with Hardware - Eric Ries writes a lot about the "Lean Startup" methodology on his Lessons Learned blog. Usually he talks about how this method can be applied to software-centric startups but, in this post, he hands the reins over to Ronald Mannak who relates a fascinating tale of applying the methodology to hardware, in this case motion-sensitive toy drumsticks. Contrasting the lean approach to a waterfall approach, Ronald concludes, "I am convinced iterative design depends mostly on the mindset of the team and the company culture and less on the tools."
4. How to Realize the Full Potential of Agile Development - HP's Tracy DeDore lays out a very clear-sighted intro to Agile in this article that also provides guidelines for organizations to use when determining when or if a project is right for Agile. I appreciated her insistence that Agile is not "developer-centric" and that it's successful adoption calls for the methodology to be "applied at every stage of the application delivery process, not just development." I also appreciated her use of the term, "scrummerfall."
5. What the #@%# is cloud computing? - Eventually, we'll be all done with explaining what cloud computing is. In the meantime, the folks at VMware have gone to the trouble of effectively illustrating the cloud concept using a caveman and a piece of pizza:

5 for Friday: Intriguing Links from the Week of September 6, 2010

Here's what intrigued us this week:

1. Simplicity: A New Model - The ever-intriguing Jurgen Appelo is writing a book on "leading Agile developers and developing Agile leaders" which will include this savvy discussion of the distinction between things that are "complicated" (difficult to understand) and those that are "complex" (difficult to predict). He offers up a model for situating objects, projects, and systems in terms of their complexity and comprehensibility. One commenter said he had his whole team read this!
2. Innovation 1.0 Served Here - Sameer Patel writes at length about the importance of developing an "innovation culture" that places an emphasis on execution by avoiding a "top down" approach. "In practical terms this means getting the big brains hidden in the corners of your enterprise to contribute unique data points (validation, rebuttals, refinement, oversight) to remove risk and enrichen outcomes," as he puts it. Eric Norlin over at CloudAve sees in this a call to develop "feedback loops along the value chain" in order to support innovation execution.
3. 5 Things Large Enterprises Need to Know About SaaS - Workday CTO Stan Swete discusses the concerns that SaaS vendors need to be able to address when selling to organizations with multinational operations and over 5,000 employees. They are namely: Integration; Performance and Scalability; Local Data Processing and Privacy Regulations; Configurable Business Processing; and IT Involvement. His post concludes, "Large enterprises face a higher bar to making SaaS work. A SaaS provider that demonstrates it can clear that bar is one worth talking to."
4. Meet your next 'Net? Academics rethink the Internet's guts - Matthew Lasar at Ars Technica reviews some recent National Science Foundation grants focused on rearchitecting the Internet. Among the projects he discusses is one aimed at improving cloud security [surprise, surprise], one aimed at developing a mobile-centric network architecture, and one looking to replace the Internet Protocol's location-based system with a content-based Named Data Networking model. Put on your Futurist Hat!
5. Distinguish Yourself - Brief post from software engineer Dan Moran on avoiding commoditization of one's services. If all you bring to the table is a particular technical skill (knowing C++ is the example in the post), then you'll be reduced to competing on price. The key for individuals and organizations is demonstrating the ability to design, architect, collaborate, and, most of all, solve problems that can't be anticipated in advance. I would add that customers ultimately don't want the commodity; they want capabilities that will allow them to achieve business goals while providing sustainable competitive advantage (at least that's what I hope they want!).

So what intrigued you this week?

R&D in the Software Industry: What Has to Be Done "In-house"?

Five long years ago, Businessweek published an article entitled, "Outsourcing Innovation," which detailed the way that companies like Dell, Motorola, and Philips were turning to partners in Taiwan, China, and India for product design. (Interestingly, the article cites one "no name" company, HTC, as a significant up-and-coming player in this market. Today, of course, HTC is on the verge of "household name" status thanks to it's Android-based Incredible phone.)

While pointing out that many companies attempt to draw a line between functions they choose to outsource due to economic necessity and those they want to hang onto in order to allay investor fears or to maintain a brand image, the article also emphasizes, "...there's no question that the demarcation between mission-critical R&D and commodity work is sliding year by year."

The article concluded:

What is clear is that an army of in-house engineers no longer means a company can control its fate. Instead, the winners will be those most adept at marshaling the creativity and skills of workers around the world.

Flashforward to the present and we find organizations still wrestling with the issue of maintaining a competitive edge while simultaneously controlling costs via outsourcing of research, development, and design. Interestingly, they do not seem to be choosing to forego this kind of outsourcing altogether. Indeed, as results released by the NSF in May demonstrate some industries (the automative industry, specifically) actually spend 39% of their R&D dollars elsewhere.

As the Businessweek article suggested, firms in countries like China and India became more attractive as R&D partners not simply as a result of lower labor costs but also because these countries actually boast huge numbers of trained and experienced engineers. As time goes by, however, there is another reason that these geographies will play a greater and greater role in global innovation: "Innovation must be located near manufacturing because so much of innovation is learning from and improving manufacturing" (to use the paraphrased words of GE CEO Jeffrey Immelt).

As manufacturing has moved overseas, it has effectively drawn innovation with it. Similarly, as customer service migrates abroad, innovation which depends on ongoing customer insight follows suit. Finally, we see this dynamic at work in the software industry as the maintainance and sustenance of legacy software products, among other things, are handed over to offshore partners.

That is, those who are in the best position to innovate and develop new products (or newer, better versions of existing products) are those who are working with these products and their users on a daily basis. 

Thus, if products (software or otherwise) are being made and supported "out there," shouldn't R&D be happening "out there" as well? Will it really get done better in-house?

 

Image Source: jurvetson.

5 for Friday: Intriguing Links from the Week of August 23, 2010

Here's some food for thought for this Friday.

1. "Outsourcing: cloud is changing the rules" - ZDNet's Joe McKendrick also commented on Stephanie Overby's interview with A.T. Kearney's Arjun Sethi (which we highlighted last week) and pointed out something they missed: Companies from diverse industries that just happen to have large internal IT infastructures could, whether they want to call it that or not, become cloud providers.
2. Amadeus Sponsored Study on European OTAs - Amadeus teamed up with Hermes Management Consulting to look at European online travel agencies and what they could do to close the gap with their more successful US counterparts. Two recommendations: 1) Sell more non-air products (50% of US OTA revenue comes from this source) and 2) Improve the online shopping experience by providing more relevant content.
3. Thoughts on Oracle v. Google - (via Alex Handy) An exhaustive and highly technical look at the recent dust-up between these behemoths written by the very informed and intriguingly opinionated Charles Nutter (Java developer, open-source developer, and JRuby developer). Nutter asks and answers the main question thusly: "[D]oes the suit have merit? It depends if you consider baseless or over-general patents to have merit."
4. "Can the Indian IT industry lead in products as well?" - India controls almost two thirds of the global, off-shore IT services market. Could it accomplish the same feat in the products arena? This author says, "Yes!"
5. "IT Services: The new allure of onshore locales" - Article from McKinsey Quarterly on the move to diverse off-shore portfolios by seeking out talent in "second-tier cities in close-shore locales." Most interesting part of the post is a case study detailing how one global company approached the selection of off-shore and close-shore partners. [Free registration is required to read the entire article, though it can also be found here.]

What got you thinking this week?

Video: Zinnov's Vamsee Tirukkala on the Evolution of Software R&D

Our roving cameraman, Phil Marshall, caught up with Vamsee Tirukkala, Founder and Managing Principal at Zinnov, during Zinnov's recent Congruence2010 - The Fourth Dimension of Globalization conference in Bangalore. Phil asked him to comment on the changing role of software development centers in global R&D.

Vamsee points out that the emphasis has shifted from cost arbitrage -- though that still plays a role -- to "value add," where captive centers and vendor partners are actively contributing to revenue generation, customer service, and defining the vision for the next generation of software products.

On that last point, according to Vamsee, there is a growing interest in the ability for development centers to play a greater role in product innovation. As he puts it, "Innovation comes from engineers. When companies have 30-40%, in some cases, 60-70% of their engineering base sitting outside the developed market, you need to have them participate in innovation. Without their participation, you cannot innovate."

What do you think? Do Vamsee's views accurately describe what's happening now? Or are they more aspirational in nature?

Six Degrees of Modernization

by Glenn M. Gruber, AVP Travel Technologies, Ness Software Product Labs

(Note: This post originally appeared on Glenn's Software Industry Insights blog.)

The travel industry has been leveraging software for more than 60 years, starting with American Airlines’ installation of the first automated booking system in 1946 (hat tip to Stephen Joyce) and led the way for electronic commerce even as Gates, Jobs and Packard were playing with blocks. So what that really means is that there’s a lot of old code out there on old platforms.

And to a large extent, while these systems are still running, they cause their fair share of problems:

• High cost of operations: can’t take advantage of lower cost hardware or Cloud-computing
• Fragility and Inflexibility: the systems don’t allow for rapid feature enhancement or make integration with other systems challenging.
• Mortalityware: literally there are fewer people alive who know the old development languages and how these systems work. And it’s not a problem that gets better.

Now it’s kinda scary that a trillion dollar industry is so dependent on what many would consider to be outdated tech. And the movement of the industry towards a la carte pricing, a.k.a. ancillary revenues, is being blunted in part by the ability of the underlying software to merchandise and manage the distribution of these different offerings through multiple channels.

But modernization is a challenge that the industry has struggled with for years and while some systems have been moved to modern platforms, many more are still tied to the past. So what’s holding things back?

It’s not technology. Certainly a big part is an organization’s appetite to expend the resources to make the move. But I believe an underappreciated aspect is the psychology of taking on a modernization project. Many of the applications that we’re talking about have millions of lines of code that have built on top of each other like an archeological dig with one civilization built on top of another. So the task can seem daunting and lead to paralysis. Few want to undertake a full re-write which can feel like a Cecil B. DeMille film, costing millions of dollars and thousands of lives (or at least man-years).

So it’s good to have a framework with which to view your choices. A good model is my “Six Degrees of Modernization” which covers the main paths to modernize your application.

When dealing with a huge project as we’re discussing, the big bang approach of re-writing the code is often a recipe for disaster and porting really doesn’t buy you a lot. So an evolutionary approach can be of great help. An example of such a strategy is where you’d start by separating and Wrapping the different bits of functionality into a SOA harness. Now that you have the code broken into more manageable pieces you can start the process of Translate/Refactor or Replace piece by piece — with the dual benefit of shrinking the size of the problem to a more manageable level that will help create early “wins” for your team and momentum for the project, as well as delivering a more flexible, higher code quality platform.

But this is not something that everyone should try at home. This is not primarily a coding activity, although that’s a big part of it. More than anything this is an architectural challenge (even more so if you’re trying to transition from an on-premise to an On-Demand model). And it’s an area where Ness Software Product Labs Strategic Consulting team have helped many clients.

Glenn Gruber is AVP of Market Development for Travel Technologies at Ness. He can be contacted at: glenn.gruber@ness.com.