hin255 - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

SaaS technology still requires preparation

SaaS technology may be convenient for many reasons, but there are still some considerations enterprises need to remember. Expert Kurt Marko explains.

Remember the days when getting a new application was a mix of excitement and dread? Excitement at the prospect of powerful new features and a slick, updated interface; dread at the thought of grinding through a couple dozen configuration screens and shoveling CDs for half an hour, while waiting for all the files to copy. Browsers and Web apps ended most of the drudgery, and as they evolved into more sophisticated, legitimate replacements for enterprise applications, it allowed software as a service technology to be born. SaaS is the closest thing to "just add water" application convenience, but the adding water part can still be a chore for enterprises. However, don't cut corners on preparation or you'll risk opening up security holes or end up with frustrated users. In this article we'll examine the tasks IT still must perform before turning SaaS loose on the rest of the organization.

SaaS doesn't live on an island

For consumers, SaaS technology generally lives up to the promise of instant gratification; however, enterprise applications exist in a complex mélange of other applications, databases, directories, security policies and customized business processes. The result is an environment that defies out-of-the-box convenience and requires application owners and IT to do some post-purchase assembly before opening up SaaS applications to users. Failing these steps will eventually come back to haunt you in the form of duplicate user IDs, security holes, data access problems and help desk calls.

SaaS configuration pain points generally fall into three areas: application and interface customization, system integration, and security and compliance configuration.

Application and interface customization

Every nontrivial application offers some level of customization, but for the vast majority of consumers that aren't power users, this amounts to little more than personalizing the interface. Many enterprises like to standardize much of the personalization to insulate users from wasting time and often confusing tasks. SaaS customization falls in several areas:

  • Presentation layer: Covers the Web front-end interface including menu structure, optional tabs or sections that organizations like to standardize and prepopulate. It also includes more complex things like custom CSS, company images and logos, and custom JavaScript.
  • Data layer: Elements like standard metadata, tags and categories.
  • Database forms and fields: Database apps can be prepopulated with standard data labels, fields, search terms, even complex query statements.
  • Workflows: ERP, HR, finance and project management applications often support complex workflows for things like approvals, notifications and task submission that must be defined and configured to suit specific business processes and workgroups.

System integration

Enterprise applications don't live in isolation and frequently interact with other apps, enterprise and third-party data sources, and enterprise directories and security policies. Tying all these together requires both configuration and, sometimes, custom code. Typical tasks include: setting up access security, like usernames and passwords, access certifications; customizing APIs; writing database queries; and writing custom scripts both in the SaaS app and on connected services, such as an application or data source. Indeed, system integration is often more involved than mere customization and may require custom code.

Security, regulatory and governance compliance

Securing data and complying with a growing list of related laws and regulations is an increasingly serious and worrisome issue for multination organizations. By decoupling application usage from the underlying infrastructure, SaaS technology complicates the situation by reducing, if not outright eliminating control over data locality and device-level security. For consumers, this seems like a conceptual, but inconsequential concern, but for businesses that must comply with a myriad of data security and privacy regulations, it's anything but a theoretical problem.

For SaaS apps, security compliance spans several axes of control: access policy, authentication and authorization, locality, and data control and encryption. As mentioned, this requires first connecting the app to a corporate directory and then assigning users and groups various permissions and roles as access control lists. Indeed, one of the things that has given SaaS a bad rap with IT departments is the ease with which individual departments and workgroups can procure software and bypass central security policies by setting up separate user accounts directly in the SaaS application. It's a natural reaction to users frustrated by waiting for IT processes, but it ends up creating a host of problems including duplicate accounts and passwords, inconsistent user rights and lack of IT visibility into application activity and possible abuse -- e.g., unauthorized use by nonemployees or breach by hackers. Thus, shortchanging SaaS security and directory integration is both unwise and inefficient.

SaaS technology due diligence

Some SaaS setup pain is unavoidable; however, it can be mitigated through judicious product selection and automation. Start by addressing the following questions when evaluating SaaS apps:

  • How much configuration is typically necessary? What is required?
  • How easy is it to integrate with the enterprise directory? What, if any, federated identity and SSO standards -- SAML, O-Auth, OpenID -- and two-factor technologies -- FIDO, Google Authenticator, SecureID, Symantec VIP, SMS -- does it support?
  • Does the app support configuration templates that can bootstrap customization? If so, does it provide sample configurations? If not, why? Does the SaaS app offer so few customizations that there's little need for detailed configuration? Or are configuration choices narrow and self-explanatory to average users?
  • What configuration customization can be done via the standard app portal versus what requires programmatic customization via the API? How much of the configuration can be programmatically automated via command line interface or Rest API scripts?

Given such a vibrant SaaS market, there is plenty of competition within every application category. By choosing a product that's easy to customize, automate and integrate with existing systems, many of the SaaS technology pain points can be eliminated.

Next Steps

Update your developer skills; multi-SaaS integration is the new frontier

Moving to SaaS remains gradual

Thwarting risks presented by SaaS products

Dig Deeper on SaaS support and licensing