A colleague and I were recently discussing the low hanging “SOA“ fruit in our fortune 500 company. As the discussion wore on, we agreed on a few things....
1) SOA is Component development taken to the Nth level.
Component development is all about building sets of common binary code that can be implemented in multiple applications. Interoperability is a huge issue with component based development, as we often have to jump through hoops to get disparate technologies to talk to one another. Middleware products (MQSeries, MSMQ, etc) attempt to resolve interop issues by providing a common communications channel to disparate technologies, and to a large extent they are successful. We've been using middleware to support inter-application and intra-application services for years, so what's the big deal with SOA? The middleware we're using suffers similar interoperability problems as components. SOA (in the context of Web Services) has introduced the potential for interoperability between systems that is contract based and works on open standards.
2) Hell, It's still Component Development!
Therefore it risks suffering from the same diseases as component development. A few years back, our fortune 500 company had a small group of developers called the “Common Components Team”. The team built a library of business components for use by application developers. A Common Components Library was created to house the components (Sound like UDDI?). The group was disbanded within a few years. Why?
Aligned IT areas were compelled to satisfy their business users, who always seemed to need an extra little tweak or feature that the existing components did not supply. The Common Components Team often would be unwilling or unable to change their component in keeping with business IT deadlines. Code was frequently copied and pasted from the Common Components Library into the business product, then modified to meet the specific requirements of the business application. Of course, this excuse-for-reuse erodes the usefulness of a library and the team that develops it, as is exemplified by the ultimate fate of the team.
Is SOA any different? In my company, services are envisioned in neat little silos, supported by the groups who are experts in the data or processing behind the service. So what happens when a core group's services do not meet the needs of a current development effort? The answer depends heavily on the availability of resources in the service group. Perhaps there are plenty of resources to work on a new service, perhaps there is a 6 month backlog in the group. Soon the business developers will be looking to write their own versions of services via copy and paste, and then we're back to square 1.
3) SOA makes a business case for outsourcing.
The natural ebb and flow of demand in a service oriented environment is a case for “developers-on-demand ”. The closest thing to this model is outsourcing. Businesses crave the potential cost savings that might be derived from paying for support and coding based on usage, rather than retainer. I know a bunch of dedicated full timers that will want to kick my butt for not publicly recognizing all the “free work“ they do, so before they have a chance I'll say this: I'm not arguing that there is or isn't a cost savings associated with a developers-on-demand model, just that bean counters believe it to be so. Nothing more than a long record of failed outsourced projects will sway those who are making the decisions about the future of your job, and by then it may be long gone.
Hmmm... are developers-on-demand any different than consultants? I would never hire a consultant without the required technical skills, yet there is nothing that prevents an IT Provider from assigning technically ignorant developers to a delivery request. I've heard countless stories of this kind of thing happening in consulting firms in order to keep people off the bench and on billable time......is Something Old new Again?