I'm working with a few mainstream enterprise application companies that are going though the painful process of SaaS-enabling their applications. What's important to enterprise customers is that they understand this pain. It's not a matter of remarketing and hosting these apps. It's much more involved and complex than many assume it to be.

David Linthicum, Contributor

January 23, 2007

4 Min Read

I'm working with a few mainstream enterprise application companies that have seen the writing on the wall and are looking to SaaS-enable their applications. However, moving to the platform of the Web is much harder than it appears, as they are finding out.

What's important to enterprise customers is that they understand this pain, even though they may not be going through it directly. It's not a matter of remarketing and hosting that will get their current enterprise application vendors to SaaS. It's much more involved and complex than the application vendors, and customer, assume it to be. That's important to recognize whether you're a vendor or an end user.Indeed, the Web as a platform has its own set of challenges, including different security models, interface issues, and the granddaddy of all of the SaaS challenges: Multi-tenancy.

Security is what you would expect. A SaaS-enabled application has to be provisioned to those who are authorized to use it, at specific levels. Role-based security is best here, including the ability to turn on or turn off modules, based on who users are and how they subscribe to the SaaS. Moreover and most important is access to information. In the world of SaaS, the physical information storage exists in large databases, and is segmented by organizations and further segmented by roles and specific users.

Vendors should consider (and customers look for) single sign on, capabilities to authorize the users to multiple computing resources without having to log on many times. This is particularly important with more complex SaaS systems that also include third-party add-ins, such as background checking SaaS applications and reporting SaaS applications.

Interface issues are the next big nut to crack. While the path of least resistance for vendors is to simply replicate a current user interface as Web forms, the success of a SaaS application is really more dependent on the ability to support interfaces with the following "s" words: sexy, simple, and speedy.

• Sexy, meaning that the interface is both interesting and creative in how the application behaves, and also leveraging the platform of the Web whenever possible. For example, when displaying customer information, why not a link to their Duns report, or perhaps see if they are listed in Linkedin or Plaxo. Also, look for state-of-the-art interface technologies such as the emerging rich internet applications (RIA) standards including Ajax.

• Simple means that the interface is easy to use. I tell vendors to write interfaces for 6th graders; this approach pretty much hits the target for usability. SaaS players often make the interface much too complex and busy, which translates into training and productivity challenges for end users.

• Speedy means that the interface processing occurs at something approaching native interface speeds. If the hour glass is always up, productivity is always down. This goes to performance engineering with back-end servers, including multiplexing transactions across a server farm that may be distributed all over the world and use of cached data and high-end servers with large network pipes.

The three "s"s above are significant, but the most challenging change when SaaS-enabling an enterprise application is supporting multi-tenancy. A multi-tenant environment starts at the data, meaning that vendors need to architect, or in this case re-architect, data management to serve many organizations. This means partitioning the physical database to support this logical structure, and allocating space as new customers subscribe. Moreover, any extensions to the database or changes to core logic that organization may need to apply need to be tracked here as well.

The primary challenge with multi-tenant architecture is that the database is typically the heart of any enterprise application, and changing the database architecture means changing the core application. Thus, the significant work is done here, and the application will have to undergo some gutting unless multi-tenancy was considered in the original architecture. In most cases it was not.

Application integration and service oriented architecture expert David Linthicum heads the product development, implementation and strategy consulting firm The Linthicum Group.I'm working with a few mainstream enterprise application companies that are going though the painful process of SaaS-enabling their applications. What's important to enterprise customers is that they understand this pain. It's not a matter of remarketing and hosting these apps. It's much more involved and complex than many assume it to be.

About the Author(s)

David Linthicum

Contributor

David S. Linthicum is senior vice president of Cloud Technology Partners and an expert in complex distributed systems, including cloud computing, data integration, service oriented architecture (SOA), and big data systems. He has written more than 13 books on computing and has more than 3,000 published articles, as well as radio and TV appearances as a computing expert. In addition, David is a frequent keynote presenter at industry conferences, with over 500 presentations given in the last 20 years.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights