Daily Concerns : Fellowship One

Evaluating the various Church Software SaaS Offerings

Administrator — Mon, 28 Jan 2008 21:03:00 GMT

I recently read an article in a Christian technology journal called An Introduction to SaaS in which the author defined the term Software as a Service (SaaS) as "an application designed to be accessed on the Web rather than installed on the user's workstation. Though the software is Web-based, it is not browser-based. Instead, the software provider develops a thin client application that the user can download one time to their workstation."

I found that definition to be far too limited and partially misleading. So what is the ‘true' definition of the term "SaaS"? Well the definition has come under debate as more and more competitors enter the market with various flavors of software delivery. Simply searching Google for "what is saas" will return a plethora of articles that debate the topic from every angle.

The most basic definition of SaaS is simply "a software delivery method that provides access to software and its functions remotely as a Web-based service" (Webopedia) or "a software application delivery model where a software vendor develops a web-native software application and hosts and operates the application for use by its customers over the Internet" (Wikipedia).

Neither clearly defines a particular delivery model (browser-based, thin-client, etc.) nor specific underlying architecture (multi-tenant, single instance, etc). Fair enough... there are many different ways to do similar things. Here at Fellowship Technologies we leverage SaaS companies for everything from Sales & Support (RightNow) to Time & Expenses (QuickArrow) to Accounting (Intacct). Each of these SaaS companies leverage slightly different delivery methods. Whereas QuickArrow and Intacct are purely browser-based, RightNow is a thin-client that you must download and install on your local PC.

A cursory review of articles on the Internet yields some common threads -- a ‘true' SaaS utilizes "a single production environment to support all customers" or put more succinctly "single instance, multi-tenant." The evolution of SaaS from the Application Service Provider model (delivering hosted client applications via tools like Citrix) to today's model of web-native, multi-tenant, applications also reinforces this concept.

Regardless, I believe the key consideration is this -- are all SaaS delivery methods considered equal to both the provider (scalable, efficient, profitable) and the end user (ease of use, accessibility, cost)? A great article on this topic can be found at SaaSBlogs.com: What is SaaS? The Answer is Rooted in the End User. In the article, the author contends that the best way to define SaaS is from the end user's perspective -- are their needs satisfied by the vendor's chosen delivery model? However, the end user must also consider the viability of the vendor's model. The author goes on to state that "the most successful providers will leverage multi-tenant, single instance because it provides maximal efficiency and value derivation."

So when evaluating companies that promote "hosted" or "SaaS" product offerings consider the following:

Does the software require that it be installed on your local computer? A pure browser-based solution allows you true anytime, anywhere access regardless of whether it's your computer at work, your spouse's laptop, a public computer at a local library or coffee shop, or perhaps even an iPhone. All you need is a web browser to get up and running.
Does the application run equally well on PC and Macintosh computers? Macs are becoming increasing popular, especially in churches. A pure browser-based solution built on web standards will likely run on both.
Is the application easy to use? The application should be written with simplicity in mind, it should be as easy to learn and use as Amazon.com.
Does the application leverage web-based tools and interfaces or is it simply a client application redeployed onto the Internet? A native web-based solution will take advantage of web-based concepts like tagging and linking and it will leverage technologies like CSS and AJAX to deliver a rich user experience without degrading performance.
Has the vendor developed the application from the ground up with the SaaS model in mind? A firm foundation is essential in order to provide the right security, scalability, reliability, performance and efficiencies that are the key elements to a successful SaaS offering. The proper database architecture (multi-tenant), application architecture (web-based from top to bottom), and systems infrastructure (data center, monitoring tools, etc.) is essential.
Does the vendor provide true "no-touch, no cost" upgrades at regular intervals to their browser-based and thin-client products? A key factor is a SaaS company's ability to deliver regular upgrades to features / functions, and rapid fixes to any issues that arise, without requiring the client to manually download or install the updates.
Does the vendor provide an API to extend the core functionality of their product offering? Another success factor is the ability of the vendor to provide an Application Programming Interface (API) so that clients and business partners can write custom add-ons and applications to extend the product's core feature set.
Do you believe the vendor is on the right technology path to succeed in the new Internet economy? A new economy is rapidly forming whereby vendors seamlessly connect to one another to form a mash-up of applications that ultimately increases the value to the end user far beyond what one vendor can do alone. Examples are Google, SalesForce, and most recently FaceBook. It is imperative that the vendor is building on a technology platform that can allow them to compete and thrive in this new economy.
Is the vendor's SaaS delivery model their core competency or is it simply one delivery option among others? A wise saying is "focus on doing one thing and do that one thing very well." A pure SaaS company focuses 100% of their time and talents from Development to Sales to Consulting to Support on delivering and improving their product offering.
Does the vendor offer Support options that complement their SaaS delivery method? Because a SaaS application should be accessible anywhere, any TIME, and that availability is the responsibility of the vendor, then the vendor should provide extended support hours to meet the expectation of availability 24 hours per day, 7 days per week, 365 days per year.

While there are many methods to doing similar things we believe you'll find some significant differences between the various Church Management Software (ChMS) vendors if you do your homework. We welcome such questions about our own product, Fellowship One, and will patiently answer any questions you may have.

God bless,

Curtis S

Lowering the Bar

csimmons — Wed, 16 Jan 2008 00:48:00 GMT

One of the challenges of working at Fellowship Technologies is trying to keep up with our rapid growth while maintaining a high-level of performance for our application, Fellowship One. This past week we reached another milestone in our growth, we served up over 4 million page loads in a single week! What I’m most proud of is that the average render time per page load was just 0.20 seconds. That is in line with top Software as a Service firms like SalesForce.com (Note, the terms Page Load and Render Time are defined below.)

When we first began proactively measuring our performance 3 years ago we were serving up just a few hundred thousand pages yet our render times were a troubling 0.75 to 2.3 seconds per page. So in mid-2005 we set an internal goal of driving that measure down to consistently average no more than 0.5 seconds per page. Through a lot of hard work and dedication the Development and Data Center Operations teams have driven the average down to 0.2 seconds per page despite Fellowship One's astonishing growth in usage.

I’m pleased that I must now tell my team that we must “lower the bar” once again. Hopefully, by this time next year, we’ve driven average render times down to 0.15 seconds or lower.

God bless,

Curtis S

Following is some additional details on how we define and measure application performance.

Accurately defining and measuring performance is an enormous challenge given that there are literally hundreds of factors that can impact the performance of a web-based application like Fellowship One. Some of these factors are within our control (the database, the application, etc.), some are within the control of the church (the local network configuration, the users’ computers hardware and software, etc.) and some are completely outside the direct control of Fellowship Technologies or the church (the church’s Internet Service Provider, the Internet itself, and our Internet Service Provider).

Fellowship Technologies focuses intensely on the factors within our control and offers assistance as needed to the church for factors within their control. Click here for an illustration of these areas.

Our Operations team measures many different factors associated with our physical resources (load balancers, firewalls, servers, network switches, etc.). The team meets on a weekly basis to review the daily, weekly, and monthly utilization trends of our physical resources to determine if the system’s load should be redistributed, if any of the physical resources needs to be redeployed, or if additional hardware should be acquired to supplement or supplant existing hardware.

Application performance is also measured across a variety of factors; the three primary metrics we utilize are Page Loads, Page Render Time, and a proprietary Pain Index. A ‘Page’ refers to a screen or page within the Fellowship One application. The first screen you see when you login is the ‘Home Page’; if you click on Group Email menu item the ‘Group Email Page’ is displayed.

Page Loads
We track each time a page is opened (or ‘loaded’) within Fellowship One. ‘Page Loads’ is a count of the total pages opened within Fellowship One over a period of time and can be reported upon by Page, by Church, and by User.

Page Render Time
When you click on a menu item or button within Fellowship One that results in a new page being displayed, a request is sent across the Internet back to our servers. Our servers receive and process the request, retrieve any relevant data, and generate the page the user is requesting along with the associated data. The completed page is then sent back across the Internet and displayed in the user’s web browser. The Page Render Time is the amount of time it takes for our servers to receive, process, retrieve, and generate the page. We track this data by Page, by Church, and by User.

Pain Index
The Pain Index is a calculation by which we measure how much user perceived ‘pain’ a particular church is experiencing. We calculate the weighted average of Page Loads and Page Render times. For example, if the church has loaded 100 different Fellowship One pages and 2 of the 100 pages has an average Page Render Time outside of acceptable limits then we next look to see how often the page was requested. If the 2 underperforming pages accounted for a high percentage of the church’s total requests then the Pain Index will be high. Conversely, if the 2 pages accounted for a very low percentage of the total request the Pain Index would be low. The Pain Index allows us to focus our efforts on the underperforming pages that are accessed the most frequently. We measure the Pain Index by Page, by Church and by User.

In summary, we use metrics like page loads, render time, and the pain index, along with many others, to proactively address potential hotspots or underperforming areas of our application. While we’re pleased with our progress to date we know that there is always room for improvement (see our blog on our new tool). For additional details on our efforts and for helpful tips for optimizing the performance of Fellowship One, please search for the keyword “performance” in the Fellowship One Support Console.

Experience Fellowship One! – A Top 10 List

csimmons — Fri, 30 Nov 2007 23:24:00 GMT

We’re excited about our new community site, Experience.FellowshipOne.com! In just the first four weeks of the site’s launch we have had over 1,000 different Fellowship One users log in to access the advanced features. And we’ve had many more thousands of visitors to the site to read our blogs and product forums.

If you haven’t visited the various areas of the Experience site, here are 10 great reasons to do so!

Subscribe to Corporate Blogs – There are a number of blogs available from different individuals and teams within Fellowship Technologies. The blogs are a great source of information regarding best practices, tips/tricks, and corporate announcements.
Interact on the Fellowship One Product Forums – The product forums provide an area for users of Fellowship One to assist each other with questions, regardless of their background or location.
Share your Product Ideas – The Ideas tab is an area where Fellowship One users can post new product ideas and enhancement requests. Other users can then comment on and Praise (vote for) their favorite ideas. Our Product Management group will be monitoring the Ideas, the point totals, and the comments, and using the results as input for future product releases.
Stay informed about Product Updates – This blog is specific to information about our future product updates. It contains preparation notices, pre-release notifications, pre-release training videos, and product release notes.
Access Product Education – From the Education tab you can access a FREE library with over 24 hours of on-demand product training videos. You can also register for one-on-one training and consulting time.
Lead or Join a Regional User Groups (RUGs) – You can learn more about RUGs that are forming across the nation and in the U.K. You can review a list of RUGs, sign up for an existing RUG, or volunteer to lead a new RUG.
Meet your needs in one location – The Experience site provides one place to access all of these great community resources.
Learn from others – The Experience site is an excellent resource to learn best practices and tips/tricks from product experts and other Fellowship One users.
Help others – The Experience site supports an online community where you can share your product knowledge and expertise with other users. Your input can make a positive impact in the life of the user and the processes of churches across the nation and world.
Stay Tuned! – We aren’t done yet. We still plan to release at least two more features to the Experience site. We will provide a “Status” feature with performance statistics and maintenance notifications. We will also be releasing “Development” tab with information on how to leverage our Application Programming Interface (API) to extend the features of Fellowship One.

For additional information about the site’s features please visit the Help and FAQ sections.

God bless,

Curtis Simmons
SVP, Product & Services