Like most people in IT, I wear different hats.  I am an Architect, Techie, Manager – to name a few.  The challenge it gives me is how to balance the roles I’ve got and still come up with the right answer.   The dilemma I generally have is this:

As an architect, I design systems.  Before deployment of new or after upgrading existing ones, I do some testing.  As a techie, I would like to test them as much as I can, covering every possible scenario that I can think of, before the systems go into service for the first time or after an upgrade.  As a manager, however, I would like to get the systems into service as soon as I can, even if it means I have to miss a few test scenarios – especially in cases where the systems are existing service systems.

You see.  It’s not easy!

That said, the correct answer depends on what’s the change and how much time you can allow for testing.  Sometimes, I am in a scenario where there is a green field environment for me to play with and it’s a new development.  I make sure I think of every possible scenario and test the environment and its behaviour to the nth degree.  On the other hand, if I have the same environment in service and it’s hosting critical service(s) now, I only have the liberty to test what I “need” to test, rather that what I “want” to.  It’s also quite difficult to justify downtime to test a scenario which “might” happen but has very low probability.  How do you quantify risk in that case?  The best thing to do is to accept the risk and move forward.  That is especially true if you’ve got strong and reliable support contracts with appropriately defined SLAs.

At the end of the day, it’s a matter of taking the pragmatic route.  After all, customer satisfaction is paramount!