This document describes the principles and guidelines to buy, own and maintain IT systems developed outside your own organization.

The key goal with these principles and guidelines are to secure that the system developed for you is delivered with a cost effective ownership and operational qualities that ensure availability, robustness and maintainability.

The basic principles are:

1. “Transferability” – It must be possible for another organization than the organization that develop the system to maintain the system and the code that constitute the system. This principle is key since it requires the vendor to fulfill basic aspects of the craftsmanship of software development.

2. “Operational automation” – The cost of operating the system shall be low. That means that the system should be available, robust and maintainable without manual intervention, i.e. automation of all operational aspects of the system is key.

3. “Built for production” – The none functional requirements must be part of your specification scope. High availability, scale-ability and other operational capabilities are NOT something that are deployed separated from the software you buy and neither something that infrastructure solves when in production. If your potential vendor produces statements like “performance is not important” or “that is fixed by xyz products” you know that this is not the partner for you.

4. “Operational architecture” – Define basic common strategies for deployment, surveillance and other infrastructure (cluster, HA, network, visualization, etc). This is something you should do in cooperation with your IT operations department and/or hosting vendor.

5. “Ownership” – All developed code should be your, the customers’, intellectual property by default. Make sure that a lawyer always read the agreements before signing.

To fulfill the principles the following guidelines apply:

1. A system must be possible to install, upgrade and downgrade automatically through programs and/or scripts. Depending on the IT and server platform you have, the developed system should comply with automated deployment tools. Automated copying/cloning of a complete environment must be possible to allow for simple deployment.

2. System installation and updates should be possible to perform as a normal IT-operations task. E.g., we do not call Microsoft to install Office.

3. All source code must be managed in a source code system and you, the customer, should have read access to the source code repository.

4. The use of an administrative system to manage change requests and trouble reports is mandatory. This system should be accessible by you and the supplier.

5. Every new release must be described through a release note including CRs and TRs fixed in the release including specific system requirements. Any CR and TR should be possible to track in commit comments in the source code repository.

6. All system developed must have an automatic build process to create a deployable system. Builds should be performed on a regular basis including automatic regression tests.

7. Release management should be documented including how release numbering is done.

8. The system must be developed to allow for real time measurement of any key application metric important for the operation of the application such as “how many orders per second”, “how many received invoices per day” etc. The implementation of real time measurement, the instrumentation, is dependent on program language and platform. Real time measurement is the most important aspect of alarming on application level.

9. The system must have a model for alarm and notification of both technical and application logic issues.

10. Tests of the continuously built system should be performed on a dedicated test system separated from the development environment. The dedicated test system should be similar to the target production environment both in setup and data volumes.

11. Continuous tests should include functional and capacity tests.

12. All integration with external systems must be documented in format and characteristics, i.e. the application level protocol.

13. It must be possible to determine the version of the installed system.

14. The system should have a logging system, either integrated with existing logging infrastructure or using its own. The logging system should support different level of logging – from critical to debug. If the system uses stand-alone logging, at least log rotation and no buffered write must be supported.

15. Log messages should be aimed for operational purposes and support trouble shooting.

16. Application user management must be integrated with existing infrastructure user configuration, including security.

17. Configuration management should be clear and documented including any configuration dependencies.

18. Mandatory run-time configuration options should be kept to a minimum. Configuration data must always be validated as part of the deployment and start up process. Configuration data should be related to the version of the system and configuration data should be stored in a version control system.

19. Configuration data should have clear and intuitive names. Using a key called “hostname” for the server where the database is located is not okay, “databaseServerName” is understandable.

20. Application backup and restore must be integrated with existing operational infrastructure. Concern for application up-time must be taken into account since it affects backup management of the application.

21. Avoid software that require software and hardware licenses solution that are calculated based on hardware entities like MAC address, CPU serial number, etc. Only accept license when a separate license server is used but try to avoid it!

22. Code for infrastructure and deployment should be reviewed by an independent part. This should be a standard milestone in the project plan.

The next level

If you find that the principles and guidelines in this document makes sense and you are buying externally developed software, then maybe it is time to improve your process to get to a higher level of control. Instead of depending on your vendors’ capability to manage software projects and code why not setup your own corporate software development system that your vendor should use when developing for you?

What you are looking for is software management system that includes:

• Source code management

• Trouble ticket and change request management

• Software release management

• Document management

• Wiki

• Forum

• Mail lists

Examples of software supporting the above are Gforge (www.gforge.org), Fusionforge (fusionforge.org) and Redmine (www.redmine.org).

About Ingenjörsbyn

Ingenjörsbyn is an IT and computer engineering consultancy company dedicated to all aspects of software development and deployment. If you want to know more about us, visit www.ingby.com or call +46 75 75 75 090.