Growing Pains: Adding Web Services to Legacy Desktop Applications

James Vaughan

As a desktop application business, you decide to take a chance and jump onto the “Web” bandwagon. Sure, this whole Internet thing has been hyped for a decade, but maybe there’s something to it after all? Your first idea is to tackle that old workhorse called E-Mail. Pictures are only getting bigger and you just can’t seem to push those snapshots around to your friends and family anymore.

“What if you could upload them to the “Cloud” and mail just the link for viewing?”

“Great idea, and there are some really excellent web services that offer this already. Maybe we could just use one of them?”

“Nah, we could do it way better and I have a few more ideas. We know what our customers really need.”

Harvesting features like fruit

“What if we version these images as they’re uploaded, keeping track of older drafts and maintaining interesting metadata like photographer and comments?”

“Even better – *clickety, clack, test* – done! Shall we release?”

“No way – it’s not enough. Do we know who viewed which photo and when?

“Sure thing, we have that covered now. Can we ship it?”

“Hmmm, that’s pretty cool, but you know what would be even cooler? Why don’t we add team based roles and permissions and charge for disk space?”

Half a year later, the development team comes limping back with the requested “features”. And, suddenly, nobody thinks it’s very cool at all. It’s harder to use and awkwardly bolted to the desktop application at the hip. Unfortunately, all the good ideas implemented in the first months have long since spoiled, left forgotten at the bottom of the “Annual Release” basket.

But that’s not the only bad news – you’ve just lost another 6 months ground to your competitors in the heated online services space.

Development at the speed of thought

A lot of companies think “online” is easy. These are the same people that think agile and scrum are easy too. Organizations structured as silos make this even harder, as entire departments are made “responsible” (for marketing, sales, QA, development) for the end product. These departments, in turn, are made up of several teams each pulling in their own direction with their own agendas and vision of “the perfect world”. This complicated network of hundreds of people (maybe even spanning multiple continents) is then given 12 months to deliver a useful, coherent (dare I say delightful?) application to end customers.

To the above scenario, add a web development team. 12 months in internet time is a blur of ever more compelling and competitive technologies. Nimble start-ups burst upon the scene with world changing ideas. Most of these fizz out in a month, but a few catch fire and go on to become successful businesses. The web literally moves at the speed of human thought.

If your web developers are doing their job, they are inundated with a daily flow of online change. Everything from new security attack vectors to incredibly useful toolkits and APIs are being released and changed everyday. They incorporate these developments into their applications – sometimes emergency releases need to be rolled out ASAP to prevent data and identity theft.

Aligning this kind of agility to the typical desktop application release cycle is extremely painful – not only are you responsible for proper functioning of the website, but if the next update of your users’ workstation product isn’t scheduled for 3 months, you have to hack your webservices in such a way that customers are protected and the everything continues to “just work”.

Growing pains like this will only become more apparent as companies realize the huge potential of online webservices. A lot of companies have decided to skip the the hassle of integrating webservices to their desktop apps entirely, breaking ground on new application development in the mobile & tablet markets. How has your company dealt with such challenges?