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

Are SaaS ALM tools the right choice for mobile application design?

SaaS ALM for mobile apps has become a proven strategy that your company should consider when designing for Agile and cloud applications as well. Here’s why.

Three critical trends in application design are the cloud, mobile platforms and business agility. It's hardly surprising...

that these trends would combine in application lifecycle management, creating a cloud/SaaS model of ALM. Every developer and architect should consider SaaS-based ALM, but making the right choice demands a systematic approach. It is necessary to first determine if you're a SaaS ALM candidate. If you are, start by assessing your current application middleware and ALM strategies, then weighing the importance of all your application drivers, and finally picking the right approach and tools based on your needs.

SaaS is an ALM delivery model, not a functional classification. Most users should determine whether they're best served by SaaS-based ALM early on, and then make ALM tool selections. The primary questions to ask in SaaS delivery of ALM tools are what is the rate of change in the applications and the number of applications being managed? If you're a large shop with a lot of application changes, you may want to consider a traditionally hosted ALM approach. However, SaaS-based ALM can also be helpful in migrating to a new ALM strategy, so it's worth considering the issues below to see if SaaS ALM can help you adopt the best ALM strategy for mobile or Agile apps. You can always convert to an in-house option later.

Compatibility key to SaaS ALM

Compatibility is the first critical ALM issue. With mobile applications, it's important to look at the full scope of the application and not just at what you'd consider the "mobile part." Most mobile apps are based on a front-end/back-end model where application logic and data access are located in the back-end portion and the front-end provides the GUI. All of this is supported by a middleware model such as Java or .NET. For mobile applications, you may also have a backend as a service tool or another mobile app development tool designed to support multiple mobile platforms and BYOD. You'll want to be sure that your ALM strategy supports your application middleware commitments, and that you support your current ALM tools unless mobility has provided a compelling reason to reconsider.

If the source of application changes is dominantly functional, a business process to the back-end elements, or mobile-device-driven changes to the front-end, you might want to consider splitting the front-end and back-end elements into separate "applications" for ALM.  Because the pace of changes helps determine whether a SaaS model will be effective, this might open one or both application areas to SaaS ALM.

Considering SaaS ALM vendors

If you have a broader ALM-and-mobility issue to deal with, the next step is to ask three questions:

  • What's my current ALM commitment?
  • What's my dominant middleware?
  • Am I expecting any major development changes in the next several years?

If your dominant middleware vendor provides your current ALM and you contemplate no near-term changes, you probably should stay where you are.

Mismatches between ALM and middleware providers aren't uncommon, but they're getting harder to support, according to users. Most companies are best served by converging ALM on to a single platform that matches their middleware commitment. Look for an Agile ALM framework compatible with your middleware.

Tips for mobile SaaS ALM

The biggest challenge in mobile ALM is likely to come from the intersection of mobility with business process changes driven by a need to be more adaptive or dynamic overall. Agility is a factor in both drivers, and the risk of creating a kind of "ALM silo" is significant. However, even future applications are likely to retain the front-end/back-end orientation because it's actually helpful in isolating application logic from presentation-layer changes. If you keep that model as a goal you can be confident that you can manage mobile ALM separate from that of standard applications.

Even then, it's far from clear that you should try to pick mobile-specific ALM SaaS tools. The trend in the industry appears to be strong in the opposite direction; make mobile dynamism an issue to be addressed by Agile ALM. The best approach is likely going to be selecting an Agile ALM tool that has a SaaS delivery option and tuning it to your needs.

What tool? The first choice for most users would be the ALM tools provided by their primary middleware vendor, if they have a fairly harmonious middleware deployment in place. Agile ALM tools from HP, IBM, Microsoft and Oracle are all considered to be very effective and get high ratings from users and reviewers. Of this group, HP and Oracle are most often cited as having the broadest support for middleware technology, and HP has the most aggressive support for SaaS delivery of the group.

The value of having a clean front-end/back-end application separation for mobile applications has already been noted. Because front-end ALM issues are dominantly technical and back-end issues are typically related to business practices, this separation can reduce the total ALM effort and scope and even let you use separate tools if your needs justify it. The key is to ensure that your front-end tools harmonize to a common interface with back-end processes in order for both ALM domains to connect with a solid specification. Otherwise, there is risk of having interdependencies that won't test correctly, and that will invalidate your ALM process.

The other tip for mobile ALM is to be especially careful of the way that push notifications and interactivity are supported. Web-oriented front-ends are normally built to expect user-stimulated interactions rather than notifications. It's easy to ignore that in testing and then fail to validate how well applications can send unsolicited messages.

Addressing SaaS ALM cost

The big issue with SaaS-modeled ALM is cost. It's important to see how SaaS pricing models will impact total ALM cost, and also to note where SaaS licensing creates a special vulnerability to large increases in cost. Where will your test data be stored? How will ALM test phases impact pricing? You have to be ready to switch to a self-hosted model if you find that your application changes are likely to expose you to excessive cost risk down the line.

Don't overthink this. ALM, first and foremost, should be an integrated process with business-wide goals driving it. It's OK to subdivide ALM across multiple tools and between self-hosted and SaaS delivery models, but the end result has to be a responsive ALM strategy at an acceptable cost. Take care up front to insure your approach.

Next Steps

Top five SaaS ALM tools

Shopping for SaaS? Here's how you can take advantage of the market

This was last published in June 2015

Dig Deeper on SaaS application strategy

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What SaaS ALM tools has your enterprise used?
Cancel

-ADS BY GOOGLE

SearchAWS

TheServerSide.com

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

SearchSalesforce

DevOpsAgenda

Close