Forbes exposes SOA's 'dirty little secret'

In his latest post in Forbes, Dan Woods delivers an interesting revelation: with SOA, IT departments end up taking on a lot of the work formerly handled by software vendors.

IT departments as software manufacturers

In the old days, a company took an application package in and ran it. (Never mind all the integration work and training and teeth-gnashing, but that's another story.)  With SOA, systems and applications are decomposed and re-assembled as services. These reconstituted, re-assembled apps, of course, belong to the assembler, likely the IT department. "For a mash-up or composite application, there is no manufacturer," Woods says. "The IT department or the person who assembled the application plays that role."  And with that role comes the need for operational and business process monitoring.

So, rather than withering away, as predicted by some, we may need even more IT. As Woods puts it:

"The challenge of full-blown SOA means that IT departments have many of the same responsibilities of software manufacturers and a few new ones. SOA management vendors like Hewlett-Packard, AmberPoint and Mashery are putting a lot of work into products that help with governance and monitoring. Software manufacturers like SAP are building consistent collections of services delivered as products. ...the mix of services needed at any one company will likely come from many sources, which means a whole new set of skills will be required for IT departments."

Woods says this may be all too much for already overburdened IT departments, so some of this work will be taken on by a new breed of service aggregators, who will "step in and collect large amounts of services, solve the integration problems and guarantee quality of service and scalability."  But the cavalry probably won't arrive in force for some time, so the work is still left to IT.

Agree or disagree?  It would be interesting to see some study into this area -- is there a correlation between SOA efforts and IT staff sizes, controlling for the fact that larger companies with large IT staffs tend to be further along with SOA?

I think even with packaged applications, there has always been a lot of additional work (and headaches) for IT, from installation to user frustration to performance issues to integration with other applications and systems within the enterprise. And there's still coding required. If anything, SOA alleviates the burden of writing a new interface every time there's a need to leverage these packaged applications. Plus, SOA reduces the risk of breaking applications, since most of the change work takes place in the service or interface.

Woods adds mashups to the SOA scenario, so it should be noted that another trend that is taking shape is that end users will increasingly take responsibility for their own front-end applications and interfaces.

Along with user-generated applications, we're seeing more automation.  Here's something for the future -- we'll someday maybe see the reality of the self-assembled application or service. Systems will predictively determine emerging requirements and automatically and dynamically generate mashups or composite applications that align with the new demands.

But there will always be enough going on to keep IT busy.