Back to the Future

by Robert Wenig, Founder and CTO —

Gas up the DeLorean, crank her up to 88.

Do you remember PowerBuilder, Visual Basic 1.0?

What about porting applications to/from Sun, Apollo, HP, Digital Equipment, MS-DOS, Windows and OS/2?

How about writing installation programs for all of the above, keeping track of a mish-mash of different versions—and of course dealing with a personal favorite, 'DLL Hell.'

As Bob Seger would say, ”Wish I didn't know now what I didn't know then.”

The Client-Server phenomenon started with a vengeance in the 1980's as the personal computer market grew at an exponential rate. The technology shifted in the early 90's from 2-tier client server (Client/DB) into n-tier (Client/Appserver/DB) with SAP's R3 success. With the rise of the internet, there was a huge shift away from 'installed applications' and a movement into thin-client (i.e. browser-based) applications—both for internal use (employees) and customers.

And here we are in 2010, about to head back into the Client Server fray.

By all indications, handheld mobile devices (iPhones, iPad, iPod Touches, Android, Blackberry and other smart phone devices) will eclipse the installed base of desktop computing devices within a couple years. Every person will be walking around with a highly portable computational device with network connectivity.

The fait accompli is watching people use their iPhones for email and transactional web applications when their laptops are within reach.

Obviously, the iPhone has different characteristics than desktop or laptop computers. The screen is smaller, the keyboard is virtual and the network connectivity is slower and intermittent.

While all of the mobile devices are moving very aggressively to support full web browsing, there are now hundreds of thousands of ”Native Applications” (just call them Fat Apps) available on these devices. With Fat Apps you need to install the application.

Fat Apps can:

• Provide an improved experience for the end user. With limited real-estate (i.e. small screen), why take up space with a nav bar or a back button when you can just build the app?
• Operate outside of the browser sandbox:
  • Access local storage, i.e. local Oracle or Sybase database on the device.
  • Access device sensors (camera/scanner, GPS, telephone, contact database)
  • Operate without network connectivity -- i.e. offline

As long as we're back in the 80's, can you remember when Jackson Browne opined:

”They say it will kill you, but they don't say when”

Have we completely forgotten the perils of client/server?

• Support a multitude of devices with different operating systems and characteristics
• Development, testing and support of:
  • iPhone, iPad, iPod
  • Android
  • Blackberry
  • Symbian
  • Windows Phone

It's not just the 31 flavors of mobile devices. Within the blackberry line alone there are dozens of different devices and permutations.

How can you possibly keep up and support and sustain this?

Then you have the next set of issues:

• Supporting each and every user with a distinct environment
• Versioning software
• Potential for conflicts with other software already installed, shared code, etc.
• Resource constraints on device -- storage, memory
• And, of course, dealing with distributed applications running across multiple tiers

So why go to all the trouble? It really boils down to two words: competitive pressure. If you’re a bank and Wells Fargo has an iPhone app that allows remote deposit, you're at a competitive disadvantage unless you have one, too.

So, for now, it looks like “Fat is in” and the arms race is on.

What are your thoughts and plans?

And, by the way, I was always more enamored with the Ford Pantera than the Delorean.

Comments

[Greg Ogarrio]

Check this latest customer experience challenge: http://www.fastcompany.com/1690788/infographic-online-retailers-44-billion-customer-experience-problem