Are developers aboard SOA bandwagon? |
 |
By Michael S. Mimoso, Senior News Editor
08 Jul 2004 | SearchWebServices.com |
|
|
Service-oriented architecture (SOA) may be a nirvana for efficiency-hungry IT managers and bean counters, but what about for the programmers building application components that will repeatedly be reused?
Are some fearing for their jobs once applications are componentized?
|
|
|
|
|
Most developers seem to take pride in self-made code, and collaboration isn't seen unless it is driven by a company policy.
Kaleem Aziz
Software consultant
|
|
|
|
|
|
|
|
|
|
Developers are usually reticent to reusing someone else's code. Plagued with the affliction affectionately known as "Not Invented Here Syndrome," developers are used to the walls built between different segments of an enterprise IT organization. It's not unusual for companies to have multiple versions of an inventory-lookup application sitting around, for example.
With SOA getting more attention, however, developers are finding themselves in a Catch-22. Some reluctantly following an IT shop's SOA design philosophy might be programming themselves to the unemployment line. An online reader poll on SearchWebServices.com posed the question of whether developers are fearful SOAs might some day cost them their jobs. Eighty-eight percent either said yes or were unsure.
Some observers weren't so quick to fall in line with that thinking.
"As we talk to members of the development community, we don't sense desperation that SOAs are going to break anybody's rice bowl," said Burton Group senior analyst James Kobielus. "Offshore outsourcing is what's striking anxiety in developers. It's not that the work being done isn't as productive, but you can pay less to a programmer in India than in Illinois. That's the real anxiety. It doesn't have anything to do with SOA."
SOA is a design philosophy where code is written once and reused again and again throughout an enterprise. Often, SOA is based on Web services standards that enable application components to be accessed and consumed by business partners, suppliers and customers.
"I understand SOA-Web services to be the answer for integration and B2B needs," said Kaleem Aziz, a software consultant in California. "I am bullish on this technology because that's one stone for two birds! Also, I am excited because SOA is invariably business driven when it comes to [business process management]."
Managers love SOA for its efficiency. Developers are no longer re-inventing the wheel, and new services and applications are built quicker with reusable components. Burton Group's Kobielus said his clients, usually enterprise decision makers like chief information officers and chief technology officers, want to know about the practical relevance of SOAs in their businesses.
"Generally those people using SOAs can employ fewer programmers, or do more with the programmers they have," Kobielus said. "Services are not needed in the way they used to be. Does that mean that these programmers are unemployable? No. It means their labor is available to other projects. IT shops can tackle new development projects with labor that's already been done. They don't have to rebuild the same procurement application over and over in different units."
Some managers, meanwhile, are either issuing ultimatums to developers to fall in line with SOAs or offer incentives for code reuse for application development groups.
"Most developers seem to take pride in self-made code, and collaboration isn't seen unless it is driven by a company policy," Aziz said. "In other words, they see their creations as more important, comfortable and well thought out than a business need."
Incentives or punishments aren't always the answer either.
"With large companies, it is very difficult to know a piece of code exists in another department. And assuming it does, the different approaches each team has taken to develop their code often doesn't fit in with that of the other team," Aziz said.
"For instance, to be able to use the code of another team, the first hurdle becomes 'Which team will maintain it?,' which is important for [answering the question of] how will the bugs be routed? The second issue then is the ill feeling or nervousness of one person's code being handed over to another -- how do you manage that? What works at a micro scale should work at a macro scale, one would think, but it isn't that straightforward when it comes to technology-management."
FEEDBACK: Are you fearful SOAs might threaten your job security?
Send your feedback to the SearchWebServices.com news team.
|
|
|
|
