Mr Lowe made a comment on his blog recently that I was chastising the use of SOD IT and sure I've had a go at people who mistake SOD IT for SOA, but there is actually another problem in here.
People don't like to admit that they do "development" or "delivery" anymore, its got to be all "architectural" and visionary, strategic and the like. Its a sad state of affairs when people have to dress up a great ability to delivery something as being architecture in the mistaken belief that this makes it more important. SOA is about making the business vision drive IT, but somebody has to turn that vision into bits and bytes which is why SOD IT is actually important.
SOD IT says that traditional delivery models that are based purely around projects need to change to move towards programme management of service projects. SOD IT says that automation of testing at the unit and system test level is critical for ensuring that a service is operating successfully. SOD IT says that requirements should be gathered in line with the services and that development teams should be based around the services. SOD IT is not just the same old technology delivery but this time with a different picture to aim out. SOA fundamentally changes software delivery, it moves it from the project oriented mentality of today towards a business focused view.
So don't dress up the delivery as architecture, its not, be proud of the fact that SOD IT is where the rubber hits the road and the SOA vision is turned into operational reality.
SOD IT without SOA isn't possible, and SOA without SOD IT won't deliver. As much as businesses and IT need to change the way they think about systems and IT in general they also need to change the way they think about the specifics of IT delivery.
So next time you are looking at an IT project and you've already created your business focused SOA and are moving into delivery, remember what Nike say...
just SOD IT.