Part 1 of 3: What to Do in a High Level it Review

This is the first of a three part article on what to do in a high level IT review.

What would you do if you were asked to look at a new platform and you only had a day? Just to make this a real challenge, let's expand the scope and say that the company was planning to run the software on your behalf and therefore, they would look after the infrastructure that supported it. At face value, this looks like an almost impossible situation ... so let's break it down into smaller chunks and build a plan from there.

In this case, there are four areas of investigation, those being:

- Software. The actual software that provides the service, including how it is developed, tested and released into production

- Infrastructure. This area covers the servers, network switches, firewalls and possibly load balancers. It will, in this case, cover the data centre(s) and the security processes

- Operations. How will the software be administered and by who? This area is concerned with how to run the software, and therefore the service.

- Changes. How will the system be enhanced or upgraded? Who decides what functionality is added and when?

Having broken the challenge down into these four areas, let's look into each in a little more detail. I will give a quick check-list of key questions at the end of each section. The only way to conduct a review in such a short space of time is to do so in a question and answer manner.

Software

First off, we need to find out what sort of application we are reviewing. For example, is it a COTS (commercial off the shelf) application or has it been written from scratch (known as bespoke)? Is it a desktop application, a client-server solution or a web application? For the purpose of this article, let's assume that it is a bespoke E-commerce system that sells something over the Internet.

The next thing to find out is what language the software is written in. Knowing the language (and version) allows you to make some assumptions about how recently the software was written and to check for some of the common issues found with software written in that language.

At this stage, you know where the problem areas are likely to be, so pursue those until you are (or are not) satisfied with the answers.

Now, let's dig into the software development processes. Useful questions revolve around what is the source control used, how are branches controlled & merged and how are hot patches managed etc

Once the software development processes have been reviewed, then move on the Quality Assurance processes. Good questions to ask at this juncture include how is the code functionally tested? How is it performance tested? Is Integration testing required and if so, how is it carried out? What regression testing is carried out and how?

The final area in this section is Release Management; the processes to get some new or enhanced functionality live in a controlled way with minimal downtime. The central question here is how the new software is deployed to the production servers. From a description of that process, it will be apparent just how efficient that process is. It is also worth asking how changes to production are tracked and who approved those changes.

Software Quick Check-list

- Describe the software being reviewed

- What language (and version) has the software been written in?

- Ask questions in the likely problem areas

- Review the software development processes

- Review the Quality Assurance processes

- Review how Release Management is carried out

I hope that you found this section of the article interesting and please feel free to contact me on my web site at http://www.petergroom.com

Peter Groom