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.
"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.
Evolving your skills for SOA
|
However, the number of programmers you employ also will depend on whether you are primarily a "publish" kind of SOA organization or a "subscribe" type, says Allison Bacon, senior research analyst for Eze Castle Research. Organizations for which IT is the business (IT vendors, e-commerce companies, virtual service organizations) might continue to write a lot of their own Web services and then publish them for others to use or buy. Organizations for which IT is a tool for producing a non-IT product or service will most often be subscribers.
Either way, assembly work will become one of IT's major roles. Subscribers will be expected to shop for pieces of applications, then plumb them together in a unique way that adds business value, Hilgenberg says. "When you start looking at SOA, you're really talking about being able to compose applications as opposed to being the developer of them. You become more of an aggregator and integrator, putting together portals and aggregating data and transactions."
The challenge for the assembly staff will be to add business value that specifically addresses the organization's needs, so that the application is more than the sum of its parts. "If programming skills become somewhat commoditized, you'll have to figure out how to add value on top of that ... much like what a Dell does as an integrator of components - the one who specs them out," Hilgenberg says.
For instance, the assembly staff will want to take generic, customer-service Web services, find more Web services that address the company's specific needs and stitch them together to produce a unique customer-service application.
Keeping watch on the parts
The IT job also will require carefully watching over vendors to make sure you can meet the stringent uptime objectives inherent in a services orientation, Hilgenberg adds. This is especially the case for companies that are kludging together Web services from a variety of sources, many of which will be written or hosted out of their direct control. In reality, these also will be out of the direct control of their vendors, who will likely be buying their Web services from third-party sources, as well. So the onus will become one of researching vendors and their sources, and then monitoring those suppliers closely to ensure that a three-times outsourced component doesn't cause a failure across your system. This is a big shift, as most companies today bring all pieces in-house and keep track of them from there.
The fact that so much of your application will be out of your direct control means that security work will be plentiful. True, security is already a major role of the network staff, but its tasks will mutate and multiply until it becomes a part of every technical role you supervise. Think about the task of securing the network and your data when you can no longer cordon off critical applications with passwords, and when bits of code are hosted on your vendors' sites, as well. "Everything, theoretically, could be outsourced, but you will still have to maintain internal expertise. You'll still have to protect what comes in and out of your enterprise. ... That requires a big security skill set," Bacon says.
However, the requisite security expertise is anyone's guess. Bacon says application design and management, including security, will become a strategic role. So if the day comes when all enterprise applications live via an SOA, someone will need to perform the job of deciding what application components are being used for what business purposes and how these components are being re-used, where each is being hosted and so on.
The job of business liaison
One of the more exciting new roles that will arise in the SOA world is "the business liaison," Ford's Bone says. This job will entail working with business to help define the technical and business processes that move the business toward its goals. While IT has always performed this task to varying degrees, the SOA will intensify the need for dedicated staff for it. For instance, people in this role could work with customer-service managers to create a business process from available technologies to improve customer-service response times. A business liaison might be assigned to every line-of-business department. This is an ideal spot for the best of all those soon-to-be unnecessary custom programmers, Bone says.
"We're seeing developers lean toward taking on business user roles. We're seeing people and competency go back and forth across that line - the line is blurring. The SOA is going to blur it even more. Developers aren't going to need to do a lot of heavy coding. We'll need those that can work with business customers more around defining processes, defining integration technologies," he says.
Of course, as more technology pervades everyone's daily lives, techie knowledge is hardly the sole purview of IT folks anymore. Business managers are already learning about the applications out there that can help them, says Sandra Rogers, IDC's program director for SOA, Web services and integration. Some might even think that these liaison jobs should be staffed from the business side of the house, not with your staff. But, as Rogers points out, business managers don't know what they don't know about technology. For instance, a business manager won't know about data modeling, integrating with automation tools, configuration, performance optimization, security and a host of other technology best practices, needs and procedures.
"It's a danger to think that the business people, even in the short term, will understand what the technology can do. It's like black boxing. You don't know what's really going on, dealing with expectations, debugging, propagation, compatibility and what the system is trying to achieve. The business side is going to find all of that very difficult," she says.
Employers will increasingly need those who can marry technical expertise with business acumen. If you haven't already begun to look at your staff through the SOA lens, make it your business to do so soon.