If you think SOAs will reduce the need for developers, you’re dead wrong.
There is a lot of talk about how SOA will significantly lower the need for developers; thus the savings of SOA. This will be accomplished through the promise of reuse that’s driving many toward the SOA light. However, I’m not sure we’ll see a reduction in development with the advent of SOA, but perhaps a redistribution of talent in the longer term. At the end of the day, the reason for leveraging SOA is agility. Reuse and development savings are a secondary benefit, if they happen at all.
Truth-be-told, we’ve been considering the demise of the developer during many “hype phases” over the last 15 years. This included the “component development” phase where I heard not one, but three software executives, in keynote speeches, talk about how “applications would be assembled like Ford assembles cars, from pre-built component parts,” thus, the need for fewer developers. Same goes for the distributed object phase, the intranet phase, and now here we are in the SOA phase. The issues are exactly the same, with perhaps the technology being a bit more compelling.
SOA, with all its rich chewy goodness, has three realities to consider:
First, it’s something that really has not happened yet; people are talking about it, and in some instances, playing around with it, but true killer SOAs are few and far between right now. This is due to the fact that it’s complex, a huge change in thinking, and those things take years to role out in most enterprises. It’s more people issues than technology, by the way. Thus, it’s too soon to understand what real savings will be realized from the use of SOAs. Or, in other words, we’re a bit early to think about how many developers we can fire.
Second, if history is a teacher, we’ll find that we actually need more developers – at least at first – with the promise of savings through reuse in the future. However, we’ve yet to get reuse right with all of the past opportunities such as object-oriented development, distributed objects, and component-based programming, so we’re assuming we’ll get it right with this technology, standards, and approaches. I’m optimistic, but I’m also a realist here, understanding that true adoption runs about two years behind the hype.
Finally, the use of services over the Internet will create a new generation of developers who build services for applications they’ll never see. They build portions of applications for use in many applications as services, typically delivered over the Web, and that industry will be huge. All you need to do is to look at the growth of the major service providers out there and the emerging Web services marketplaces. So, you guys who get fired by the enterprises will have better jobs in these emerging areas.
We’re building SOA for many different reasons, including savings on the development costs, but the primary focus of our SOAs should be on the notion of agility. The end result should be an architecture that’s able to change with the needs of the business, and the more your business changes, the more value SOA brings to you. Not to beat a dead horse here, but that’s the prize, and where SOA will make its real money for you.
The reduction in development costs will occur at the enterprise levels, but only after SOAs have been implemented and are systemic to the enterprise. This will take some time to accomplish with most businesses – years for many – before you can actually see development costs go down. Indeed, in the short term, development costs will go up.
In the future, more and more development will be occurring outside the enterprise, for consumption by the enterprise. This paradigm will provide even more cost savings, but the need for talented developers will always be there. These developers will be working on other things; service development, and perhaps for other companies, service providers and Web services marketplaces. Making more money, I’m sure….that’s a win/win as far as I’m concerned.
