The Right Tools for the Job
Are today’s SaaS enablement technologies robust enough to support business to business SaaS? It’s a question I ask myself everytime I am introduced to a new ‘mashup engine’ or ‘online SaaS IDE’. Granted, there are some very impressive products out there right now, Bungee Labs’ BungeeConnect and CogHead for example. But initial impressions aside – are these whole product enablement environments robust enough to support extremely high levels of customization? Multi-tiered integration? Legacy integration? Complex computation and data types, and the myriad other requirements of the world’s most powerful business software? Even Salesforce’s proprietary Apex language born from Java seems a bit limiting in terms of programming expressiveness. Or so I’ve heard.
CogHead made a statement in their early advertising that has stuck with me for awhile now – they said [paraphrasing] that “CogHead wasn’t designed for computational fluid dynamics calculations”, instead spotlighting ease of use for the business individual. The idea: an environment to quickly build business process applications, and it’s so easy that anybody in your business can do it.
The problem I have is not with the ingenuity or inventiveness of these types of environments. I think there is a ton of very cool, and applicable, things that can be done with them. But I feel they alienate one crowd that, well, we owe pretty much everything to – software developers and engineers. Those that have been schooled and trained in the complex sciences of computer programming and application engineering. Believe it or not, but these folks are masters of an art – because there is a significant amount of expressiveness that goes into architecting an application, writing code, and optimizing it. Furthermore, business to business SaaS includes applications and services that fundamentally require a powerful computational platform and languages expressive enough to harness the power of that platform. I spoke with a vendor the other day who is looking for the right tools to develop an online service that provides genomic computation. Yes, that’s right – genome sequencing for researchers, on demand.
Some of the feedback I’ve read and heard from developers who’ve gotten their hands on languages such as Apex leads me to believe that developers’ hands are tied – even if they stretched the technology to its limits there’d be so much more they’d want to do with it that it’s almost not worth their time. They’ve spent years honing skills in the .NET languages, in Java, PHP, Ruby, in name your favorite programming language – and now they’re being handed Javascript-based online IDEs and proprietary languages and told to deliver enterprise SaaS applications. They’re being told by managers to port existing client\server code to an on-demand architecture using tools that simply don’t match up.
The tools exist, and developers have been using them for years. They’re experts. Perhaps SaaS enablers should focus on bringing the existing developer toolbet to the SaaS world, instead of enabling the rest of the business world around them with brand-spanking new tools that limit and eventually alienate developers. Frankly, I think the novelty of so-easy-your-manager-could-do-it development tools will eventually wear off and the business world will turn back to developers looking for programmatic magic. But, that’s a whole other post for another time.
The point is, handing an enterprise software developer some of these enablement tools and asking for a business-to-business SaaS application is like handing Mario Batali an EasyBake™ oven and asking for a six-course Italian dinner. No matter the amount of genius and talent involved, there’s only so much you can do with a 100-watt lightbulb.
read more
Related Posts
Tags
Share This
