Purchasing Software-as-a-Service vs. Doing It Yourself

This article was originally published in the JHU mHealth Digital Digest. I have modified the content for this blog post based on feedback from the community.

I subscribe to the idea that software is eating the world and want to share some evidence in the international development sector. New entrants in the space have built businesses providing Software as a Service (SaaS) to support organizations in the development sector. Long-term players have transformed their software models from do it yourself (DIY) to Software as a Service. As an implementer, I value this enormously and advocate for this model even though some challenges remain.

Many open source projects in the international development sector were created as do-it-yourself systems. For example, RapidSMS was created in 2007, Open Data Kit was created in 2008. The software is freely available for implementers to download and run on their own. Under this DIY model, the implementing organization takes full responsibility for ownership, achieving compliance and operation of the system. New players entering the space have immediately structured their software using the SaaS model instead of DIY. “‘SaaS’, or ‘Software as a Service’, describes when users ‘rent’ or borrow online software instead of actually purchasing and installing it on their own computers.” - Source This model reduces the barriers to entry, allowing organizations to purchase the service instead of develop native expertise to achieve their outcomes.

##Why is SaaS a good thing? SaaS is a service delivery model that shifts the burden of deployment from the organization to the SaaS provider. It’s really difficult to run a stable and secure IT service. Deploying and maintaining a system takes an incredible amount talent and resources. Hosting fees, SSL certificates, backups and compliance audits require specialized expertise that is often beyond reach for an organization. I’ve done the evaluation and these are just a few of the direct and indirect costs that must be considered by the organization. SaaS providers centralize their system to one location and take on this burden to achieve economies of scale. Organizations running DIY can achieve a similar economies of scale, but this often require a large IT budget that has to take care of all these things. From my experience, small organizations find it difficult to maintain such a solution.

##Open Source SaaS Platforms

Magpi was one of the first SaaS platforms for mobile data collection. Magpi is a proprietary system that does not share their source code and remains a major player in the international development data collection space. As I stated before, DIY open source software is really difficult. This fact has allowed open source service providers to emerge. CommCare, Kobo Toolbox, Ona.io and TextIt are all examples of open source SaaS platforms for development professionals. These systems were developed at universities, NGOs, international organizations and social enterprises. Innovation in this space is thriving. Each platform is backed by an organization with a clear mission and value proposition. Additionally, sharing your source code increases the size of the developer base. Some savvy individuals install the software themselves or integrate it into other systems. Organizations win when their software is used by more people, developed by a diverse group and receive more feedback.

SaaS platforms in the international development sector serve a wide audience including small organizations, research professionals and governments. These innovations have opened doors for paper-based organizations to shift to mobile data collection by paying a monthly fee instead of heavily investing in IT infrastructure. This has allowed my organization to focus on providing services to our clients instead of becoming a software company.

I have to take a moment to define the difference between an open standard and an open source SaaS platform. This is critical for ensuring that your information isn’t locked in to one SaaS provider. The ODK Xform standard is an open standard that ensures information transmission is structured in a standardized way. SaaS platforms have the choice to conform to that standard or build their own structured system for transporting data. Some SaaS platforms have contributed to and conform to the Xform standard and others haven’t. Theoretically, data and forms can be moved between SaaS platforms that conform to the Xform standard. I haven’t tried moving data from SaaS platform to SaaS platform, but the Xform standard allows systems like ODK Collect and Enketo to communicate with ODK Aggregate and Ona.io.

There’s an interesting argument at play around making your source code open source. How do these open source SaaS providers stay in business? The answer is that good, production quality, software is incredibly complex and it’s cheaper to buy a SaaS license than to stand up these systems yourself. Nicholas Pottier put it well when they made TextIt open source “As a rough guideline, if you think TextIt is too expensive, then you definitely cannot afford to host RapidPro in a reliable manner yourself.” - Source Additionally, this blog post about CommCare issues in February reveals exactly how challenging it is to setup your own version of the software. CommCare HQ’s server utilizes CouchDB, Postgres, ElasticSearch, Redis, Python, Django, Celery and Apache. This open source software is not for the faint of heart. Knowledgeable developers download these platforms to run them on their own. I’m an implementer who is trying to deploy a service that helps my organization succeed. I tried to stand up a local instance of CommCareHQ last summer and failed miserably because of the complexity of the system. Of course my organization could hire a computer scientist to run their instance, but we crunched the numbers and realized that it’s cheaper for us to purchase the SaaS license.

##Challenges to the SaaS model for the development sector

I see two key challenges for SaaS providers in the international development sector. The first challenge for SaaS providers is the location of reliable servers that are close to customers. SaaS providers operate their services in the cloud, which often requires that they choose a core location to host their information. For example, CommCareHQ.org is hosted on the cloud service provider Rackspace for general use. They have additional servers in Zambia and India to ensure they have fast services for their users in Africa and South Asia. As a rule of thumb, it’s best to locate your service as close as possible to the end user. SaaS providers like this have to compensate for slow infrastructure by providing duplicate deployments to achieve this.

The second challenge is providing meaningful customized reports to customers. SaaS providers are generalists by definition. They do their best to provide a core set of features that the majority of the user base will adopt. This is evident in reporting features of these providers. They do their best to create meaningful standard reports that can be used by the majority of customers. As an implementer, this can only get you so far and we should understand that a SaaS provider may not be able to fulfill all of my reporting needs today. My team wants a custom report for each information set. In this case, I have submitted the custom reporting requirements to a SaaS provider to see if this could be used by a broad audience. In some cases, my custom report may not be valued beyond my implementation. There are two solutions right now. The first, and innovative, solution was recently released by Ona.io. They allow customers to pay to build custom RealTime XLS reports. Another solution is by providing access to an application programming interface (API). Some SaaS providers allow customers to access their API and pull data to another location for analysis and custom reporting. The expectation is that this API provides access to the data so customers can meet their custom reporting needs. For example, a customer would build or buy a separate customized reporting system for themselves and pull the data from the API.

These solutions aren’t perfect and seem to be workarounds. We have seen rapid deployment of static content through content delivery networks (CDNs), but this doesn’t help with dynamic content or form submissions. I think there is space for a CDN-type solution for dynamic content in this area where edge servers act as extended arms that duplicate content and accept form submissions. In this world, I could use the cloud SaaS service and submit my forms to a server here in Nepal that duplicates and transports the form submission to the core system. Then that remote worker would only have to submit from their mobile phone in rural Nepal to a server in Nepal instead of India, or the US.

##My Recommendation

I have no affiliation with any of these SaaS providers. I whole-heartedly recommend that you purchase SaaS instead of DIY if these providers can meet your needs. As a project manager, not a computer scientist, it is difficult to predict enormity of resources required to run a production software system. As a global health IT project manager my goal is to provide sound services that improve the situation of our clients. Purchasing SaaS products has helped me achieve that goal more quickly and at a reduced cost than doing it myself.

Contact me if you'd like to talk about this post.