The origins of SOA
A couple of days ago I attended a meeting of Java programmers sponsored by SUN to be part of a round-table discussion around SOA with people from BEA and other local companies. I had a lot of fun but this really isn’t the point of this entry.
During the discussion we were trying to explain what SOA was and how to design SOA based applications. What really stuck me was that we were all explaining how to implement and ESB from scratch and use it to create new applications designed from the beginning to use it.
The fact is that this is simply not true. SOA is not something that most people plan from scratch. What really happened is that in the late 90s, companies just started to lose faith in their IT departments. They started to buy ERP systems because they promised better reliability, functionality and performance. ERP and other CRM systems are the great failure of the corporate IT departments. Corporate developers in midsize companies could just not deliver the value their employers expected from them. As a result, the number of development jobs started shrinking.
However, the promise of ERPs did not hold totally true. Most companies need functionality not provided by their corporate systems and implementing it using BAPIs or other proprietary systems to extend them is normally much more expensive than doing it quickly in languages such as Java or PHP.
So, SOA is really the last chance for corporate developers to save their jobs. If they can use it to successfully provide additional functionality at a lower price than their ERP providers, then they can show value to their upper management and will probably be asked to continue developing. Otherwise corporate IT will lose their remaining developers and will finally be completely outsourced as systems administration is usually not strategic.