Performance Assurance for IT Systems

Target Audience

It is not my intention to attempt to produce a book that tells you everything that you (n)ever wanted to know about addressing IT Performance. My simple objective is to discuss the key performance-related issues, whether it be the use of immature technology, the credibility of vendors, how to deal with the lack of solid information when attempting to size the system early in the bid or project lifecycle (what I flippantly term the crystal ball gazing act), scalability, or a whole host of softer, non-technical issues, and to provide the reader with sufficient guidance that he can feel confident about tackling them.

The reason for this approach is that I have come across a great many bids and projects where:

the members of the team are largely unfamiliar with some / all the technologies that are to be used, and do not understand what design issues there may be, e.g. in the area of scalability
the person who is responsible for the hardware sizing has never done it before
due to inexperience, there is a tendency to believe what hardware and software vendors tell you, particularly the sales and marketing people - generally a healthy dose of scepticism is preferable
the various layers of non-technical individuals, from bid / project manager, line of business manager, through to sales and marketing, struggle to understand the technical risks and the associated cost implications.

I have striven hard to ensure that part 1 of the book (about the processes) is in large measure understandable to most people in the IT industry. My objective was to make it readable ... almost like a novel - I use this analogy to get across the message that it pays to read it serially, rather than dipping in and out. The general feedback seems to be that I have succeeded.

Part 2 (the technology tasters) is by its very nature more technical than part 1, although I have endeavoured wherever possible to write in English rather than "techie speak". Do not necessarily assume that you may not understand them. One of my guinea pigs (associates that I persuaded to review the original draft) was a business analyst. After reading the draft, he confessed that he had been positively dreading having to read the tasters, but he had been pleasantly surprised to discover that his fears were unfounded and that he learnt a great deal. Another, a business manager, enjoyed the taster on firewalls so much that he wanted to know much more. I regard the tasters as reference material, i.e. I only expect readers to dip into those subjects that they feel uncomfortable with.

Which individuals are likely to get less out of the book? Although there is a chapter on post-implementation, I concentrate on the period from bid or feasibility study through to implementation. Therefore, if you are primarily involved in the support of systems that are in production then you may not get very much out of the book. If you are an experienced performance analyst who may be looking for highly detailed information on particular technologies or specialised topics such as queueing theory then this is not the book for you. However, I believe that the majority of readers will find it useful.