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.
2 comments:
To a degree, I would argue that there's a 4th method being used - "jerry-rig it". This becomes a significant issue if you've decided on an "integrate it" approach AND the applications you are trying to integrate are already jerry-rigged. Do you really want to integrate applications that are barely meeting the needs they're *supposed* to be meeting?
Of course that's true. But whether or not a piece of existing technology meets the needs of a particular church should be decided by people at that church. If you think something is "jerry-rigged" but someone else thinks it meets their needs perfectly, why shouldn't they be able to integrate it?
Post a Comment