In the previous Development Support Framework (DSF) post I outlined the broad objectives of this series, this post outlines the high level requirements of the development support framework we are going to build. And by high level I mean really high.
We want our DSF to:
- free from licensing costs.
We want our DSF to support:
- heterogeneous environments (at least *NIX and Windows);
- distributed teams;
- teams of various sizes (from one person to 1000+);
- different development models, e.g. ‘classic’ waterfall, Agile, combinations of both, or new methods as they arise;
- whole of life (so called ‘cradle to grave’) from initial requirement through to retirement;
- whole system—hardware, software and infrastructure, through development, test, and production environments.
Although our DSF is going to be free from licensing costs it would be foolish to think it free from costs. There are still associated administration costs, setup costs, the costs of developing and maintaining ‘glue’ to integrate our systems1. The important question (if you were pitching this system to management) would be the relative whole-life costs of the system.
The system we will build could be used in a real environment. Would I advocate using it? Probably not. This is a teaching aid, not necessarily a production environment and certainly not a ‘cookbook’2. Although I will discuss many issues and things you need to consider when designing and building your own DSF I will not necessarily configure the system being built to production standard. As with all things, the appropriateness of any part of the DSF to your circumstances will depend on many factors that only you can assess.
This limitation is entirely practical. I cannot anticipate your organisation’s setup, so, for example, the precise configuration you need to integrate user authentication into your organisation will undoubtedly differ from the simple setup I will use in this example DSF.
The important message of this process is to learn how to approach designing a DSF and to show each step with practical examples.
1 One falsehood propagated by some integrated tool vendors is that the cost of ‘glue’ software is eliminated by their integrated tools. This is true to the extent that their tools work together, but these tools never cover all of your requirements and so there is always a need to integrate other tools (and this is often excruciating, or downright impossible, when proprietary systems are involved).
2 Cooking is a good analogy here. When learning to cook you learn individual techniques (such as chopping, boiling, basting, reducing, marinating, and so on) and you follow recipes in cookbooks. But once you have learned all of this you start to create new recipes yourself. You use the knowledge you acquired while training and apply it in new ways. I want this series to do the same things; teach technique, provide some practice recipes to illustrate points, and hope that you acquire enough knowledge that you feel confident creating your own recipes.