[LINK] IT can lead to big savings: Tanner

[Richard Chirgwin]

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...

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.
>