Page tree
Skip to end of metadata
Go to start of metadata

As with any technical strategy, it is important to lay out a set of principles that guide decisions and approaches during the evolution of the strategy. The following principles are key to the IHTSDO Tooling Strategy:

  • Agile Development

All development projects must follow Agile principles, as outlined in the Agile Manifesto, documented in the Appendix. This means short iterative developments, frequent deployments.

  • Open and Transparent

All development will be open source under the Apache v2 license, unless a COTS product has been chosen, and all plans and progress will be publicly available on the relevant online location.

  • Organization/Community Wide Functionality

Any application development or procurement should be done within the context of the organisation and the community, not an individual domain area.

  • Requirements Based Design

Changes in applications and technologies are implemented only to meet business needs.

  • Ease of Use

Although the IHTSDO Tooling needs to meet complex requirements, the complexity should not be exposed to the user.

  • Innovative and Agile

The technical strategy readily supports the incorporation of new technologies to support business and technology innovation.

  • Technology and Vendor Independence

The architecture is designed to minimise the impact of technology and supplier changes on the business, as well as be resilient to change.

  • Reuse

Investigate the reuse of existing and proven solutions, internal and external, where appropriate.

  • Service Oriented

The architecture and components built upon it should be viewed as a set of independent services that can be combined to provide a solution.

  • Ensure Design Simplicity

The architecture and tooling must be as simple as possible to maintain yet meet all business and organization requirements.

  • Hosted solutions

All user systems should be browser based wherever feasible or where a specific business requirement exists for 'offline' working.

  • Repeatable

Defined processes and design patterns should be repeatable and therefore able to be automated wherever feasible.

  • Refactor regularly

Regularly review the work that has been done, look for lessons learnt and ensure that delivered product is maintainable and supportable for the foreseeable future.

  • No labels