Test-driven IS strategy 4: implications

Test-driven strategy is easier to communicate and more flexible. It provides a clear mechanism for ongoing improvement.

Over the past three weeks, we have covered how the principles of test-driven development can be used to define and execute IS strategy. We have covered how system quality management provides a framework for this approach.

What are the benefits of this approach, and what are the drawbacks?

The main benefit is that it is simply a more efficient and more effective way to define and execute IS strategy. You spend less time and money on strategy, and achieve a better result.

There are three other key benefits:

• It is easier to explain IS strategy and to justify the work required to achieve it. If you express strategy as IS processes, organisation and technology, the response from your business colleagues will be, "So what? This is just internal IS management. Why should I care?" Expressing strategy as outcomes that your colleagues value (such as continuity of service and speed of change) makes it much easier to explain and justify the required work.
• It is easier to continuously improve the strategy. Most strategy is ill-defined. If something is not working, it is not clear whether the strategy needs improving, or management needs strengthening. An evaluative approach clearly separates intent from implementation. It lets you do both halves of your job - defining direction and achieving it - more easily.
• It is better at coping with organisational change. Traditional strategy is rigid: it defines IS processes, organisation and technologies. Organisational change is hard, because the processes, organisation and even technologies need to be realigned to reflect changes in the broader business. An evaluative approach frees you from this. It lets you bring together different IS organisations under the same strategic umbrella. You can manage by bringing together objectives, and let realignment evolve more slowly where there is a real need.

Is there a downside to this approach? That depends on your perspective.

In a traditional approach, the strategy is expressed in terms of its implementation. This gives extra status to those who implement or work with "strategic" processes or "strategic" technologies. An evaluative approach changes this emphasis, and, politically, there will be winners and losers. Those who have built their careers by chasing after the next big thing in the name of strategy will lose out. The unsung heroes of IS, such as operations and support managers, will have the opportunity to show just how much their day-to-day activity drives the achievement of strategy.

On balance nobody really loses. This approach allows for better management of what we have, and more confident embracement of change.

Test-driven development is not really about testing. It is a way of thinking about systems, their design, and their development. An evaluative approach to strategy is similar. It is not really about checking that you are following strategy (though it does do that). It is a way of thinking about strategy, defining it, and executing it. It turns strategy from worthy words in a document to a practical tool for setting and achieving objectives.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Test-driven IS strategy 3: implementation

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.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Test-driven IS strategy 2: principles

IS strategy is much more practical when it is based on a description of what good IS looks like.

Test-driven development gives benefits of efficiency, clarity, risk reduction, speed and communication. The key to these is to focus on what is required and how this can be verified, before looking at how it can be achieved. This same principle can be applied to IS strategy.

This idea is deeper than it may seem. In any situation, you can build one of two different types of theory:

• An explanatory theory, which describes how a thing works. The aim of an explanatory theory is to understand the parts of a thing and how they are related, and to use this understanding as a guide to achieving objectives.
• An evaluative theory, which does not describe how a thing works, but describes what a good thing looks like. You can evaluate against this description, and use this as a guide to achieving objectives.

Evaluative theories work well because they are easy to define. They are also more rigorous because they can more completely cover requirements.

Going back to test-driven development, it is nearly impossible to validate that a design correctly meets all requirements. It is possible, however, to define a set of test cases which perfectly reflect requirements. Test-driven development is not a nice-to-have to make testing easier. It is a development technique that achieves a closer fit to requirements at lower cost.

In a complicated situation, like overall strategy, the advantages of evaluative theory are even greater. It is impossible to build a complete explanatory theory of how to achieve IS strategy (you would need to define exactly how everyone should act in all situations). But you can define a complete evaluative theory.

Despite this, our current approach to IS strategy is based on explanatory theory. We try describe how people should work (processes), how they interrelate (organisational structure), how the technology is designed (architecture), and so on.

Adopting an evaluative approach to IS strategy has many advantages:

• It is much easier, and much more rigorous, to represent IS strategy as required outcomes, than it is to define the required processes, organisational structure, architecture, and so on.
• It allows for variety in management. A strategy expressed as outcomes can apply across multiple IS organisations, but a strategy expressed as processes, organisation and architecture can not.
• It is easier to stick to the chosen direction. Evaluation keeps the organisation on track, and stops it being constantly diverted by the "next big thing".
• It is easier to make changes to the strategy, because changes can be defined independently of their implementation.

An evaluative approach to IS strategy is not a nice-to-have to control the IS organisation. It is not part of IT audit. It is a fundamental technique for IS management, a better way of defining and executing strategy, a better way of meeting requirements at lower cost. It turns strategy from worthy words in a document to a practical tool for setting and achieving objectives.

Next week I will outline the techniques required to build and benefit from an evaluative model of IS strategy.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Test-driven IS strategy 1: introduction

Can the principles that underpin test-driven development be applied to the definition and execution of IS strategy?

Test-driven development is a well-established approach to systems development. The defining characteristic is that tests are written before code is written. Tests provide a structure for design and coding. Test-driven development is generally accepted as a fast approach to development that delivers a high quality product.

Test-driven development forces the developer to focus on the outcome of the work, and how the work can be proved to be correct. This focus is then repaid by freeing the developer from many of the difficulties of traditional approaches.

• Tests are an efficient way of representing requirements. It is easier to fully and unambiguously represent requirements in a set of tests than in a design.
• By clearly defining right and wrong outcomes, tests provide clarity to the process. If all tests are passed, the programs are correct. There is no need for procrastination. There is no need for extra work "just to be sure".
• By embodying existing functionality in test cases, there is a much lower risk that new changes will invalidate the existing system. Change can be made much more confidently, and if the testing process is automated, very much faster.
• There is a clear distinction between errors in the system (tests not passed) and errors in the requirements (tests are wrong). This separates problems of implementation from problems of intent. It clarifies communication, particularly when requirements change during development.
• The clear and unambiguous definition of requirements up-front, in the form of tests, helps prevent unnecessary elaboration of the design.
• Tests provide a very clear mechanism for making changes. Changes are specified by changes to the required outcome, not by changes to the design.

I have found test-driven development hugely valuable. It helps us develop our Metrici Advisor software with speed, ease and confidence. It makes our development process much more efficient, and helps us compete with businesses many times our size.

Test-driven development is not just about programming and testing. It is a way of thinking about design. It moves the focus away from the structure of the solution, to the definition of the requirements and how the correctness of the solution can be validated. This clarification of intent is what makes development so much easier and less risky.

As the name suggests, test-driven development is fundamentally a systems development practice. But the benefits of the approach - efficiency, clarity, low-risk, speed, good communication, good change management - are general benefits that all parts of IT could benefit from. Can we use the underlying principles - a focus on requirements and validation of correctness - to achieve these benefits across all parts of IT management? I believe we can, and that we can scale these ideas to the definition and execution of IS strategy.

To understand how, we need to look more closely, not at the technical aspects of testing, but at the principles that make test-driven development work so well. I will look at these principles in more detail next week.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.