Test-driven IS strategy 3: implementation

By Andrew Clifford

You can achieve a test-driven IS strategy by implementing a simple, high-level evaluation process.

The principles of test-driven development can be used to define and execute IS strategy. The fundamental idea is describe what achievement of IS strategy would look like and use this to evaluate the current situation, in effect to "test" that the strategy is being achieved. You can use these results to drive decisions on the execution of strategy. This is much more effective, and much easier, than defining and executing strategy solely though processes, architecture, organisational structures, and so on.

To implement this approach, you need two things:

• Criteria. Measures that you use to evaluate your fit to strategy.
• Evaluands. The things to be measured.

The evaluands must represent what you want to achieve, not how you do it. IT projects, processes and architecture are only a means to an end. Measuring these may help you do them better, but they are fundamentally inward-looking.

Conversely, you could consider that IT achieves improved business processes. But there is a lot more to business processes than just IT. Measuring only business processes is too blunt for managing IT.

You need something in between. Something that can capture the internal structure and working of IT, which represents what IT delivers, and which is relevant to the broader business.

Most of the evaluation can be based on an evaluand of "system". Not system in the narrow sense of just application software, or just servers. But in the fullest sense, where system is the entire stack: the application, the business-facing service it supports, the software and hardware on which it runs, and the human support infrastructure around it.

This definition covers inward-facing aspects of IT such as support processes, technology and architecture. It also covers outward-looking aspects of IT such as alignment to business processes, and whether systems are accepted and usable.

The criteria should represent your IS strategy translated into desired outcomes for systems. This might include:

• Business usage: ownership, contribution, usability, user acceptance.
• Risks and controls: security, disaster recovery, regulatory compliance.
• Development: system architecture, viability, documentation, testing.
• Service delivery: resilience, scalability, support, technology, configuration management.

The aim is to build a basket of criteria which evaluate how well you are achieving IS strategy by assessing your systems for evidence of that achievement.

Evaluation needs to be rigorous, more than a simple checklist. It is useful to gather both descriptions and objective gradings. The evaluation needs to be applied during projects to make sure that new systems meet the strategy, and applied periodically to existing systems to make sure that they remain compliant and keep up with changes to strategy.

Analysis of the evaluation can deliver two things. It can deliver summary statistics which measure achievement of strategy. This demonstrates how well the IS organisation is doing its job, especially in the critical but less visible aspects of long-term management. It can also pinpoint which parts of which systems need attention to achieve the strategy.

System quality management is a method for evaluating IT systems. It provides a suitable framework for this evaluative approach to IS strategy. Have a look at the material on system quality management for further ideas on how to implement this approach.

Subscription