Standards, Not Just Systems

How the global church can set digital ecosystem standards without forcing every field to run the same software

Not that many years ago, Adventist organizations were considerably more siloed than they are today. When a technological advancement occurred somewhere in the world church, it usually stayed where it was built. Without shared digital ecosystem standards, new advancements had nowhere obvious to travel.

What has been a real encouragement to me in recent years is watching that change. Innovation is happening in different fields and it is genuinely cross-pollinating.

The South American Division has produced excellent work that is now making an impact well beyond its own territory.

Closer to home for me, the South Pacific Division’s development of the Thrive CRM has become something other fields are actively deploying.

Before anything else, I want to express appreciation to the forward-thinking leaders who made that kind of sharing possible. It represents a meaningful shift in how we think about what belongs to the whole church.

Alongside that, I have watched policy at the General Conference level crystallize around centralization and shared infrastructure. This makes good sense and goes a long way toward protecting the Adventist digital ecosystem. It gives us something coherent to build on rather than a patchwork of unrelated decisions.

Local Needs

Even with all of that in place, there will inevitably be a union or local conference that considers its needs genuinely different from what is being used elsewhere, and chooses to build its own product to solve a similar problem.

The temptation is to resist this. After all, if we have a monolithic product solving one problem for the entire world church, we gain efficiencies and advantages that are very difficult to argue with, particularly when you are looking at it from a global standpoint. Fewer contracts, fewer integrations, one security posture, one training pathway, one roadmap.

But with as much diversity as there is in our global community, I think it’s reasonable to expect that one solution won’t work in every circumstance. When a specific field does build its own solution, we lose the level of integration we could otherwise be enjoying as a global community.

This is a natural problem when you are dealing with a decentralized ecosystem like Adventism. It’s not a failure of leadership or of goodwill. It’s the expected trade-off when authority is genuinely distributed and every organization is accountable to its own constituency.

We value free will and autonomy, so were always walking the line between what needs to be enforced and where we empower our leaders to make the best decisions for the people they serve. I would like to suggest an approach that preserves both.

Standards Running Parallel with Systems

We need to set standards as a global church. Standards that define security, integration, and data governance.

In practice, I think that means two things held together.

The first is a set of shared definitions. What a member record contains, what an organizational unit is, what the fields mean and in what format, and which system holds authority over each one. It’s not a glamorous task but it’s foundational to a cohesive ecosystem.

The second is a conformance bar. What an application must demonstrate before it’s permitted to connect to existing infrastructure. How it authenticates, how it stores what it holds, what it logs, how access is revoked, and what may cross an organizational boundary and under what conditions. Requirements rather than guidance, with a way to test them.

The standard should be abundantly clear on both of these points but afford freedom as to what actually gets built.

Here is what that looks like in practice. Say a local conference in New Zealand determines it needs a specific piece of software, and the way it’s built requires a connection to ACMS for membership information and an integration with Thrive to capture spiritual interests. That conference applies the standards set by the global church. We then know two things without having to investigate case by case: it meets the expected level of quality, and it’s interoperable with the church’s platforms. If that conference later chooses to share the work with other fields, it plugs into the wider ecosystem naturally, because it was built to the same definitions from the beginning.

This runs alongside the church’s existing infrastructure rather than in competition with it. Centralized systems remain the authoritative record. The standard allows custom solutions to be built without losing all of the benefits of a monolithic platform.

The thorny part

I recognize this brings real difficulties with it, particularly around privacy and data governance. Once systems talk to each other, questions about who may see what, under whose consent, and with what audit trail all become legitimate considerations.

I am not minimizing the size of that undertaking but I do believe these are surmountable problems. They are also, in a sense, problems we already have. Data moves between our organizations today. Clearly defining the rules under which it moves is important even if we weren’t defining software standards.

The default way to protect against negative outcomes is to say ‘no’ by default. That’s an understandable approach because, in order to say ‘yes’, so many decisions would have to be made to ensure good governance. That’s understandable especially if there is organizational memory of bad experiences in the past.

The problem with this position in the long term is it doesn’t scale, and it asks senior people to make a fresh judgment call every time someone arrives with a new idea. A well constructed standard replaces that with a question anyone can answer on evidence: does this solution meet the requirements?

What it opens up

It’s easy to think of the Adventist ecosystem as exclusively the official church structure, but there is so much more when you include healthcare, education, supporting ministries, and many auxiliary organizations. Having a standard like this has a considerable impact on that part of the ecosystem as well.

If the standards are published, then independent ministries and supporting organizations can choose to follow them as well. That means more tools available to the global church that have already been vetted against the same security and integration requirements as anything built internally. 

We have extraordinary technical talent scattered across schools, health systems, small businesses, and volunteers throughout the church who would contribute tomorrow if there were a documented, coordinated way to do so (I say this from experience as I work with many such people).

At the moment, the practical route to building something usable at scale runs through being already connected to the right organization. A standard changes that, and it does so without lowering the bar.

It also changes what sharing means. Under a standard, adoption of new technology is not a binary yes-or-no decision. The technology stack for each organization can be better tailored to their needs and the global church maintains the values and standards that a fully integrated digital ecosystem offers.

Where to from here

In the end, this is the heart of it: standards, not just systems. Systems will keep multiplying as different fields solve their own problems, and that is a healthy sign of a living, decentralized church. What holds them together, and keeps the whole digital ecosystem secure and interoperable, is the standard everyone agrees to build to.

This is a starting point, a discussion piece. I’m sure I am not the only person who has talked about these ideas and there are others who are far closer to the administrators and policy writers and would be well placed to tackle this topic, but I wanted to bring it out into the open to start a discussion that may help to assemble at least some of the elements needed to pull together and make this happen.

If anyone would like to dialogue with me any further about it, please reach out.