[LINK] IT can lead to big savings: Tanner

[Bernard Robertson-Dunn]

Tom Worthington wrote:

> At 07:34 PM 11/04/2008, Bernard Robertson-Dunn wrote:
>
>> Tom Worthington wrote:
>>
>>> Recruitment is a very small corporate application which only a 
>>> handful of people in a government agency would use
>>
>>
>> Aren't you forgetting about the users who are searching for and 
>> applying for a job? Potentially thousands, potentially many at the 
>> same time. ...
>
>
> Yes, there may be thousands of people searching for a job and hundreds 
> applying at a time, but they are not going to use much in the way of 
> computer resources. 

Is that an assumption based upon it being a "small" application? or are 
you  familiar with the sort of infrastructure required of such a system?

>> As I tried to explain, there would need to be a number of separate 
>> implementations - at least two, probably three - prod, 
>> dev/test/acceptance and DR and not in the same computer room. Five or 
>> seven servers is not a lot for a system with the requirements that 
>> ABS has put out. ...
>
>
> Yes, but each implementation would only take a small fraction of the 
> resources of each server. The development and test systems in 
> particular are not going to be heavily used. As a result those servers 
> can be shared with other applications. 

Server hardware is actually quite cheap, compared with all the other 
things you need to support and manage them.

One reason for having so many servers is because the system has so many 
different functional components and it's a very good idea to reduce the 
dependencies between them. One standard architecture for a web 
application is internet/firewall/web server/firewall/app server/database 
server. Each on its own hardware. That way you do not introduce 
dependencies and coupling between OSs and application, and one 
application and another application.

The number of times that an upgrade to an app server has been delayed or 
forced because of an OS or Database upgrade is significant enough to 
result in the standard architecture.

And that's also a good reason to be very careful of virtualisation. Some 
versions introduce unfortunate dependencies. Similarly for sharing 
dev/test with other applications.

>
> My back of the envelope estimates are intended to spark discussion and 
> have people question the assumptions upon which business cases are 
> put. Building computer systems is a complex and expensive business and 
> that is why I suggest that the Australian Government needs to build 
> fewer of them, and build each one better.
>
That's where you and I really disagree. Sharing a complex thing like an 
enterprise Information System adds complexity, dependencies and cost. 
Simplicity, specialisation, clear control and minimum dependencies work 
makes systems much more efficient and effective.

I would suggest that you probably don't sit at your personal computer 24 
hours a day. On what basis would you be prepared to share it with 
someone else, other than immediate family?

-- 
 
Regards
brd

Bernard Robertson-Dunn
Sydney Australia
brd at iimetro.com.au