web
You’re offline. This is a read only version of the page.
close

All ICT projects will face a decision to "build" or "buy" a solution. The Design Authority is supportive of either decision with all projects.

In order to adhere to the Technology Code of Practice, a project must clearly demonstrate that it has considered a "build vs. buy" decision. This can only be done once suitable user requirements have been gathered. In determining whether to build or buy software, the project must consider and document:

  • Are the business needs unique?
  • Is there an off-the-shelf product that meets the business requirements?
  • What solutions are appropriate when considering time, cost and support costs?

A project can also use a blend of purchased and developed solutions.

When developing a system or service, the following must be documented:

  • What technology is being used to build
  • What coding standards are being used
  • What functions of the system can be facilitated through use of existing IOMG or Open Source code, components or services
  • What parts of the system build can have its code published for reuse (either internally or externally)

Technology choice is important

Once a decision is made to develop a system (or part thereof), choosing a technology stack is the next major decision for an IT project. Technology choice can be complex, and there is no ‘right’ answer in most cases. When reviewing a technology stack for development, please refer to the evaluation criteria for technology choice

It may also be appropriate to align your technology choice with a tried-and-testing stack, based on its use elsewhere in Government.

Adhere to coding standards

For IT projects that require code to be written, it is crucial that coding standards are identified and adhered to. For the programming languages that GTS use, there are established coding standards and conventions that can be referenced. In addition to coding standards, the project must also take into consideration any relevant open standards.

By adhering to coding standards, software development projects use a consistent style which makes the code easier to understand and maintain. Standards plan an important role in helping to develop software that accommodates privacy by design and is innately secure.

Don't reinvent the wheel

Development can be made easier through the intelligent reuse of system components and code from the GTS Code library or through utilising Open Source solutions. By adhering to the principles of micro services, systems can be developed through the composition of existing common services.

This approach is not exclusive to using government code, and can be through utilising another technology ecosystem. Assessing a technology stacks ecosystem for maturity, community and quality can be a joint undertaking with the business and GTS.

Share your source code

When software is developed in-house for the Isle of Man Government, GTS will facilitate the publishing of its code to the IOMG Code Library (where appropriate) to improve transparency, flexibility, accountability and reuse between GTS teams and ICT projects.

Please note: Prior to sharing your code, your project must have a record of completing the open source checklist.

The IOMG Code Library is the central point for the Isle of Man Government to share open source code with suppliers, other projects, other programmes and the public. If development is taking place, it is mandated that if code can be open sourced then it should be, and any changes or improvements to existing code libraries be fed back to the original project. Any new components must also e added at project go live for reuse by other suppliers or projects, whilst ensuring adherence to open standards.

Publishing your project code and functions encourages:

  • Transparency in technology by sharing our innovations and creative problem solving
  • Compartmentalised, clear documentation with a clear library based structure resulting in easier to maintain code library with audited change
  • A segmented and structured code library which is cleaner and easier to maintain and contribute to
  • Clear identification of components and data that cannot be shared and are exempt from the Open Source mantra (encryption keys, development related to unreleased policy and code used to detect fraud)
  • Efficiencies across government that would otherwise not exist

When your share your code it is important to choose a suitable open source licences. It is an important decision as it protects contributors and users of your software. The Design Authority can advise projects in this space if they require additional assistance.​​

  Related links