Thursday, August 19, 2010

ChMS - MinistryPlatform

Church Management Software is not standing still, and in an effort to keep this blog up to date and useful to people who are reading it I try to follow new developments and write on them when they come up. A new player in the market that is not reflected anywhere in my work to this point is MinistryPlatform. While the name may seem a bit plain at first, as you will see it describes the product perfectly (not that it's plain, but they have built a very robust platform!).

MinistryPlatform (hereafter MP) has been operational since May of 2009 and utilizes the SQL Server 2005/2008 platform and like any modern ChMS is a browser based platform agnostic system. Kevin McCord, the gentlemen who showed me the ropes with MP has a background as a professional DBA, and as such the backend of this product is designed to be incredibly robust and to follow the rules of an ideal database (things like all the data being in third normal form for those of us geeky enough to understand what that means). Kevin's statement to me was that they work to leverage the DBMS as much as possible, and do everything else through an API.

Ah, now things get very interesting, and if you are early in your search and haven't spent a lot of time thinking about this your eyes are going to glaze over very quickly. Let me see if I can explain this simply: Church Management Software is really two things in one. The first part is the database, which is the actual repository for the data. In its simplest form a database is just a table. A single table might have your name, your birthday, perhaps a social security number and anything else that is always completely unique to you. A database for a church management system will have hundreds of tables, all related to one another. To interface with this data you need an application, and it is this application layer that we think of as the Church Management System. The application interfaces with the database and presents the data to the user.

The approach that MP has taken is to build the best set of tables possible, and then build an API that interfaces with those tables. The advantage of this approach is that it makes no presumptions about what you want to do with the data, and provides the maximum flexibility for developers to utilize that data. This approach takes more time on the front end (building API's isn't easy, and it doesn't result in anything an end user can actually use), but once the API is complete this allows a church to build pretty much anything they want.

Of course if all MP amounted to was a database and an API, there would be very few churches that could ever do anything with it. With the foundation in place Kevin and his team have built a very nice full featured Church Management System, ticking all of the important checkboxes and even adding a few that others miss. At this point the system is geared towards churches of 2000 people or more (although they are targeting 750 and up), and is designed with scalability and speed in mind. Most of the time that is a good thing, although there are some things about the interface that I don't like that Kevin explained are built that way with speed as the highest priority. This is part of the reason for the large church focus. When you only have a few thousand giving records in your system speed isn't really an issues. When you have millions of records, speed quickly becomes very, very important.

Kevin explained it like this: "At times it is important to distinguish between the Software Application Framework and the API.  The API is part of the Software Application Framework and it allows other applications to leverage MinistryPlatform.  MinistryPlatform is an Open Architecture, Software Application Framework that allows you to extend the scope of data it can manage without development.  In this way you can leverage MinistryPlatform to manage that new data.  At times a developer might also leverage the API for the new data that the framework is extended to cover.  It isn’t that we spent a lot of time on the API, we did!  However, we spent a lot more time on the framework that allows developers who use our API to focus on the specific ministry need behind the software they are building without worrying about managing all the data, developing workflow, or creating a security model. With MP you really don’t need a programmer to leverage most of what the software application framework can offer."

To drive home his point Kevin showed me a missions module that he had created as a non-programmer using only the application framework, in other words, only what you could do yourself not being a programmer.

I've talked a lot about the platform, and very little about the app itself. Part of that is because while I have looked at the product, I simply cannot give it the time and attention that I did to the products that were actively under consideration. For example, I spent five hours on the phone with FellowshipOne before bringing them in for an all day demo. All told I probably spent upwards of 20+ hours evaluating that solution for HDC. In the couple of hours getting to know MP I like what I see, but can't speak about the app with the same level of confidence I can of ArenaFellowshipOneConnectionPower or any of the finalists in my original comparison.

That doesn't mean I didn't learn anything in the time I spent. First off, MP is multi-site at its very core. The database is designed around multiple sites. As such, multi-site is not an afterthought or a tag, it is integral to the data design and table structure. If you are a multi-site church, this fact alone should have MP on your list of solutions to evaluate.

The overall interface of the product, as I reflect, felt a bit clunky. It seemed to me like I would have some training issues getting users fully up to speed on the product. It was very flexible and Kevin could definitely move around quickly, but the interface is not as polished as some of the competition. That said, I've seen far worse interfaces in my search than what MP presented, it just wasn't my favorite.

The product has solid assimilation and workflow features, including the concept of journey vs. milestones. Each person in the database can be in various journeys, and there are milestones that you can track and help move them along within those journeys. The workflow features seemed good, but I really didn't get to delve deeply into them to see how they would or would not work in our setting.

Another thing I liked about the product was the fact that you could add data from multiple locations. In other words, you weren't always having to go to the "right" place to enter the data you needed, the product seemed geared to allowing efficient operation across the board.

MinistryPlatform also includes event and facility management, which is not an essential part of a ChMS suite, but one that many churches ask for.

All told I was very impressed by what I saw with MinistryPlatform. If we were doing our search right now I am very confident that they would be a finalist. I really like the back end of the product and the philosophies on which it is built. The focus on API makes it extraordinarily powerful and customizable. If you are a church with weekend attendance over 2000 (or well on your way there), you should absolutely take the time to evaluate MinistryPlatform as part of your ChMS search.



KevMcCord said...


Thanks for your time and your interest in MinistryPlatform!

God bless,

Kevin McCord

Anonymous said...


Thank you for the time you put into your blog detailing your ChMS journey. I have found it to be a great benefit. Now that you have had Arena for awhile, what has your total cost of ownership been (Approximate)? I have been given the task of finding a new ChMS for our church and have actually spoken to Russell a few times and have received quotes, but I have learned that there are always unexpected expenses. Thanks again for all of the time you have put into your blog. It truly is a great blessing.

David Eggers

Steve said...

I think the link to MinistryPlatform has changed:

renewingmind said...

Thanks Steve! I've updated the link above.