Are SaaS Software Products Secure?

Software delivered over the Internet is exposed to increasing threats to confidentiality, integrity, and availability. SaaS implementations have an even greater exposure than single-customer deployments. Some analysts have estimated that as many as 90% of all Web-accessible commercial applications have security vulnerabilities. What can and should be done to minimize security vulnerabilities of a SaaS software product?

Security for SaaS software products must be addressed along the following dimensions.

• Threat sources, both intentional (malicious probes, floods, spoofing, etc.) and inadvertent (identification, authorization, boundary violations, etc.). In a SaaS environment, an intentional threat can wreak great havoc because multiple customers are sharing the same code and database. Additionally, inadvertent threats become much more likely, such as one customer gaining access to another customer’s data.
• Phase of vulnerability introduction, the steps in a software development lifecycle, including requirements, design, source code development, object code creation, deployment, operations, and maintenance. SaaS development requires re-thinking an application’s and database’s architecture from the ground up to insure isolation and confidentiality. Ongoing operations and maintenance processes must be designed to ensure new vulnerabilities are not introduced.
• Target of threat, including account information, application processes, data, code modules, and infrastructure. Each component of an application is more at risk in a SaaS deployment because of its shared-use nature.
  

This means that security must be “built in” to a SaaS software product from the beginning. Threats and vulnerabilities must be understood and be the basis of the security requirements of a SaaS software product. The development process must ensure that the product is architected and designed to meet the security requirements, that development and testing practices and tools ensure the security requirements are met, and that the execution environment has been designed and implemented to meet security requirements.

Are you developing a secure SaaS software product?

Top 4 Reasons to Outsource Software Product Development

If you think I am going to say the number 1 reason to outsource software product development is cost savings, you are WRONG! It’s not that you won’t achieve cost savings, but it should not be the main reason you outsource. If all you want is a “cheap” solution, just remember the old adage “You get what you pay for.”

Choosing to outsource software product development is a complex decision which includes target market needs (particularly around speed to market), core vs non-core product development, skills of current development staff, ability to hire key skills, and many other factors.

Based on my experience outsourcing software product development and providing outsourced software product development services, I believe the following are the top 4 reasons for outsourcing software product development.

1. You need to quickly adapt to new technology but don't have the skills in-house. For example, with the advent of smart mobile devices, your users may demand that they be allowed to access your software product via a mobile device. Or, you may need to transform your product from an on-premise product to a SaaS product. But, you don't have the skills in-house to do this.


2. You have a rapid growth plan that includes developing and releasing new software products at a more rapid pace than ever before. This may require putting new teams together quickly to address the new demand on product development.


3. You are unwilling or unable to find enough staff with the appropriate skills in your local market. For example, you may need to ramp up a team of 5-10 developers in 2 weeks. That is usually very difficult in any local market (particularly the 2 week requirement).


4. Your product development needs require flexible staffing. For example, you may need an extra team for a few weeks at a time, but not all the time or you foresee needing an extra team for only a few months.

Our most successful outsourcing clients cited at least 2 of the above reasons as their primary impetus for outsourcing their software product development. I'm interested in hearing other reasons for outsourcing software product development. Let me hear from you.

5 Key Trends in Mobile Usage and Development

Eileen Boerger
President, Agilis Solutions

Recently I participated on a panel at the SIIA “All About Mobile” conference. The conference covered topics such as the explosion of mobile devices in the Enterprise, developing mobile applications, marketing and monetizing mobile applications, and the debate over mobile native apps vs mobile web apps.

The panel I was on discussed the state of the technology and benefits of developing mobile web apps. I’ll just state that I could argue (and have fun arguing) either side of the native apps vs web apps debate, but I was happy to talk about mobile web apps. I truly believe that the technology (mainly HTML5) for developing robust and highly-functional mobile web apps using multi-media has finally arrived. If you don’t believe me, go check out the You Tube mobile web app on your smartphone or iPad.

I found the information shared at this conference quite informative so I thought I would share the key trends that I noted.

1. The use of mobile devices in the Enterprise this year has exploded. One company surveyed Enterprises in January, 2010 and September, 2010 asking the number of mobile OS’s they officially supported. I was surprised to see that in January a small percentage of the Enterprises supported no mobile OS’s, but by September, the Enterprises all supported at least 1 mobile OS. More astonishing was the number of Enterprises surveyed that supported 4 or more mobile OS’s in September – a whopping 44%. I believe that % at least doubled from the January survey.
2. Enterprises are not only allowing but encouraging their employees to use their personal mobile devices for work tasks. In fact, it was reported that a Fortune 100 company recently returned 18,000 corporate Blackberry devices and substituted them with employee-owned mobile devices.
3. Independent Software Vendors (ISVs) are scrambling to add a mobile interface to the Enterprise software they sell. A panel of ISV representatives talked about their experiences adding a mobile interface. Interestingly enough, they all chose to implement mobile web apps.
4. Mobile devices are not limited to smartphones and tablets (such as the iPad). Included in this are machine-to-machine (M2M) mobile devices in healthcare, automotive, etc. I was surprised to see how much development that Sprint/Nextel was doing in M2M development.
5. Microsoft has finally entered the mobile device game in a major way with Windows Mobile 7. Microsoft had several models of newly-introduced smartphones for conference attendees to play with. Time will tell if this platform will catch on in a big way. I certainly am not one to rule out Microsoft’s ability to play in this market.

There are many more observations that I could make, but I'll stop here for now.

No Time for Testing!

Not too long ago I met someone who was developing a new software product for release later this year. I casually asked about their test plans and test results to date. The response I got was underwhelming, and, unfortunately, a response that I’ve heard from other development teams. Basically, my paraphrase of their response was: “We’re too busy developing to test right now.”

Immediately, red flags popped into my head. In my opinion, software testing is an integral part of the software development process and must not be left until the end of the development period. The purpose of testing is to not only find defects in the software product but also to ensure that the product requirements are understood well and that the product is designed to be testable. And, what better way to ensure that product requirements are understood well and testable than by developing tests in the early part of a development cycle or iteration (if developing using an agile methodology).

This means that test planning occurs at the start of a project or iteration. I recommend that developers follow a test-driven development (TDD) methodology that mandates that an automated test is written for each feature/function before any code is written. When the test passes, the code is complete. TDD is especially helpful for development organizations using an agile methodology. For each development iteration, TDD requires the developer to understand the requirements of the feature/function they are implementing and ensures that the feature/function is designed and coded to be testable. TDD also ensures that the features/functions of the iteration work at the end of an iteration.

However, test-driven development does not represent the only testing that should occur and does not mean that a product has no defects. A product development team must consider all the different types of testing that can and should be done, such as unit testing (using TDD), functional testing, system testing, integration testing, and regression testing. Full test design and implementation should be done in parallel with software design and implementation. This ensures that product requirements are written clearly and are testable. Full testing throughout the product development cycle also ensures that defects are identified as early in the development cycle as possible.

Eileen Boerger
President
Agilis Solutions

http://agilissolutions.blogspot.com
http://twitter.com/Agilis_EileenB
http://www.linkedin.com/in/eileenboerger

Use of Agile Development Methodologies vs. Outsourcing

Welcome to my first blog! This blog will focus on software development topics. I hope you find some value from the blogs or at least find what I say thought provoking. So, here goes . . .

Almost every prospective client I talk to says that they are using an agile (or agile-like) software development process. And, almost every one of them says, “Is it even possible to outsource using an agile development process?” My answer is a resounding “Yes”.

Before moving forward, let’s make sure it’s clear that an agile development process is a “process” and still has all the characteristics of a process (steps are defined, results are defined, metrics are defined). Many people I have talked to equate “ad hoc” to “agile”. An ad-hoc process is an oxymoron, i.e., it is not a process and is therefore not an agile process.

Our company, Agilis Solutions, provides software development outsourcing services for Independent Software Vendors (ISVs) with a blended team of onshore PMs, technical architects, and analysts and offshore developers and testers in Vietnam. We have worked with many companies using their own development processes. In the past 3 - 4 years, almost every company we work with uses some form of agile development process. After an initial “getting to know you” period with each client, we have successfully developed products using several variations of an agile development process.

As I’m sure you all know, there is no single “agile methodology”. These days, most teams use an adaptation of scrum to manage their agile process. This means having a backlog of work that is delivered in manageable pieces (i.e., iterations or sprints) and emphasizes full teams, including product management, development, and QA, working together interactively to successfully deliver each iteration and finally, the released product.

How can teams work together interactively if they are an ocean-apart in
distance and several hours apart in time? The keys are:

• excellent communication via the use of collaboration tools
  
  
• tracking progress of both internal and outsourced work using collaboration tools


• a strong commitment to make the process work across an ocean.

Example 1.

One of our clients uses several communications mechanisms to compensate for the teams not being located together. Teams on both sides of the ocean hold daily scrums (short meeting of team to discuss status and issues) and summarize their scrums in daily reports to each other. Issues identified that need to be addressed by the team on the other side of the ocean are tracked through to closure. In addition, weekly skype conferences are held to make sure that everything is moving forward and to also address outstanding issues. The teams each work out of the same configuration management system and are involved in daily builds that include each others code changes. The QA teams use the same test machines (but during different times of the day) ensuring that tests are done using an identical test environment. And, internal and outsourced teams track their time using the same system.

Example 2.

Another client uses a “kanban” methodology (made popular in Japan manufacturing companies). In this method, “tasks” are tracked via cards (one task per card). Each card goes through a set of steps, such as task definition, design, coding, testing, acceptance. Standards exist for the flow of a card, meaning how long each step is, how many days should be spent per card and how many cards should be active at any one time. In this case, the standard is 6 days per card. The progress of the cards are tracked electronically and can be viewed by team members on each side of the ocean. Everyone can see where a card might be blocked and can offer help to unblock a card. In addition, daily meetings are held on both sides of the ocean and across the ocean to identify and address issues.

One last thought, a commitment to make agile work with an outsourced team must exist on both sides of the ocean. It’s too easy to point a finger at “those people over there”. Both sides have to remember that teamwork must extend across the ocean. If the commitment is missing, most likely the relationship will fail and so will the project. That is a lose-lose situation. All levels must make a commitment to outsourcing to reap all the benefits of outsourcing.

Hopefully, I have given examples that help you see that you can outsource software development while using an agile development process. I’m not saying it’s easy, but it can definitely be done.


Eileen Boerger
President
Agilis Solutions