[LINK] IT can lead to big savings: Tanner
Bernard Robertson-Dunn
brd at iimetro.com.au
Wed Apr 9 22:41:36 AEST 2008
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.
--
Regards
brd
Bernard Robertson-Dunn
Sydney Australia
brd at iimetro.com.au
More information about the Link
mailing list