You in an SOA world

The service-oriented architecture will lead to big changes in your job. Early adopters and other experts share tips on how to prepare for what's ahead.

No doubt you've spent time pondering the profound technology changes that a service-oriented architecture implies. But you need to think, too, of the sweeping changes an SOA would mean for your job. The SOA promise is that monolithic applications will be replaced by loosely coupled Web services - reusable bits of code written to a standardized interface so they can be mixed and matched and hosted anywhere. These little bits of applications floating around will be bound together on "the network" - and not just your little corner of it. In an SOA, the network encompasses public networks and your business partners' networks, too. So your work will become more visible in the corporate scheme of things, which can be good for your career.

The hope is that the SOA approach will let IT departments quit reinventing the wheel, to automate more and therefore to do more with less, particularly less programming. Then again, loosely coupled services are more easily outsourced. This might lead to fears that introducing such an architecture could put IT jobs at risk. But early SOA adopters are learning that job loss isn't as much a factor as is figuring out how to best realign IT personnel with the shifting tasks an SOA requires.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

No doubt you've spent time pondering the profound technology changes that a service-oriented architecture implies. But you need to think, too, of the sweeping changes an SOA would mean for your job. The SOA promise is that monolithic applications will be replaced by loosely coupled Web services - reusable bits of code written to a standardized interface so they can be mixed and matched and hosted anywhere. These little bits of applications floating around will be bound together on "the network" - and not just your little corner of it. In an SOA, the network encompasses public networks and your business partners' networks, too. So your work will become more visible in the corporate scheme of things, which can be good for your career.

The hope is that the SOA approach will let IT departments quit reinventing the wheel, to automate more and therefore to do more with less, particularly less programming. Then again, loosely coupled services are more easily outsourced. This might lead to fears that introducing such an architecture could put IT jobs at risk. But early SOA adopters are learning that job loss isn't as much a factor as is figuring out how to best realign IT personnel with the shifting tasks an SOA requires.

"The theory with SOAs is that IT departments shrink," but that's not necessarily the case when you balance the ability to cut programming jobs against long-term goals, says Terry Bone, manager of frameworks and architecture for Ford Credit, one of the largest automotive-financing companies in the world. (Network World honored the Dearborn, Mich., company in 2002 for its early SOA efforts.)

Bone is analyzing how to size the department correctly and if outsourcing has a place. This translates into trying to "define strategy" on what a right-sized department looks like and how he can encourage his best programmers to stick around when an SOA means less coding work for them, Bone says.

Although staff size will remain constant, the automation technologies necessary to operate an SOA model will allow each member to do more work. In addition, roles will shift away from manual areas, such as custom-coding projects, and into new zones, such as application assembly work.

Obviously, the number of application programmers on staff would decrease because less code would need to be written. One skill that might not be needed nearly at all is the down-and-dirty technical programming usually relegated to young, inexperienced programmers. The job of writing integration code between two cantankerous applications, for example, should be rare. That task should be undertaken by the vendors, whose role will be to handle and hide all that complexity from their customers, says Tim Hilgenberg, chief technology strategist for application development at Hewitt Associates, a human-resources firm in Lincolnshire, Ill., which has adopted Web services and SOA technologies.