[LINK] IT can lead to big savings: Tanner

Tue Apr 15 09:41:56 AEST 2008

Richard Chirgwin wrote:
> Chipping in late...
> 
> There's also a gap between how systems are presented (particularly 
> through the press), and the realities you outline below. When someone 
> says "here's our new application" in a media case study, they rarely 
> talk about the multiplication of servers that you've outlined.
> 
> I note that Cisco is now pitching the idea of "run your application 
> server inside the routers":
> http://newsroom.cisco.com/dlls/2008/prod_041008.html
> 
> The security implications of such an implementation would worry me to 
> death ... the idea, even in the branch network (or especially so) of 
> putting the apps in the router, is only good for Cisco, not for the 
> users. IMO anyway...

Depends on the application, alternative application servers/architecture and 
where in the network it was located. There is a chance the operating system on 
the Cisco box is inherrently more secure.

> 
> Richard Chirgwin
> chirgwin.blogspot.com
> (Now that I'm freelancing again, I've revived the blog!)
> 
> Bernard Robertson-Dunn wrote:
>> Tom Worthington wrote:
>>
>>>  As an example, ABS issued a request for tender for a recruitment
>>>  system a few weeks ago
>>>  <http://www.tomw.net.au/blog/2008/03/e-recruitment-system.html>. This
>>>  will have a web based interface and can work over the Internet.
>>>  There should not be anything different about how ABS does recruitment
>>>  to most federal government agencies (apart from some in law
>>>  enforcement and security). There doesn't seem any good reason why
>>>  most government agencies couldn't use the same system as ABS. The
>>>  system would just need a few extra features and more userids issued.
>>>  The hardware to run the system for the entire public service would
>>>  fit on a desktop server costing a few thousand dollars.
>>>
>>>  Rather than create a huge project for a recruitment system, the
>>>  Finance Department could simply identify this as a potential
>>>  corporate application and give ABS a few extra resources to take
>>>  wider needs into account. ABS would implement the system for
>>>  themselves and if that worked okay, the system could then be made
>>>  available to others. Along the way the sums could be done to see if
>>>  it is worth having the system open source.
>>
>>
>> Oh dear, the naivety.
>>
>> When I was the IT architect at Finance and then Health and Ageing, we 
>> used to get all sorts of simplistic requests like Tom's suggestion of 
>> "a desktop server costing a few thousand dollars" to run an enterprise 
>> class application.
>>
>> Without commenting or addressing the functional requirements of the 
>> recruitment system, the infrastructure requirements go way beyond a 
>> couple of servers.
>>
>> The reality is that any system that is to go into a government data 
>> centre has to comply with the department's operational and security 
>> requirements - and we are talking DSD ACSI33 here.
>>
>> The first requirement will be that there will need to be at least two 
>> if not three versions of the infrastructure - 
>> production/dev-test/acceptance (as its an off the shelf system dev and 
>> test can probably be combined with acceptance). If it has a serious 
>> database as well as an application server and web server then that is 
>> at least two, if not three servers per application. In addition there 
>> will need to be some form of archiving/audit/logging - preferably on 
>> another server, but maybe only for the production environment. Yet 
>> another server might be required for analysing and accessing the 
>> archiving/audit/logging data.
>>
>> As its a web facing system then the prod web server will probably be 
>> in the DMZ with some mechanism to work across the internal firewall, 
>> probably a proxy server.
>>
>> Then there is back-up and restore, but that would probably use 
>> existing infrastructure, but there would still be a cost.
>>
>> Then there is DR. Depending on the agency's approach, it might be 
>> possible to ustilise the dev-test/acceptance environment, but there 
>> would still be a cost.
>>
>> And maybe also Business Continuity (which is different from DR), 
>> possibly more cost.
>>
>> And redundant network connections, and redundant power supplies, and a 
>> SAN with RAID discs for the data.
>>
>> So we are actually talking about significantly more than a single 
>> server. My educated guess is 15-20, depending on the complexity and 
>> performance and other NFRs.
>>
>> And let's not talk about virtualised servers. The experience in many 
>> data centres is that there are limits to what you can virtualise on to 
>> the same server (eg you don't combine prod with non-prod or prod with 
>> DR and you don't cross security boundaries.) and the cost of 
>> supporting a virtual instance is more than that for a server with a 
>> dedicated OS.
>>
>> The suggestion that "ABS would implement the system for themselves and 
>> if that worked okay, the system could then be made available to 
>> others" does not take into account the additional complexity and 
>> security requirements of a system that can be accessed by multiple 
>> agencies from within their security zones.
>>
>> My experience of trying to get people from one agency to access an 
>> application in another agency, both within the same portfolio, tells 
>> me that this would either not be possible or is downright impossible. 
>> This is for many reasons, not the least of which is that agencies 
>> cannot have legally binding agreements with each other.
>>
>> Enterprise IT systems are very complex and vastly different from 
>> personal computing.
>>
>> And all this is not because it is government IT. Banks and airlines 
>> have just the same requirements.
>>
>> And it there really were cheaper ways of meeting the NFRs then someone 
>> would be out there doing it.
>>
> _______________________________________________
> Link mailing list
> Link at mailman.anu.edu.au
> http://mailman.anu.edu.au/mailman/listinfo/link
> 

-- 
Marghanita da Cruz
http://www.ramin.com.au
Phone: (+61)0414 869202