« Cfengine | Main | Mars Update »
January 20, 2004
Return of the architects
I have to be careful here and speak fairly generically but the point is important. In the public service (and the quasi-public service) there is a strong tradition of "outsourcing" IT projects to some kind of body shop staffed by hourly rate incompetents. These are selected by going out to tender where the responses are from the consulting arms of large accounting firms (usually) who put there best (and often brilliant) people into a team to win the tender. Once the project business is "won" (usually at less than cost) they body fill with young and less competent staff while the brains go on to the next tender. The money comes from two areas. Firstly the body-hires are cheaper than the rates calculated in the tender (which are high enough to bring back the brains if required) and secondly there will be variations. There are always variations and the variations make the money.
Now before we get too deeply into the details, we need to stop and discuss architects. Traditionally your IT architect was called the "chief scientist" and he was into Dr Who and wearing long scarves and holding strange presentations and going to lots of conferences. This person (or rarely persons) was abreast of all the things that were happening outside the confines of the company and could be relied on to set corporate (technical) direction as well as to provide guidelines for implementing new systems, applications or technology. Now the role has become an 'IT architect' who still hold strange presentations and go to lots of conferences. They provide blueprints of where an organisation should be headed. They investigate new technology. They can direct new projects towards the "grand plan". What they should not do is (1) implement their plans (that is an operational concern) or (2) retrofit their plans onto existing projects (that is a project concern). New architectures need to be married with existing practice and implemented with an eye to operational and organisational constraints - i.e. by those looking inward, not outward. Otherwise the end result will be hugely expensive systems that are not used or simply don't work. The retrofit problem combines with the earlier note about tendered projects - the money is in the variations and a retrofit of architecture standards after the contract is a gold mine for the contractor.
Previously my current employer was involved in an ambitious, outsourced, project. The body hire was extensive (on our side and theirs). Everything was set and signed and then the architects retrofitted their standards. Two years (or so) later the whole project went belly up and headed for the courts with huge sums of money going down the gurgler. Who was to blame? The contractor? The operations staff? Certainly not the architects.
So with all that background, there is a project currently in the final design stage which involves some outsourced services. These services, running on an external server will be sending information to one of our servers over a secured communication channel. The architects, in their absolute, infinite (or is that infinitesimal) wisdom have decided that this communications channel should be implemented using MQ series (an IBM data queuing product used in business transaction servers). Note that they have not been involved in any discussions to date with the contractor, they have not discovered if this is practicable or even if it is a viable alternative. They have simply made a pronouncement from on-high which will have to be implemented. The server at our end may not cope with the overhead. The server at their end is probably not designed to run MQ. The internal staff that look after MQ are tearing their collective hair out trying to implement the existing MQ system without adding an unrelated set of systems.
Once again, all I can do is wash my hands of it. The contractor will get money out of the variations, the project will go the same direction as the previous one, we will have to resize systems, redevelop software, fart around and the whole project will go over time, over budget and over senior managers patience. Who will be blamed? Operations of course - for failing to implement it. Not architects for fooling around outside their assigned areas of incompetence retrofitting inappropriate technology.
Posted by Ozguru at January 20, 2004 10:01 PM
Comments
Posted by: The Gray Monk at January 20, 2004 10:01 PM
