For the first time since the late 1990’s, our technology options are making heads spin and making purchasing decisions more complicated than ever. As stalwarts like Oracle, SAP, and Microsoft age into the molds of IBM, CA, and others, there are hundreds of next generation technologies that will present themselves as undeniable cogs in the quest for business transformation.

Buyer beware.

Business agility is the new standard in the global marketplace. Aligning with flexible, infrastructure-free technologies is critical for organizations to realize the vision of iterative process improvement, customer centric behavior, and constant innovation. Every CIO, CMO, and SVP of Sales that I meet is hungry for faster automation of core, customer facing tasks. The common goal for these leaders is attaining greater leverage from existing go-to-market resources - their people, their processes, their existing customers - with the end game of selling more. Inflexible technology will hold them back.

Let me put it another way: there are many next generation applications that are inflexible. Don’t get fooled into thinking that one version of the “cloud” is as good as the next. If anything, the incredible flexibility of applications, like salesforce.com, have lulled buyers into believing that all cloud applications are alike. Trust me, they are not. And when a company purchases and attempts to deploy an inflexible technology, their results are severely compromised and they end up feeling like an SAP implementation circa 1998. In other words, disaster!

So, what is the test for flexible technologies? How should your purchasing criteria be structured to ensure that your future applications can drive the constant innovation that your marketplace demands? Below is a list of five things to look for when making your decisions.

#1: Configurability

Make certain that 90% of your business requirements can be fulfilled through point and click configuration. Extensive custom programming that requires software development resources is the smoking gun behind inflexible applications.

#2: Automatic Upgrades

Through the power of multi-tenancy, true cloud applications allow for organizations to seamlessly upgrade at their own pace. IT departments never have to haggle through a major “upgrade.” Customers are never “forced” to upgrade because a prior release is being de-supported. Make sure automatic upgrades are written into your contract.

If a new release has new features, these features should be easily enabled by point and click configuration. And, make sure that prior “customizations” are carried forward to new releases without the need for new code.

#3: Customizations

Rule #1 above speaks to the importance of point-and-click configurability. However, no one vendor is ever going to provide this capability at 100%. Therefore, a flexible application must also provide an open set of APIs that allow for customizations with open software languages (Java, Ruby on Rails, etc.). Avoid proprietary languages as much as possible.

How do you verify the availability of open APIS? Easy. Ask for the documentation. Verify that customizations can be built WITHOUT the intervention of the vendor. Make sure that customizations are upwardly compatible (see above). Lastly, check to make sure that the APIs allow for the customization of the presentation layer (interface), as well as the back end data-model. 

In today’s mobile, facebook-oriented society, it is critical that the user interface is as customizable as the back-end. 

#4. Vendor Agnostic Professional Services

What’s the first hint that a technology is inflexible? The vendor requires the use of its own development services to make it work. Check to see if independent 3rd parties are capable of implementing the application that you are considering purchasing. Do a quick ‘Linkedin’ search to see if there is an ecosystem of consultants that make their living working with the application.

If your search comes up empty-handed, you can bet that the technology you are considering is inflexible. You can bet that the vendor has yet to invest in the flexibility needed for 3rd parties to be successful and, instead, is making code changes to the base product to accommodate customer needs. This approach does not scale and leaves customers in line for future features that rely on the bottleneck of the vendor’s development organization.

#5. On-time Go-Lives

A huge benefit of the Cloud is that it is “always-on.” It is “always live.” And the onus on launching a cloud application generally rests on the migration of data and the training and change management required by the users. Therefore, a large majority of cloud projects are launched on-time and on-budget, which is a huge departure from software deployments of yesteryear. That is not to say that cloud projects guarantee success. Requirements can be poorly gathered, executive support can be lacking, and the goals of a project can be misaligned. However, the actual “go-live” is almost always a no-brainer.

Check to make sure that this is the case with your vendor. Reference checks that indicate projects were late or over budget reveal symptoms of inflexible technology, and that the vendor is not truly leveraging the power of cloud architectures that are designed to be open, flexible, and “always-on.”

Enage with me on Twitter @ericberridge.