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. ;-)
Subscribe to:
Post Comments (Atom)
6 comments:
tracking using CoComment
Clif, I like your questions, and I hope you don't mind, I'm mirroring part of this on ChMS discuss.
- Tony
re: What kind of business model...?
"Build" is not a good option for me, and probably for many others. "Buy" implies going with exactly what the vendor thinks is the right answer, and we've all got different opinions there. I'd like to see words like "customize" and "configure" as key choices.
Is it possible to have a PLATFORM, and then "plug in" specific components to meet the needs of individual churches? Perhaps this is the open source model, but to me, open source is still expecting a lot of "build" and not much support. Tough choices. I look forward to your follow-up posts.
It may be helpful to syn with the micoformats movement,
http://microformats.org/about/
Granted this is "presentation" layer, XHMLT/CSS standard -- but it means that no matter how the data is stored, if it is outputed in a microformat (say hcard) then it is "machine readiable" and thus more valuable.
Tony: Your term "platform" is exactly right. It wouldn't necessarily have to be open source to be an open platform.
> “build it or buy it?”
Do both. Since you can't buy a solution that matches the EXACT way you do ministry, do the next best thing. Buy a ChMS PLATFORM and build on it. Doing the 100% "build it" is risky and wasteful (I've been down that path).
> Is it possible to have a
> PLATFORM, and then "plug in"
> specific components
Definitely!
Tony hit it right on the head. With a product like Arena (shared source) you'll be able to start with a core ChMS system, a ton of configurable functionality that might match the way you do church. If a part does not match, then use Arena's API (core "business objects") and create your own solution to share with the Arena community. We're set to be an Arena beta site so I'm a bit enthusiastic about it.
In the next several weeks, I'm going to blog a series on using this approach to solve an example problem: "... but we do Small Groups like this"
Post a Comment