ChMS: Buy it, build it, or integrate it?

If you have spent a lot of time thinking about how to improve the Church Management System (ChMS) function in your church, you probably have reservations about buying one of the existing ChMS products (“buy it”) but at the same time realize you can’t afford to build your own system (“build it”). I want a third alternative: “integrate it.”

With the right technical and non-technical factors in place, it should be possible for your team to integrate technology from multiple commercial and open source providers, along with in-house developed modules, to achieve the range and degree of automation that makes sense for your unique ministry.

In my last post, I listed three technical factors that would need to be in place in order for an open ChMS marketplace to come into existence:

1. A common schema for data exchange. (The best technology for this right now is XML. See ebXML for an example.)

2. An architecture for generating and handling data change events (such as a Web Services API).

3. An architecture for single sign-on.

This list comes out of our experience integrating multiple web applications that weren’t designed to work together. Perhaps there are one or two additional technical requirements I haven’t thought of yet. This brings me to the second part of my question ...

What non-technical (business) factors would need to be in place to foster development of an open ChMS marketplace?

I'd like to suggest we work toward the following:

1. Backing of a few influential churches and/or para-church organizations plus one or more open source or commercial ChMS vendors.

2. A funded standards organization.

3. A Kingdom-minded spirit of unity and cooperation across denominational and geographical boundaries as well as among both non-profit and for-profit organizations.

I’ve said before that we have differing styles, mission fields, and theological points of view, but we have one Lord and we proclaim one gospel. We're all on the same team. Could we begin to move together in a direction that honors God and helps the Church pursue the Great Commission?

I look forward to your comments.

Example of how a Standard and an Open Marketplace changed one industry...

I'm on the part-time IT staff at COR, and I get to talk to Clif directly. I agree with his perspectives on ChMS. We've argued out lots of these points over lunches and Skype chats.

I'm also a worship musician. And I was there in 1983 when the music industry figured out something critical: that a common standard could help *everybody*. Even though the manufacturers were scared and skeptical at first, when they finally dived in THE WORLD CHANGED.

In the 70s and 80s, keyboard players (like me; hey it was 1983!) spent thousands of dollars on instruments: music synthesizers with names like Moog and Yamaha. Learning to play them was cumbersome, and each was a completely independent experience.

In 1982 (still pretty much before PC's) my 3-man company became an original member of the old IMA, right along side giants like Yamaha and Sequential. The objective was to develop Dave Smith's idea for a Musical Instrument Digital Interface (MIDI), which was/is merely a language that all manufacturers could use to translate Black & White key presses into music notes for the sound generator of a synthesizer. If there was a *standard* language for this (the unlikely reasoning went), then instruments could communicate, new grass-roots development from outside would introduce hybrid vigor, and everyone would benefit. But, it was a hard sell: most companies had lots of money tied up in their own systems, and saw things through Old-World colored glasses, hoping for customers to stay "locked in" to the company after learning one instrument's subtleties.

AND THEN: "In a rare example of insight and cooperation, U.S. and overseas companies began working together..." (see Mix Mag's interview with Dave Smith) - - and the 2 companies that spent huge $$ to technically design and implement MIDI gave the technology away to everyone and told *them* how to implement it. (read about the birth of MIDI)

So, in January 1983, at the Anaheim NAMM Trade Show, one guy carried one synth to another synth company's booth, one tiny little MIDI cable linked 2 totally different instruments, and The World Changed. We all quickly discovered digital control, computer mixing, new soundscapes, and a slew of eager new companies hatching new strategies to exploit the newly expanding market. Practically every bit of the worship music I listen to (and create) every day depends on MIDI - a standard that everyone bought into when no one was sure anyone would.

Guess what? Yamaha, and Korg, and the Big Boys are still around, leading their industries, and happy that MIDI came along. The MIDI specification, now nearly 25 years old, transformed the creation of contemporary music. Every church I know of uses it every week, and you've benefitted from it a hundred thousand times. You probably even have .mid files on your PC.

The lesson (of course): working to develop or promote standard schemas will help *your company*, *your church*, and *God's Kingdom*.

More about MIDI at these links:
* Wikipedia - -
* MIDI.org - -

Towards an open ChMS marketplace

See previous posts in this series:
The ChMS conversation we started (but know we’ll never finish)
Choosing a ChMS – the risk calculation

Also earlier posts on related subjects:
Integrating CRM and the Web
Open source Church Management System (ChMS)

No customer lock-in
So what could ChMS vendors do to help me with my conundrum and reduce the risk that I’ll make a bad choice? First, let me suggest a non-technical answer: they need to reject the tempting strategy of achieving and maintaining customer lock-in. They need to go out of their way to make it easy for me to change in the future if I so desire. In other words, they need to set aside their interests and focus on the interests of the Kingdom (and in so doing, they’ll find that their interests are served as well). Instead of competing primarily on a feature list, they need to compete on ease of integration, openness, and customer services. If the vendor can achieve lock-in, they don’t have to be great at these things because they’ll have acceptable rates of customer retention regardless, at least in the short term. On the other hand, if the ChMS vendor rejects the lock-in strategy, my risk as the buyer goes down because I know the vendor will have to continue to earn my business long after the initial sale and implementation.

Second (and this is much more difficult), ChMS suppliers need to find their way towards an open ChMS marketplace. By “open” I mean one in which innovation can originate from many places and come together to meet the needs of a particular church at a particular time. For example, wouldn’t it be great if Granger could run Saddleback’s small groups system with Fellowship’s check-in and WEC’s content management? Wouldn’t it be awesome if Perimeter could run Shelby with Resurrection’s missions opportunity registration system? Wouldn’t it be excellent if Resurrection could run iModules’ online community tools with Perimeter’s Elder system and a web store like OS Commerce? I’m envisioning a marketplace in which there could be multiple for-profit companies contributing technology and services alongside churches, para-church organizations, and open source communities giving away software that automates their process innovations. Wouldn’t that be a major advancement for the Kingdom?

What is stopping us from doing this right now? Well that’s easy enough to answer. The systems I mentioned were built at different times on different platforms by for-profit and non-profit organizations without ever considering the possibility of interoperability. So that’s a big technical barrier. Also, the ChMS vendors don’t see an economic incentive to cooperate with their competitors, which is a big non-technical barrier. Could we overcome these barriers going forward?

To overcome the technical barriers, it seems to me we would need three things:
1. A common schema for data exchange. (The best technology for this right now is XML.)
2. An architecture for generating and handling data change events (such as a Web Services API).
3. An architecture for single sign-on.

Tony posted a comment in which he used the term “platform” to describe what we need. He also quoted me in the ChMS Google group, which attracted a number of comments exactly along the lines I’m thinking.

More in the next post ...

Worship attendance

At the Roundtable we had an extensive discussion of approaches to automate worship attendance. Today Kevin McCord weighs in on the same subject. He thinks printing out a nametag will be enough incentive to get many/most worship attendees to stop at a kiosk and check in.

Choosing a ChMS – the risk calculation

As I alluded in the previous post, a huge consideration for me in choosing our next Church Management Systems (ChMS) is minimizing the risk of making a bad choice. The question of ChMS is the most strategically complex and the riskiest decision I’ve faced since becoming IT Director at Church of the Resurrection three years ago. Why do I say that? What makes this decision especially risky?

The risk is high mainly because Church Management Systems automate core processes. In business or church, whenever you automate core processes you set in motion a complex interplay between your operations and your technology. You adapt the automation system as best you can to fit your processes and you inevitably adapt some of your processes to fit the automation system. You train your staff on the system and over time they develop some deep expertise in its quirks. You purchase and integrate other technology with the system. Before long, the thought of changing the system becomes nearly unthinkable. Companies that build and sell systems that automate core processes understand this very well. Once they get a customer fully on board with the system, they know it will be very difficult for the customer to go another direction. The customer is “locked in” and they're happy (that is, the vendor is happy).

Going forward from the initial implementation, a ChMS is likely to become a two-edged sword. While your operations become more efficient, operational innovation can be held back if the automation technology can’t keep pace. Curtis Harris of Fellowship Tech asked at the Roundtable if it wasn’t possible to have a set of best practices that the system would automate, benefiting all churches that use it. I don’t believe that’s 100% the case (although we all can and should be learning from each other). The best senior pastors are the innovators. They zig when everyone else is zagging. So there’s bound to be some mismatches between what any particular system does and my particular church’s unique way of doing ministry. I strongly suspect that will be the case for other churches too.

Right now Resurrection is too dependent on Shelby. If Shelby doesn’t keep pace with new technology and new ministry models, there’s not a lot we can do because we’re “locked in.” If we go out and find a new system that “stinks the least” and change to that system, we might be better off than we are now, but fundamentally it’s the same strategy. Our risk of Shelby not performing simply changes to a risk of the new vendor not performing. And ultimately, I don’t believe it will be possible for Shelby or any vendor to perfectly, exactly meet our needs.

So what could ChMS vendors do to help me with this conundrum and reduce the risk that I’ll make a bad choice? I’ll share some thoughts on that in my next post.

The ChMS conversation we started (but know we’ll never finish)

After a long day of sharing at the IT Roundtable about everything from WiFi to training and volunteers, we took a break around 4:30 pm and began a lot of conversations in groups of 2 to 5 people. The reps from Shelby, ACS, and Fellowship Tech joined in those conversations. That went on for a couple of hours until the long-awaited Church Management System (ChMS) discussion began. We were just warming up when the pizza arrived courtesy of Shelby and suddenly food seemed more important than ChMS (imagine that!). After pizza we toured the facility and had more conversation in small groups. I think I was one of the last to leave at 10:00 pm. So we started the conversation (or more accurately we continued the conversation that has already begun in the blogosphere and on Tony’s Google group), but we didn’t finish it. Reflecting on that, I realized we will never finish it. So here is another installment in the conversation …

To open the discussion I put up the question: “What do we need the system to do?” This is the usual starting place because we typically think system selection is mostly a matter of determining which system’s features have the best match with our needs. Everyone around the table, with the notable exception of Terry Chapman, agreed with my assertion that no available system perfectly meets our needs today. (Terry is the CIO at Fellowship Church, so Fellowship One is a hand-in-glove fit for them.) John Dolan then rephrased my question as: “Which system stinks the least?” And Tony Dye focused in on the “we” in my original question. “Who is ‘we’?” he asked.

Exactly. Depending on who “we” are, a given system might meet our needs. But unless we built it ourselves, as Fellowship Church did, we’re probably stuck forever with the question, “Which system stinks the least?” (And by the way, Terry said he doesn’t recommend building your own ChMS.) So we start with the assumption that, at a high level, the first issue is “build it or buy it?” And most of us get to “buy it” pretty quickly, perhaps without even consciously considering “build it,” because that option is simply not feasible for most of us.

I then wondered out loud whether “What do we need the system to do?” is the right question with which to begin. I would like to ask what I think is a pre-requisite question. In fact, my question challenges the assumption that our top-level options are build it or buy it. My question challenges the assumption that we have to choose a commercial or open source system and run with it. My question is, “What kind of structure do we need in the ChMS market?” Or, “What kind of business model would optimize the relationships among churches and ChMS suppliers?” Or, “Why should I have to choose whether to run Shelby, ACS, or Fellowship exclusive of the others?” Either/or choices might be our only choices today, but can we imagine a marketplace in which both/and is a possibility? That would radically alter the risk calculation and make my job as IT Director much easier. What technical and non-technical principles would need to be in place for such a world to come into existence?

Ruminate on that a bit while I compose my next post. And feel free to comment. ;-)

IT Roundtable at Granger

What an awesome experience it was to be at Granger Community Church with a bunch of other “church nerds” talking about church IT! My only complaint is that our time together was too short. It was great to meet so many of you in person after reading your blogs, and great to renew acquaintances with old friends.

A big “thank you” to Jason for organizing the event and hosting us. Granger is a place where God is doing remarkable things. It was inspiring just being in their facility and interacting with their people.

We definitely need to do it again some time.

To block or not to block?

We're blocking both MySpace and Facebook at our firewall. Our youth pastor and his boss decided to do this because the school districts are doing it. Their argument is: Why should we be less restrictive than the schools? I'm conflicted about it.

Do you have web content filtration in your network? If so, do you block social networking sites? What are the pluses and minues?

By the way, Scoble says MySpace is for kids; Facebook is for adults. Makes sense.

Comparing a podcast to "teleportation" in Acts 8

This morning Mark Batterson posted about how after leading the Ethiopian Eunuch to Christ, Philip "teleported" to Azotus (actually the text says "the eunuch did not see him again ... Philip, however, appeared at Azotus ..."). Mark compared this to his ability to "teleport" all over the world via podcast. Those of us who are church IT nerds and not pastors really need people like Mark Batterson to put what we do in theological terms. Thanks, Mark. Hopefully I'll remember this the next time someone asks me about church podcasting.