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.
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.
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.