Most IT oriented attempts to implement SOA I have seen end up as glorified CRUD systems pulling data to and from databases. This leads to tightly coupled systems that rapidly degrade into Big Balls of Mud. If I contrast this to the few successful attempts I’ve seen, they had one commonality: they were all ‘message based’.
While messages share some characteristics of service interfaces, they differ mostly in their granularity and lack of dependence upon one another. Messages allow true decoupling, where traditional service layers only promise this and usually end up creating even more tightly coupled systems. This separation of concerns allows development teams to concentrate on component parts with little impact upon other teams, and no more reliance upon them than an agreement on the messages they will listen for and those they will publish.
Of course the question remains if IT is the right department to promote a SOA approach. Often decisions about software architecture become the underlying drivers for the entire IT department, instead of providing a framework to create business value.