Goals and Principles


  • To provide a suite of tools that help all officers to perform their duties, and all members to participate in the activities of the Kingdom.
  • To provide support to people using those tools.
  • To manage the provision and maintenance of those tools, so that they remain current, supported, and fit-for-purpose.
  • To provide advice to the officers and members of the kingdom on the most appropriate tools to use for a given task.


Fit for Purpose

The needs of Lochac will be met by a number of different systems, each supporting one or several user needs – no single tool can do everything.

As far as possible, we should identify one tool for each purpose.  Multiple tools that do the same thing cause confusion among users, increase the learning required for people using the tools, and increase the support required to keep the systems running.

Before adopting a new system, we will consider reusing an existing system for an additional purpose.  If an existing system will not provide a fit-for-purpose solution, we will consider an existing product. We will only consider building bespoke systems once the first two options are ruled out.

Not all tools will be run and managed by the Masonry team – in some cases, a publicly-available system will be the best tool for the job.  Where that is the case, Masonry will still provide support and coordination for Lochac’s use of the tool.

The Masonry team is responsible for eliciting requirements from users for the tools they need.  Sometimes users don’t fully understand what their requirements are, or the implications of what they are asking for — it is our job to help them work those things out.

The Masonry team has the authority to identify a preferred tool, based on the combination of user requirements provided and other factors relating to the support and management of different alternatives.

If there is a cost associated with a user requirement, the user is responsible for submitting a business case to the Kingdom, Board, Committee or their group council to secure funds.  Masonry don’t have any money of their own.


Our systems need not be completely free, but the total cost of all the products and services we use has to fit within a finite, sustainable budget.  In order to plan ahead, Masonry need the Kingdom and Au/NZ societies to approve an annual cap on spending.

Each new product or service that we consider implementing must be affordable, and the collection of products and services that we buy or rent has to represent the most efficient and effective use of that money — the best bang for our bucks.

When we consider the cost of a system, we have to think about the whole-of-life cost, not just the cost of setting it up.  We need to look ahead, and make sure we will be able to pay the annual costs of using the system.


Technology products and services don’t last forever.  Each system we use will become obsolete, and we will want to move on to a new system that replaces it – so we need to plan ahead for the day when that new system becomes obsolete, in its turn.

When we look at new systems, we need to consider whether or not we will be able to import our existing records into them, because if we can’t we create a break in our history.  If there is no way we can do that, we need to make sure the superseded system can be archived, and remain accessible for when we need to look something up.

Before we load our data into a piece of software, or put our systems onto a server, we need to be sure we can get the data and software back again at the end of the product life or the contractual arrangement.

The more complicated the system, the better the export needs to be.  If we store simple files in an environment like Dropbox, we just need to be able to get them back out.  If we use a complex CRM product, and build structures in it to reflect our groups and events, then we need to be able to get the data back out again with the relationships between tables preserved, and to export both data and stored procedures.


All of our systems need access control to be managed, robust, sustainable and based on roles and group membership.

  • Managed means a hierarchy of access levels, with an administrator class who are able to grant and revoke privileges. CRUD (Create, Read, Update and Delete) privileges should all be managed.
  • Robust means that we need to be able to demonstrate that the security of any system that contains any personal or financial information has been tested, and that we have demonstrated a reasonable level of due diligence that the security mechanisms will protect systems and data against probable threats.
  • Sustainable means that the process of adding and removing users, and adjusting the security settings as the kingdom changes over time, needs to be something that we can do (and keep doing) with the resources available to the masonry team.
  • A given user’s access levels should be determined by the role they hold, and the groups they belong to. A user who takes on office should get the additional system access they need to do their job automatically, once their name is linked to the office the hold.  A user who is made a member of a group should get access to all the resources relevant to the group.

Extension and Integration

Every system Lochac runs relates to the same community of people, and the same collection of baronies, shires, cantons and colleges.  If we don’t just have one system, then we want all the systems that we do have to talk to each other, so that people don’t have to maintain their details separately in each system, and so that an update to one system (like the establishment of a new shire) is reflected everywhere.

We also need all our systems to allow for extension in the future, as we add new activities, qualifications, awards or types of member or group.


In most respects, Lochac grows very slowly compared to software and hardware scalability.  We probably don’t need to worry too much about our databases growing so big that they slow down or run out of room, during their operational lives.

The exception to this will be around multimedia — if we start to make more use of audio and video files and streaming services, then we could run out of disk space and bandwidth.  Whenever we are considering any new system, or renewing a support contract, we need to consider how our membership is growing, and how their use of IT systems is evolving, to make sure everything we buy or build can grow with them.


There are two ways our systems get supported: for free, or for a fee.  Whether we are talking about a paid service, or one supported by volunteers from within Lochac, we should pick systems where there is a choice of people to support them.  We can’t afford to be tied to one vendor, and we can’t afford to be dependent on one volunteer, for any of our important tools.

Supportability means not only choosing systems that more than one person or company might support – it means planning them and managing them so that the support task can be passed on from one person or company to another.

This means using open standards, and avoiding obscure (but handy) code libraries and plug-ins.


None of our members are going to attend training courses on the use of our systems, before trying to use them.  Most of them won’t call Masonry when they have a problem – and we have limited resources to support the ones who do.  So we need to minimise the need for training, the likelihood or people making mistakes, and the frequency with which they call for help.

Whether we are choosing between alternative open-source products, or building something for ourselves, we need to test it with users who are not IT-literate, and be prepared to change the user interface to reflect how they expect the system to work.  The only useful definition of “usable” is “it did what our users expected it to do.”

Accessibility and Responsive Design

While our websites might still be getting visited by people using full-size computer screens, more and more often the people looking up details in systems like Registry, Canon Lore, the Lochac Roll of Arms and the authorisation databases will be doing it on their phones while at events.  That means the layouts need to be smart enough to accommodate people working on a five-inch screen.